He touches on a number of things that bother me about technology today. The biggest is the " New is good and Old is bad" idea that seems to be in the subconcious of every person in the tech industry. Things are discarded because they are old instead of because they don't serve a purpose. New things are added because they are New, not because they serve a valid purpose.

I am in a position that I evaluate the IT skills of computer techs. I have found that a good knowledge of DOS is a flag that marks a better quality technician. They understand that the GUI is just a pretty picture and that something else is going on under the hood. They new techs have never seen an "Old" command prompt and they believe everything they see in a window.

I feel that a big problem is that computers aren't really processing machines anymore. You have to babysit them now. I used to run a CAD service starting in the DOS days and ending up in the Win 95 era. In DOS it was a simple task to throw hundreds of CAD drawings into a directory, do 30 seconds of setup, and then type a batch file name and then walk away while the equipment did all the work. It was easy to string lots of automated tasks together. Now computers require you to sit in front of them and click on everything. You can't walk away and have it do the work. The only way past this deficiency is to have a programming project for every different task.

( We still automate processes using DOS batch files in XP because IT WORKS!)

BTW - I read the whole article before realizing who the author was. Only thing I would like him to add is another Uplift novel!

I think just as important as having a simple language is having a computer that is 100% okay to rip apart, break, or otherwise have non-working at any given time. That's part of what makes buying the Commodore 64 such a nice solution.

These days the main computer of the house is needed as a communication and media device. It's hard to take too many risks when you might destroy data you need or not be able to check e-mail later in the evening. But with a cheap computer (even a modern one) reserved for hacking use, all is well. If you get stuck, you can go to your main "appliance" computer and google for answers.

The WW2 era kids "hacking" on their jalopies in the garage weren't taking apart the family car, after all. Having the junker free for experimentation is what makes it liberating.

Since I came up through comp sci in the late '70s/early 80's, our computer science department required us to do all the math and the low-level programming. They wouldn't teach COBOL, for example; not applicable to comp sci in their opinion, though they taught FORTRAN, Pascal, C, assembly, etc. We had to learn how to bootstrap a PDP-11 from scratch.

We were also required to take many upper level courses that cross-listed with applied math. And as a woman (and often the only one in the class), it was also disappointing to see how comp sci and mathematics was out of balance between men and women - but that's another issue.

The one thing I now notice in my middle age is that newer programmer/analysts don't have a grasp of the fundamentals behind what they are coding - exactly what the article pinpoints. It's frustrating to me to have to explain to someone with a comp sci BS how underlying principles of design for databases and languages work. So it seems this is endemic even in some universities, which is frightening. Not to mention the interfaces with the OS and tuning issues - I work in a UNIX environment, but the developers normally code on Microsoft platforms.

I love the suggestion of an older machine as a tool for my daughter. I'll be surfing on e-Bay today! Thanks for a great article!

The key line to this article appears near the end:

...they seem bent on providing information consumption devices, not tools that teach creative thinking and technological mastery.

For me, learning BASIC, FORTRAN, PASCAL, COBOL, etc., on punchcards in the early '80s was invaluable in my later computer career. The thing most people ignore about creativity and innovation is that it's based in logical possibilities. Learning the underlying logic of a thing, whether it be programming, biology, physics, pigments, whatever, gives you a window into more possibilities.

Understanding how things work on the basic level makes you more capable of seeing everything that can be done. It's the source of my own innovation in the workplace, and I'm sure of many others. It also gives you better powers of discretion and design in creating your own programs and "art" in whatever field you work. Today, when computer programming extends into nearly every field, it is essential to know what that programming is based upon when designing it to meet your needs. There's the flip side of this, too, in that deep understanding in any discipline is frequently applicable to another. Understanding systematics from biology opened up flexible ways of organizing information in databases, and taught me that how the data was organized and presented would determine the direction of future development and research.

To answer the question, Should artists grind their own pigment? Well, obviously not all artists need to do that in their daily work. But they should all know how to do it, if they want to be fully capable of instantiating their vision. Understanding pigment - and programming - means being aware of everything you can do, not just everything you've seen done.

An interesting article, on a topic that has troubled me as I've become part of the gray-haired programming set.

I know the same line of argument was made by those who worked with machine code or assembler and didn't have the benefit of a "high-level" language such as BASIC, but Mr. Brin is correct -- BASIC at least revealed the underlying logic of the system in a fairly transparent way.

That knowledge is already missing in a wide swath of working developers. The modern languages give them the power to create without understanding, which is fine, until something doesn't work. Another gift of BASIC was that it taught programmers how to isolate problems and debug them. Depsite the much more advanced debugging tools available, many developers lack the logic skills to employ them properly.

Perhaps the answer is an open source software project to create an OS-independent BASIC command line programming environment. It will give us old guys a chance to revisit our GOTO roots and maybe help seed the next generation of alpha geeks.