Does Johnny Need BASIC?
I just popped over to Salon to read an article by SF writer David Brin entitled "Why Johnny Can't Code." It's interesting enough to skim, but it can be summarized very easily: Brin thinks the lack of line-oriented BASIC interpreters (like we used to have in IBM PC BASICA and cheap machines like the Commodore 64) is keeping bright kids from getting into technical computing.
Ummmmm...no. I've met a fair number of Johnnies who have mastered C++ at age 13, just by getting books out of the library or reading online articles, without intervention by parents, teachers, or even peers. That may not be the issue; such kids will always exist, and nothing will keep them out of the belly of the machine. What David is actually worried about is that kids who lack this kind of passion might be distracted into other fields without an easy way to experiment with FOR loops at a command line, and never spend much time on programming at all.
I admit, that is not an optimal outcome. Anybody who aspires to any kind of career in tech (even sales or PR) should have some exposure to programming, and with more PCs than people now in educated urban America, there's no reason why this shouldn't happen. No reason except that we've hidden The Front Door.
I've mentioned the problem of The Front Door a time or two here. When you come to programming absolutely green, how do you take your first step? Where is Square One? With command-line languages, The Front Door is right there in the command prompt. The lights are on and it's waving you inside. As your first step you can use a PRINT or Writeln statement to echo a piece of text like "Hello World." Step Two is to display it a second time with a second PRINT statement. Step Three is to take the leap to a FOR loop and display it five times. At that point things start to accelerate, until the fundamental concept explodes in your head and the next thing you know, it's two ayem and you can't rip yourself away from the machine. By the time a week goes by, you've written a text formatter or a simple video game. (This was certainly my story, albeit with APL and not BASIC, and I've heard it from a lot of other people as well.)
All early operating systems were text-oriented, and at some point everything was done from a command line. Once Windows took over, it got a lot more complex: To even open a window entitled "Hello, World" took an understanding of events and handles and (early on) a huge ugly honking case statement. The first generation of true visual environments (Delphi, Visual Basic) helped a lot, but there was still the problem that instead of a single command prompt there were a screenful of things to look at and decide how to cope with. You could no longer type a couple of characters in an obvious place and get onto a useful feedback treadmill.
The Front Door is a problem, but there are big questions of how much of a problem-and whether the solution that Brin and others suggest is worth the cost. BASIC is one of the worst ways there is to learn how to program. (The only worse ones I could suggest are flailing away in APL-as I did-or FORTH-ditto.) The message you get from such languages is that stringing statements together until something works is programming. Learning the subtleties of program structure and OOP after an intro like that requires significant un-learning, which isn't automatic and requires a remarkable amount of personal energy.
You get no prize for predicting that I think Delphi is a better way to begin (especially now that there's a free version) even if it might require ten minutes' worth of reading to take your first step. If a command line is important, I think Tcl/Tk is worth a look. It's free, there's a Windows version, and there are several good books written about it. The Tk toolkit allows you to create windowed apps without a lot of fuss, and the whole thing is completely text-based.
But no matter how I look at it, the kicker insight (which Brin mostly ignores) is that there is now an irreduceable amount of study that you have to do before you can write even the tiniest sane program. That's the approach I took in Assembly Language Step By Step. The book is half over before you write a single line of code, but the conceptual foundation embodied in the book's first half keeps you from coming to a faulty understanding of the ideas behind assembly work. With assembly the key idea (often badly taught) is memory addressing; in OOP languages (all structured languages, really) it's scope. Compared to those two ideas, machine instructions and iterative loops are trivial. I'm trying to figure out the best way to teach Delphi programming that begins with sound design principles, but if my method requires reading 200 pages before setting fingers to keyboard, will anybody bother?
Or is the real problem that Johnny isn't interested enough in programming to accept being told how to do it right?