At the beginning of the personal computing revolution, several pundits suggested that “in the future, schools will teach programming skills the same way they teach reading, writing and arithmetic.” Well, yes and no.

Yes. Many schools are teaching programming skills the same way they teach reading, writing and arithmetic. Badly. (Ask anyone who has taught college level courses for more than two decades about the deteriorating levels of skills we’re seeing from high-school graduates. Of all the dangerous trends in this country, that one has to be the most terrifying.)

And no. Nobody is teaching programming skills as an equivalent to reading, writing and arithmetic, which was what the original assertion predicted. For the average person, programming remains an arcane craft.

Because I’ve had some experience in code wrangling, I regard programming as one of the most profound of all skills a human being can learn, because it’s thinking about thinking. It looks like it’s about code, but on a much deeper level, it’s about the way we think about problems.

Code isn’t just a list of specific steps to take to get from hither to yon, it is the hands-on application of an algorithm. An algorithm is a specific methodology. It is not necessarily the only applicable methodology, and sometimes it isn’t even the best or most appropriate methodology; that depends on the programmer. But if it gets you from hither to yon in a reasonable amount of time (instantaneously), that’s an acceptable result to the user.

In the hands of a skilled visionary, an algorithm becomes a place where philosophy, invention, discovery and sometimes even sheer artistry get mashed together in ways that produce wondrous results, things that not only were not possible just a couple decades ago, but weren’t even conceivable.

The essential building block of an algorithm, the single most important part of any algorithm, is this: If…then….

All programming depends on this single statement. An algorithm is a decision tree, and the if…then... statement is how it makes decisions. Add the ability to do loops, and you have the two essentials necessary for a programming language. (Everything else is procedural mechanics.) While…do… and do…until… lets you drill down to specific cases of if…then…. This was the essence of BASIC.

Pascal was a step up from BASIC. It gave us procedures and functions and eventually object-oriented programming, all of which made it significantly easier to manipulate if…then… and while…do…. We also got the case statement, variable records, and pointers.

Eventually, C became the programming language of choice because it allowed programmers a more powerful grasp on the underlying nuts and bolts. It has since evolved into C++ and more. Other languages have also earned a place on the professional tool shelf, and today the serious programmer has a wealth of options, each suited for specific purposes.

But underneath all of our languages, if…then… remains at the core. A high-level language adds a lot of conveniences and methods and abstractions, but ultimately, it’s still about all those little choices at the bottom and the resulting decisions, three point six billion times a second.

The reason why we do not teach programming skills like reading, writing and arithmetic, is that the average person really doesn’t need to know how to write a program. Somebody else has already written it, probably dozens of somebody elses. It’s already available as freeware, shareware, trialware or even (gasp!) buyware.

And even if the average person needed to write a simple utility not available anywhere else, the learning curve for even a simple programming language can be prohibitive—a cliff, not a curve. By the time he or she learns the language and writes the code and debugs it, the better part of a year will have passed and the need for that utility will have probably disappeared.

Even more to the point, programming is not a hobby that you can pick up and put down at will. Programming is a discipline that requires constant practice; otherwise, like any other skill, it evaporates. (That guitar in your garage, remember?)

But there’s another reason why the average person doesn’t need to learn a programming language. He or she already knows at least one, probably several. Many of the most popular programs in use already include scripting languages. The result is that high-level users are writing their own data-specific code.

Examples: Photoshop allows the user to record and edit complex lists of actions to perform on an image.

Flash is no longer an animation program, it’s a language for producing special-purpose applications, everything from websites to cartoons.

FileMaker Pro isn’t a marvelous database system, it’s a language for manipulating and presenting data according to user-defined conditions.

And then there’s Excel…

Excel is a spreadsheet, a database and a programming language all in one. Constants, variables and functions can be displayed across a table, giving the user the opportunity to see the interrelationships immediately. And while you wouldn’t think to use Excel for string handling, it can do a lot of interesting text-manipulation as well. Complex functions can be constructed in columns or rows, allowing the user to test and debug each step as he or she goes. Charts and buttons can be added and tweaked at length. And if necessary, the user can write even more complex actions in Visual BASIC.

There’s another program worth mentioning here: Microsoft Visio. Visio is for constructing charts and diagrams, such as organizational charts, electrical circuits and even decision trees. In its current iteration, Visio can connect to an Excel or SQL database and update its charts in real time. And while Visio is not yet a programming language, it doesn’t take a visionary to start wondering if some kind of graphic programming language might be possible. Could we build whole programs the same way we design visual decision trees? We could drag and drop special-purpose boxes onto a form, writing specific bits of code as needed. We could zoom in on specific domains or zoom out to see the whole flow. Would this be a good learning tool? Would it be practical for applications?

At the object-code level, a program is just a stream of ones and zeroes. At the assembly-code level, it’s a list of instructions. Everything above that is an abstraction. In the past half-century, our programming languages have evolved into some very high levels of abstraction, so that the average user is working directly with his or her data and rarely with the underlying machinery that manipulates it.

A visual programming language would move us to a much higher level of abstraction. Would that be more or less efficient? I don’t know. Would it make programming accessible to the average user again? We won’t know until we try. But I think that it’s a possibility worth considering.

What do you think?

David Gerrold is the author of over 50 books, several hundred articles and columns, and over a dozen television episodes, including the famous “Star Trek” episode, “The Trouble with Tribbles.” He is also an authority on computer software and programming, and takes a broad view of the evolution of advanced technologies. Readers may remember Gerrold from the Computer Language Magazine forum on CompuServe, where he was a frequent and prolific contributor in the 1990s.