Why Johnny can code

Why Johnny can code

I recently re-read David Brin’s essay, “Why Johnny Can’t Code”. He posits an interesting idea, one I’ve had for a while—we are raising a generation of techno-illiterates through our focus on high-level languages, rather than on the simple languages like BASIC, on which many of us cut our geekteeth.

What I observed had nothing to do with programming, and everything to do with Mr. Brin’s approach to computers. His point may be valid, but his sight is limited by his own understandable ignorance.

He forgot there are other options.

Simply put, Mr. Brin wanted to teach his 14-year-old son about programming. A few of the textbooks still had examples in BASIC, that wonderful, terrible language that came with many of the first personal computers: the Altair, the Apple ][, the Commodore PET and 64, the CompuColor, and even the first IBM PCs. In those days, Microsoft was merely a supplier of BASIC for some of those machines, and so BASIC was fairly consistent across systems.

I learned BASIC on the Apple ][. Eventually, I moved on to 6502 assembly language, and Pascal, and then on to C and LISP and Objective C and FORTRAN and COBOL, and so on. But we all remember our first, and mine was BASIC.

For all its faults, BASIC was simple to learn, simple to write, and the interpretive nature of most implementations meant it gave immediate feedback. I realize many people have been ruined as programmers by BASIC. But, for people who are just starting out, it is not as bad as, say, C++, or Perl, or Python.

And so Mr. Brin looked for a BASIC interpreter for his MS-Windows machine, or for his Mac. Never once did he consider his alternatives.

The education of Ben Brin

Mr. Brin’s entire goal was to educate his son Ben about the true workings of computers. He looked at doing it the old-fashioned way: guns-a-blazin’, with BASIC. This isn’t a bad start, but he didn’t consider that those of us who cut our teeth on BASIC learned about computers by tearing them apart, by making them work, by fiddling with them. It wasn’t just BASIC. It was the entire environment, where the system source code was printed in the books distributed with the machine.

There was a voice recognition system for the Apple ][ that used the cassette tape for voice input. It came with a tic-tac-toe game. I spent hours getting that to work properly, fiddling with the tape drive to get the input to work, meticulously training the system for the six word vocabulary, and such. In the end, the voice recognition didn’t do a whole lot of recognizing. But it was fun, and it was hard, and I learned a lot.

Decent programmers have a good rudimentary knowledge of how computers work. Skillful programming is aided by knowledge of memory allocation, whether the fundamental malloc-and-free management of C, or the garbage-collected object lifecycle in Java. Like a carpenter who knows which tools to use depending on the type of wood on which he works, the more programmers know about the hardware and operating system, the better they are at their craft.

That knowledge doesn’t come from BASIC. It comes from fiddling with the system, from the hardware on up.

If Mr. Brin is serious about teaching his son how to be a good programmer, he’ll give him a computer with GNU/Linux.

Protecting us from ourselves.

The current computer philosophy is simply this: the computer should be unobtrusive. The user should not have to worry about the details, nor be concerned about the inner workings. This is a reasonable philosophy, and an admirable goal.

Like many good ideas, it is being taken too far. Not only do most modern commercial consumer operating systems present a friendly, easy-to-use face; they essentially firewall the user from the hardware, and from the operating system. Apple OS X isn’t too bad in that respect, as they do ship many of the standard tools one would expect with a modern Unix-like OS. But even there, users are discouraged from tinkering.

The MS-Windows approach is even more draconian. There is no easy way to gain access to the lowest levels of the operating system. Not unless you are a programmer, anyway, which kind of defeats the purpose.

The coming DRM dark ages will only exacerbate the problem, locking would-be geeks away from the heart of their systems, relegating them to the Visual Studio wastelands. If Mr. Brin thinks the current situation is bad for future programmers, he should be looking at the future, as well. (That’s an inside joke. David Brin is a first-rate science fiction author, so I assume he thinks about the future all the time.)

Although many of the newer GNU/Linux distributions provide a sleek, fancy, modern desktop with little-to-no user configuration required, the ease-of-use is not a strict policy. A user can simply browse the web and check their email, or they can open a shell, load and unload modules, run a variety of programs, and look at and modify the source of those programs. The can tinker with the source of the operating system itself, if they so desire.

GNU/Linux encourages tinkering by its very nature, but does not require it. (Okay, I admit sometimes it takes a little tinkering, depending on specific hardware support. But that is true of MS-Windows, as well, just to a different degree.) This is a good thing, I think. If this line of reasoning is true, the best geeks of the future will have grown up on GNU/Linux.

The resolution of a dilemma.

Mr. Brin’s son Ben found the sword to cut their particular gordian knot. The purchased a classic Commodore 64 off the internet, and had it running BASIC in a matter of minutes. That is the beauty of the Freedom to Tinker.

And finally, should Mr. Brin install GNU/Linux, here’s a gift for him and his son. Blassic is a fairly simple and very nice implementation of old-school BASIC. Those textbook code samples should run just fine.




aztec cat's picture
Submitted by aztec cat on

You are so right !

Before having this Dimension 4500 that I am writing on, I've had a lot of machines starting with a Vic 20, moving on to a Coleco Adam (remember those ?) then several clones (as they were called at the time) among which the first one had NO hard drive and those clunky 5 1/4 floppies.

Through the years, I learned by reading a lot and using different techniques like programming in Basic and YES, opening up my systems and poking inside, adding and substracting things.

I still remember fondly the nights of applying what I read at the local library and generally having fun.

I remember being startled by the Coleco Adam thinking I was in a gangster shootout when I first used the combination power supply / daisy wheel printer to print something and it let out a loud staccato noise.

I also remember having to reinstall everything on my 40 Meg hard drive after installing too many conflicting things that blew it up (virtually) :)

Now, since I will be retiring soon, I've been thinking of building a GNU/Linux based computer and starting to have fun again.

So yes, I've learned a lot from tinkering and fiddling !

You still can learn if you are willing !

Don't let the consumer driven all-easy machines stop you, get in there and learn !

M. Taylor, in closing I would like to thank you for this article because you made me revisit my younger days and gave me an extra boost to start my retirement project.

Anthony Taylor's picture

Thanks very much. That's the best compliment a person can receive, I think.

Good luck, Mr. Cat. Enjoy your project. Learn. Have fun. Mostly: have fun.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I think you've set David Brin up as a straw man so you can comment on his ignorance in order to drive your point, rather than objectively viewing the situation and the reasons.

I am also from the era of Apple ][, Commodore 64, Archimedes and all of those old computers. I can state that the reason that they were so great to learn on has nothing to do with random fiddling, but because every one of them came with a decent set of documentation.

You could read about them, and then fiddle.

That is not something you can do with (cough) GNU/Linux. Documentation is the scarcest and crappiest resource when it comes to free software, regardless of the ability to tinker with masses of obscure and mostly badly written source code. Being able to rip a PC into its components doesn't help with that problem at all.

David Brin had the right approach of buying an old computer, because then all the old documentation (which was really well written, about simple computing systems) can be read, studied, and understood.

Anthony Taylor's picture

You are close. I set David Brin's situation up as a framework to comment on something I see as a problem in the computer industry: the movement of control from the user to the operating system supplier. Also, I included as a bonus another problem I see: corporations controlling public perception to the point where citizens behave as consumers, and see only the choices offered by corporations. That's not the same as a strawman-- first, it's a valid literary device. Second, it doesn't invalidate my points, as they directly address his situation. Ergo, no strawman. (If I were using him as a strawman, I wouldn't've addresses his issues as all.)

As for the rest: I do believe I mentioned the excellent documentation that came with the Apple ][. You know, the systems manual that had the assembly code for the monitor ROM in it? I loved reading through that code and finding new entry points for my own code.

As far as documentation with GNU/Linux, it is far superior (from a fiddlin' with the computer point of view) to any other system out there. I agree, it's not great. There could be a better effort to document various aspects of the system. But it still beats anything you'll get from Apple or Microsoft, or any other vendor, for that matter. Sure, MS-Office has incredible documentation-- not from Microsoft, but from third-party publishers. Same with MS-Windows. But it's absolutely useless for learning fundamentals.

Bad code? Sure, there's a lot of bad code. There's also a lot of excellent code. Look at Apache, or PostgreSQL, or (if you like C++) Abiword. There's a lot of superior code out there.

Your last point is entirely valid. Computers of the early days were much simpler than the ones we deal with today. That allows learning the fundamentals without distraction from compilers, memory managers, or intrusive operating systems. The solution was elegant, simple, cheap, and will only work for the next few years, while you can still get these sorts of machines off eBay.

Learning on an old Commodore 64 will certainly be fun for Ben, and was probably the best solution. But Brin's argument as written included the false assumption there was no other viable choice. And, I would go so far to say, he would be better off taking his next step up to GNU/Linux, or a *BSD, to learn modern computer systems.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

REALbasic which is free for Linux(but not Open Source) is really worth looking into. It's commercial Pro version sells for $500 USD (regular MAC & Windows versions are $99), and has a very nice IDE. The reason I suggest it is that it is great for creating simple games, something a kid new to programming would have hours of fun tinkering with (comes with lots of samples too, lots more free samples/examples on net).

Free for Linux, very nice IDE, cross platform possibilities & fairly compatible with VB yet will let you run old Basic code as well.

See www.realbasic.com for more info, free downloads (MAC/Windows 30 day trial)

PS I don't work for them but do enjoy the product.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

CHEERS! Great article. I am only 32, but I cut my teeth on an Apple ][ on the old turtle drawing program. I had BASIC training in high school, and still remember my ^KD wordstar shortcuts. I am responding via my openSUSE computer. It has all the latest bells and whistles, including the best 3-D desktop since the Sony VAIO experience. I was able to change a few things, and get it inside out and wrapped around nicely, the way I wanted. I still play games (the twist-a-plot's on the old Apple still hold a special place in my heart), and a great group of people have made it possible to play games written for windows on this contraption.

I believe if more up and coming programmers were required to write software the old way, the software would not be so bloated (if you have to type it all, you are going to look for much more streamlined ways of writing the code, believe me). I run software written for the 486 quite often. On an Athalon 64, it just screams. It is amazing what you can do with these simpler tools, if all you are needing to do is a simple task. Sometimes all the bells and whistles get in the way of just getting the job done. How often do you use vi/gvim or in windows, notepad? They are both great for just getting your thoughts down in print. I still use pine for some generic e-mail tasks, and use it to automate my spam e-mail address functions. I run it in the background, getting my mail from a pop3, and shoving it into /dev/null abyss. If I need to register with a certian web site, I turn it off, get the "congratulations" e-mail, then put it back to work, providing a "No Outlet" "Dead End" sign for all my spam.

Keep up the good work, btw, your article was on my google personalized desktop, and grateful I am that it was.

Thanks, J. R. Fude

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I've been working on a language called 2e (http://lang2e.sourceforge.net), which is a very simple language, but also has some hidden power. It is essentually an expression evaluator, so it can on the surface be used as a an extended form of the "eval" command. But, the expressions can contain variables an variable assignments; plus, the C style inline conditional is included. In addition, I've added an iterative inline conditional; so between the two, you can perform the equivalent to if/else and while/do. Functions are also supported (user-defined, built-in and external).

So, for a learning language, you can start simple and build from there. The current implementation is fully functional, and has a decent built-in function library. I'm working on creating GTK bindings as a loadable module which should be finished in a couple weeks.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

You know, every group has its old man. The guy that talks about the old days. Programming on punch cards. Flipping switches just to here the blender make a smoothie. Fascinating stuff like that.

I completely agree that programmers are losing their connection with the grunt work going on inside a computer. Unfortunately, what's their motivation to do so? I chose to take up a small amount of x86 assembly and ANSI C, but I'm sure I still don't know it well enough to be of any real use.

The job market is looking for people to pound out pretty looking stuff and what's in demand is RAD development with some high-level poop. It's going to get harder and harder to find those kids that enjoy getting down in the kitchen and watching things smoke.

Anthony Taylor's picture

When you learn math, do you learn basic skills first, or do yo just jump straight to the tricks you use for integration? When you learn woodworking skills, do you start off building a fine cabinet, or simply nailing two pieces of wood together?

My point (and David Brin's point, as I understand it) is simply this: if you are going to be any good, you will know the basics. You will understand the foundation of what it is you are doing. Otherwise, you will just be another point-and-click code monkey.

It's not about the old days at all. It's about now, it's about the future. I talk about the old days because people were encouraged to learn back then. Today, even college courses are leaving the basics, and concentrating on products, such as particular development or application environments.

You cannot efficiently and reliably move into the future without a firm understanding of the past. I have worked with younger programmers, and I can tell you with great assurance, those who understood how memory was managed, those who had at least been exposed to assembly language, those who coded by hand, were by far the superior programmers, even when plonked down in front of the Visual Studio the other less-educated coders knew so well.

I'm not simply dreaming of a simpler day. I'm dreaming of a better future through the understanding of computer fundamentals.

Author information

Anthony Taylor's picture


Tony Taylor was born, causing his mother great discomfort, and has lived his life ever since. He expects to die some day. Until that day, he hopes to continue writing, and living out his childhood dream of being a geek.