Commentary: The next big leap in programming

When I first began programming, I wrote software in 68k assembler. I was one of those hardcore cycle-shavers who knew the fastest way to clear a data register was with a moveq rather than a clr, or whether a branch taken was faster than an untaken one (which depended on whether it was a short or long branch). I ultimately had to be forced to learn a higher-level language -- Modula-2 -- since I was perfectly comfortable with what I was doing, and felt that I was plenty productive.

Reading Unreal developer Tim Sweeney's exegesis on programming languages about a year ago brought back many memories. Having recently re-read it, it started me thinking about what the next step in programming language evolution is going to be.

Programming for programmers
We've seen programming languages develop increasingly greater distance from the hardware they're meant to control. C provided a level of abstraction above assembly language, and C++ bolted numerous extensions onto C, creating what many consider an unwieldy monster. Having been witness to quite a few mind-curdling discussions during the past few years about what a given snippet of C++ really means, C++ evokes in me parallels to esoteric numerological interpretation. Clearly, this is not Programming for the Rest of Us.

Java was meant to take all the desirable bits from C++ and add some wholesome goodness of its own. While it really hasn't caught on as the write-once-run-anywhere language it was initially touted as, it has found great favor as a server-app development language. Microsoft's C# is a direct response to Java, with a similar C++ derivative design philosophy, but not likely to bring any earthshattering leaps forward into the world of computing.

RealBasic is an interesting phenomenon, mainly because it seems to be a bridge tool that sits between GUI-based, erector-set app construction systems, and an object oriented development environment. The downside of RealBasic is that seems to be no end to the number of advanced script kiddies releasing "new" text editors and similar apps that in reality just use the core features provided with the development system's runtime. This is hardly innovation. On the other hand, the upside of a tool like RealBasic is that it lowers the barrier to entry for programming and lets people build tools to make them more individually productive.

Let the machine do the heavy lifting
A few years back, I needed to perform some data analysis on several gigabytes of Web server logs. I had neither the time or the inclination to write the necessary tool in C or C++. I remembered that Perl was actually an acronym for Practical Extraction and Reporting Language, so I did a little research, downloaded Perl, trial-and-errored my first Perl script, and crunched the logs my way before the day was out.

Now this is what I call productivity.

Moore's Law and clever developers have bestowed upon us high-level languages that allow us to concentrate on the problems we need to solve, rather than spending the effort to sure we've initialized all the necessary subsystems of the OS appropriately before we even begin. With the abundance of compute power, the overhead involved in interpreted languages has shrunk down to negligibility for many tasks, and the amount of time gained by being able to use these languages instead of lower-level ones is huge.

Perl and Python are well-known and well-regarded, and Ruby is growing in popularity and props outside of its native Japan as well. ECMAScript (aka JavaScript) is in heavy use by Web designers without programming backgrounds, often to good effect. AppleScript, while platform-specific, is nonetheless mighty useful on that platform. The use of application-specific languages like Lingo and ActionScript is on the rise as well.

Finally, I'd be remiss if I didn't mention UnrealScript, which I'm certain has made programmers out of gamers who might otherwise never even thought about software development.

As Sweeney's essay points out eloquently, language choice influences how one approaches certain problems. But a programmer with a solid background in algorithms and data structures probably won't care too much about which of several roughly functionally equivalent languages is chosen for a project. That programmer is, however, likely to be more interested in choosing a language with a large library of easily accessible source code, in order to avoid wasting time reinventing wheels.

Even with today's high-level languages, I still feel like an otter opening a clam with a rock. With enough skill, dexterity, and perseverance, I'll open the shell, but it's still a far cry from having a good clam knife and a pair of hands.

Perl 6, for example, is under development, and despite all the whizzy new features it's going to have when it's done, it'll be an evolutionary refinement of today's Perl and related methodologies rather than a knock-our-sneakers-off change.

While we're waiting for The Next Big Leap In Programming--which hopefully will be useful to ordinary mortals as well as professional codesmiths--I guess all we can hope for are better and more supportive development and debugging tools for the high-level languages we already know and work with. Indeed, it's modern development tools for these languages that are in many instances still sorely missing.

I have no idea what the next generational leap in programming will look like--and am certainly curious to hear your opinions in the TalkBack section below--but if it provides as much of a boost over the Perl generation of languages as Perl does over 68k assembly, then I'll be happy as the proverbial clam (who, presumably, isn't under attack by a determined otter).

Given the choice, ZDNet columnist Stephan Somogyi typically prefers analog pursuits over digital ones.