madison

Programmers: Otters with rocks?

Stephan Somogyi | May 10, 2001 12:00 AM PDT

Summary

Will ordinary users ever build their own software tools?
COMMENTARY--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 whethera branch taken was faster than an untaken one (which depended onwhether it was a short or long branch). I ultimately had to be forcedto learn a higher-level language -- Modula-2 -- since I was perfectlycomfortable with what I was doing, and felt that I was plentyproductive.

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

Programming for programmers
We've seen programming languages develop increasingly greaterdistance from the hardware they're meant to control. C provided alevel of abstraction above assembly language, and C++ bolted numerousextensions onto C, creating what many consider an unwieldy monster.Having been witness to quite a few mind-curdling discussions during thepast 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 somewholesome goodness of its own. While it really hasn't caught on asthe write-once-run-anywhere language it was initially touted as, ithas 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 anyearthshattering leaps forward into the world of computing.

RealBasic isan interesting phenomenon, mainly because it seems to be a bridgetool that sits between GUI-based, erector-set app constructionsystems, and an object oriented development environment. The downsideof RealBasic is that seems to be no end to the number of advancedscript kiddies releasing "new" text editors and similar apps that inreality just use the core features provided with the developmentsystem's runtime. This is hardly innovation. On the other hand, theupside of a tool like RealBasic is that it lowers the barrier toentry for programming and lets people build tools to make them moreindividually productive.

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

Now this is what I call productivity.

Moore's Law and clever developers have bestowed upon us high-levellanguages that allow us to concentrate on the problems we need tosolve, rather than spending the effort to sure we've initialized allthe necessary subsystems of the OS appropriately before we evenbegin. With the abundance of compute power, the overhead involved ininterpreted languages has shrunk down to negligibility for manytasks, and the amount of time gained by being able to use theselanguages instead of lower-level ones is huge.

Perl and Python are well-known and well-regarded, and Ruby isgrowing in popularity and props outside of its native Japan as well.ECMAScript (aka JavaScript) is in heavy use by Web designers withoutprogramming backgrounds, often to good effect. AppleScript, whileplatform-specific, is nonetheless mighty useful on that platform. Theuse 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 madeprogrammers out of gamers who might otherwise never even thoughtabout software development.

As Sweeney's essay points out eloquently, language choice influenceshow one approaches certain problems. But a programmer with a solidbackground in algorithms and data structures probably won't care toomuch about which of several roughly functionally equivalent languagesis chosen for a project. That programmer is, however, likely to bemore interested in choosing a language with a large library of easilyaccessible source code, in order to avoid wasting time reinventingwheels.

Assaulting mollusks
Even with today's high-level languages, I still feel like an otteropening a clam with a rock. With enough skill, dexterity, andperseverance, I'll open the shell, but it's still a far cry fromhaving a good clam knife and a pair of hands.

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

While we're waiting for The Next Big Leap In Programming--whichhopefully will be useful to ordinary mortals as well as professionalcodesmiths--I guess all we can hope for are better and moresupportive development and debugging tools for the high-levellanguages we already know and work with. Indeed, it's moderndevelopment tools for these languages that are in many instancesstill sorely missing.

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

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

Talkback - Tell Us What You Think

Formatting +
BB Codes - Note: HTML is not supported in forums
  • [b] Bold [/b]
  • [i] Italic [/i]
  • [u] Underline [/u]
  • [s] Strikethrough [/s]
  • [q] "Quote" [/q]
  • [ol][*] 1. Ordered List [/ol]
  • [ul][*] · Unordered List [/ul]
  • [pre] Preformat [/pre]
  • [quote] "Blockquote" [/quote]

The best of ZDNet, delivered

ZDNet Newsletters

Get the best of ZDNet delivered straight to your inbox

Facebook Activity