When personal computing started—before it was even called personal computing—there were only two options for programmers: assembly language or BASIC.

In those days, most of the programmers writing assembly language had graduated from college with a degree in computer science. They were like Zen masters who understood the soul of the machine. Assembly language was a direct line to the heart of the computer: It produced the smallest and fastest code possible. You wrote your code, you ran the compiler that turned it into actual executable, and then after it crashed you went back to your code for debugging. And heaven help you if you hadn’t commented your code; tracing through assembly code could be mind-numbing.

But for people who hadn’t taken courses in computer science, assembly language had an impossible learning curve. You had to think in terms of storing bytes in registers, fetching them, shifting them, and doing things to them that had no references to the real world. Like XOR, for instance. XOR is not something you explain, it’s just something you do after you learn how to do it—like riding a bicycle.

BASIC, on the other hand, was so easy to learn that a child could learn it in an afternoon. Most of those who used BASIC were self-taught beginners. It worked for them because the challenge of programming was reduced to a set of easy-to-understand concepts. The user only had to understand that variables could be diddled; you can do a lot of interesting diddling with nothing more than a FOR…DO loop and an IF, THEN statement. Best of all, you didn’t have to compile it. You just typed RUN. If the BASIC interpreter crashed, it would tell you exactly which line contained your syntax error. BASIC was easier to debug.

But BASIC was an interpreted language. Every line of code had to be decoded step by step and transformed into machine instructions by the underlying engine. For simple applications, BASIC was wonderful, but an 8-bit Z-80 machine running at 4MHz had its limitations. If the task was complex enough, you could watch the computer chug methodically through its calculations, slowly painting its results across the screen. BASIC also lent itself to sloppy “spaghetti code.” But despite all that, it introduced a whole generation of beginners to the world of programming.

The gap between speed and ease of use was a hotly discussed issue in most of the computer magazines of that era. And it went on for several years. It was a symptom of the difference between those who had come to personal computing from refrigerator-sized machines and those who were coming to it from typewriters.

SUBHED: Enter Pascal
The discussion also included an interesting alternative: Pascal. The Pascal language had been created by Niklaus Wirth in the late 1960s. He published it as a teaching language, which may have been a critical error, because Pascal was much more than a learning tool.

One of the more interesting aspects of Pascal was that it was a “write once, use many” system. The compiler would produce results usable across a wide variety of systems. The Pascal compiler didn’t produce assembly language, it generated P-code. You only had to compile your program once, and then any machine with a P-code interpreter would be able to run it. (Does this sound familiar?)

P-code wasn’t as fast as assembly language, but it was much faster than interpreted code. It was a compromise between the two, an attempt to bridge the gap between ease of use and faster-running executables. As interesting as Pascal promised to be, there was no convenient iteration of it for the microcomputer.

But then, in 1981, the game changed almost overnight. Borland introduced Turbo Pascal, selling a disk and a manual for a very reasonable US$50. Within months, Turbo Pascal became the most popular language for software development on microcomputers.

Turbo Pascal was written by a brilliant young programmer named Anders Hejlsberg. Its most compelling feature was that it didn’t generate P-code, it generated object code for the Z-80 environment, making for immediately executable programs. The resultant programs were faster than BASIC, faster than P-code, and nearly as fast as hand-optimized assembly language—fast enough that the ease of use far overwhelmed most concerns of code size and speed. And if speed was an issue, you could still write your critical routines in assembly language and include them into your Pascal program.

The user interface was equally remarkable, as easy to use as BASIC. The editor and the compiler were the same executable. You wrote your code, you pressed F9 to “make” (compile), and the program compiled in seconds and ran immediately. If it crashed on compile, you were delivered to the critical line. Later versions included a sophisticated debugger.

Turbo Pascal made it possible for beginners to learn structured programming easily. It was equally practical for experienced programmers to create powerful applications of all kinds.

As a “procedural” language, it was a programming environment that expanded with you. You didn’t just write code in Pascal, you extended and customized the language. As you wrote your various procedures and functions, you were building a personal menu of tools that you could reuse in any subsequent project. That wonderful menu system that you wrote for your address database? You can reuse it immediately in your record-collection database. Turbo Pascal encouraged you to create whole libraries of reusable functions and procedures. And if you needed more than you had time to create on your own, you could even buy whole libraries of add-on units.

To a great degree, Turbo Pascal was also self-commenting. BASIC limited you to variable names all the way from A1 to Z9. After a five-minute potty break, you had to reacquaint yourself with your own code. But Turbo Pascal let you give your variables names that made sense in the larger context of your program.

While Dilithium_Crystals > 0 Do
Warp_Speed := Warp_Command
Else
Report (Scotty, “Cap’n, I canna give you nae more power!”);
 
That’s a lot easier to follow and debug, isn’t it? We take it for granted today, but it was a breakthrough in 1981.

SUBHED: Turbo Pascal’s demise
Throughout the 1980s, Hejlsberg continued to expand and improve Turbo Pascal, adding powerful new features with every release: an integrated debugger, external libraries, case functions and variable records. (I once asked Anders how he managed to speed up the compiler and the executables with every new version. He said he took out the wait states.)

With release 5.5, Turbo Pascal evolved into an object-oriented language. After that, there were several versions of Turbo Pascal for Windows, then it became Borland Pascal and eventually part of the Delphi Rapid Application Development system—still available, but not exactly a tool for beginners or hobbyists anymore.

Somewhere on that long evolutionary path, Turbo Pascal disappeared—not just the product, but the concept of an accessible, easy, powerful, all-purpose programming tool. Most professional programmers have more sophisticated needs, of course, but for the hobbyist, the beginner, the teenage enthusiast, the kid who wants to write his own game, the weekend warrior who wants to write his own application—there’s no easy or obvious place to start.

It may be that the need for a Turbo Pascal kind of programming tool has evaporated.

If you need a quick-and-easy utility of any kind, it’s easier and faster to Google around and find that someone else has already solved that same problem. In fact, a lot of people have probably solved it. Your biggest challenge will probably be finding the one that best serves your specific need.

And many of our high-level tools have become programming environments in their own right. Excel isn’t just a spreadsheet, it’s a whole programming system, with every cell either a variable or a function. And if that isn’t enough for what I want to do, I can use Visual BASIC to create action-specific scripts and buttons.

If I need a special-purpose database, with an interface I design myself, I don’t have to build it from scratch. I can create it quickly in FileMaker Pro, expanding it as I go with action-specific scripts and buttons to call them.

Even Photoshop lets me create scripts to accomplish complex and sophisticated image-processing procedures. A single click on a multiple-step script can perform hundreds of actions; I can turn a photo into a comic-book drawing in seconds.

Other tools, like Stardock and Rainmeter, will let me redesign my Windows interface. And over here, on the recreational side, a lot of games—like Warcraft III, StarCraft II, DOOM and Halo—come with powerful editors so gamers can create their own mods, or even whole new games.

And finally, Minecraft isn’t even a game at all; it’s just a place where you design your own environments and the interactions within.

Nevertheless, despite all of the various scripting tools, there are still days when I wish I had a fast-and-easy programming environment for Windows, a contemporary equivalent of Turbo Pascal, something I can use for quick coding a specialized utility or even a simple game idea.

At the dawn of the age of personal computing, the idea was put forth that the common man was finally getting control of the computer, that we were getting rid of the dreaded computer priesthood. But 30 years later, it’s apparent that we did not. We just traded one priesthood for another.

The disappearance of Turbo Pascal and many easy-to-use tools of creation may be costing us that critical sense of achievement and power that comes from the ability to reinvent the computer to be what we want it to be—to create our own tools and toys. Yes, having ready-to-use solutions is easy and convenient, but are we losing the skill to look at things from a meta-position?

Programming isn’t just a skill, it’s a way of thinking about solving problems. It’s an intellectual discipline of the highest order. You can see it in the way professional coders talk and think. Writing code is a strenuous workout in the gymnasium of the mind. Programmers tend to be smart, disciplined, focused, pragmatic and results-oriented. (And occasionally arrogant, self-righteous, and pig-headed too, but that’s a different conversation.) (I do not exempt myself.)

I could be wrong (it wouldn’t be the first time), but I wonder if there might be a place for a new “Turbo Pascal,” something fun and seductive and powerful in its own right, easy enough for beginners to understand, but powerful enough for experienced users to create a useful application in a few hours or a weekend.

If a beginner came to you today, what would you recommend?

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.