Slashdot Mirror
QBASIC Programming for Dummies
I've read countless books and online tutorials on QBASIC, C++, PHP, and other various languages. I'm sure all you wise programmers can tell me the first sample program that comes to mind with any language, can't you? The classic 'Hello, world!' example. This easy app starts off would-be programmers with a level of confidence and understanding. To my surprise, Douglas Hergert decided not to use the ever-popular example program. So, you might be wondering, what did he use in it's place? A four-page-long currency converter.
This was Mistake #1.
The book started off making me feel stupider than I actually am. This oftentimes discourages readers from pursuing, and the book takes to the shelf, perhaps never to be picked up again. I've noticed that the best way to capture a reader's attention (and explain the most) is to start off with PRINT, INPUT, IF...THEN and GOTO. Then move on to loops, and get technical from there. It best prepares the reader for everything in store, rather than making them feel like idiots. The book didn't do this at all. It started off making in such a way that anyone without experience would be completely lost. IF...THEN doesn't even come in until the eleventh chapter, despite being one of the most important tools in the language!
So, what good can I say about the book? Not much, except that it came with some practical applications. This brings up another grievance I have with it, that being the lack of an accompanying disc. I feel every book on programming with long examples ought to come with a disc containing all example programs, so that the reader can tweak and observe them as he sees fit, without typing in five pages of code. The best way to learn is often by example, and discouraging lazy people doesn't help the learning process along.
Alas, the book does contain some humour, as it's other brothers and sisters from IDG often do. With chapter titles such as Text, Lies, and Videotape and How to Manage Arguments and Influence People, a book can't be completely bad.
Although I suggest beginners steer clear of this book, it can be useful to experienced programmers (supposing they don't think QBASIC a waste of time). It goes deeply into data structures, arrays, and databases. There are many helpful features, but it's definitely not a book to learn from.
You can purchase the QBASIC Programming for Dummies from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
"When I said to move your mouse 'up', I meant forwards, not vertically.........."
0110100100100000011000010110110100100000011000100
Don't mess around with any variety or descendent of BASIC as a learning language. You've got one thing right: it teaches you the wrong things to do in a lot of ways. It will only add confusion when a programmer goes on to more complex (perhaps the wrong word here) languages.
:-)
So, I suggest C++. That may sound appauling at first to some, but here's why.
Programmers absolutely have to know how to work with memory. It's a fact and it's one I think will never change, no matter how abstracted or garbage-collected languages become. You might suggest using C, but I think that's a bad idea for two reasons. The first I'll describe here: it's a little too hard. You want programmers to learn the hard stuff, but not too fast. new and delete are clearly not as powerful as malloc and free, but they do basically the same thing: allocation and deallocation of memory. The former two are easier to use at first and more intuitive to the programmer, especially when dealing with objects. The second reason for not starting on C comes in my next point.
We live in a world of objected oriented abstraction. It's essential for the development of a lot of modern software, particularly anything that exhibits a sophisticated user interface. Classes are not particularly difficult to learn with C++ and C lacks object oriented programming altogether (well, for the most part). Once you know C++, the object oriented programming skills obtained can be passed on to a number of other languages, including Java with very little relearning.
C++ is more relevant by far than *BASIC. Aside from skills developed while learning it, the language is self is widely used and has a relatively small learning curve. *BASIC may or may not be much easier to learn, but that's irrelevant because it is very rarely used. You wouldn't bother learning *BASIC for the same reasons you don't really bother learning COBOL or Pascal these days. I'm not saying they're lousy languages, just not particularly useful. (You could argue that VisualBASIC is used a lot. May be true, but usually only for RAD throw-away applications or application prototyping. It's piss-poor for anything serious.)
Of course, you could also argue that CS should be taught the same way as CE: learn why the tiny pieces work, then learn how to use the tiny pieces, then learn how to use complex pieces made of tiny pieces, and so on. In that case, everyone needs to learn Assembly first then move to higher level languages one at a time. That is another discussion altogether, but it contradicts learning *BASIC first.
Join Tor today!
FYI, I'm 30, I've long since graduated from programming to design, and no I did not make the numbers up.
That's funny because you said you have 20 years of work experience in the industry. So you worked for 6 years illegally or you're John Carmack, but that's impossible since you hate low-level stuff.
I'll leave you to understand how to cull since you've obviously would rather insult me than ask how it could possibly be done.
Ah, but you said that you "ran" 1,000,000,000+ records in 1/100 seconds. I very generously gave your "run" 1 cycle per record... now you try to tack this on. Since you don't care how things work intenerally, you must assume that culling is a noop. It's not. Try agian. Perhaps you could explain to me in detail how this is done. Describe your algorithm. Give an analysis of its complexity. How do you overcome the bottlenecks? Desecribe what a "run" is on a reecord. I understand caching can be used to improve IO performance, but that has nothing to do with how fast the operation itself is performed. Whether or not you read from a buffer or a disk, any given operation will take n time. It's not as if a buffer makes something a noop! Care to lend us your insight?
With your logic it should be a requirement to understand all material science of a car in order to let a driver use one so they can make, replace or mend any part that could go wrong.
Uh, no. With my logic, it would be a requirement to understand material science to engineer a car. The user is analogous to the driver. I agree, the user need not know about how the computer works because they are not programming it.
But, if you knew design you would have realized that your CPU argument doesn't hold water because the issue is really how to handle the I/O bottleneck, which is asynchronous. So, your 1 CPU per record doesn't even work because you don't understand how buffering works-- it is possible to have a well below 1 CPU per record count rate, but I digress.
This makes no absolutely no sense and you failed to comprehend the argument. First of all, I said cycle, not record. There's a big difference. I never suggested 1billion CPUs were necessary to process 1billion records. Let me break this down and explain it to you again.
Your claim: 1,000,000,000 records processed in 1/100 seconds.
Let's assume 1 CPU cycle is required to process each record. For simplicity sake, we are not going to take into account any processor time required to read the records regardless of the source, memory, disk, or any other magic buffer. The reason we are disregarding this is becaue clearly, any operation to read data, regardless of its source, takes additional time. If you take IO into account, your claim is not even remotely possible. We will only concentrate on the actual "processing" of a record. Even the processing of the record is arbitrary in this argument. Any kind of practical record manipulation would likely involve many cycles. Incidentally, to examine a record to determine if it can be culled also requires some CPU time.
Now, let's do some very complex math. 1,000,000,000 records at 1 CPU cycle per record in 1/100 seconds would require a CPU to perform 1,000,000,000 * 100 cycles per second. That would be 100,000,000,000 cycles per second, or 100GHz.
If we take into account practical operations on records (involving many more cycles), reading them from disk and/or memory, the CPU would clearly have to execute far more instructions. I am still disregarding IO bottlenecks for your benefit. If it takes 1 CPU cycle to process and 1 CPU cycle to read, again assuming that IO takes zero time, then we now require a 200GHz processor. This is true even if the CPU is a specialized processor that performs the operation on each record and IO in 1 cycle each.
Now if you had a cluster of 100 systems running our
Join Tor today!