Cameron Laird's personal notes on scripting for Web applications

We launched this page to answer questions from readers of our June 1998 Byte article, "Get a Grip on Scripts". Writing for Byte was quite educational, by the way. As a reader, I'm fonder now (April 1998--but events certainly overtook my comfort) of the magazine than at any other time in its history. It makes me uncomfortable as an author, though. Byte has very strong, top-down editorial development. Nominal authors are brought in late in the process, largely as reportorial "fact-gatherers". The process certainly transformed the principal themes on which we constructed our draft. Many of the words, sentences, and paragraphs in the printed version are not ours. Also, there were cultural mismatches with staffers that I'm still puzzling over. Let me emphasize, though: everyone at Byte has behaved honorably, even generously.

The kicker, "Choose scripting languages for dynamic and maintainable Web apps," perfectly expresses what I was after. From there, I wanted to give those with an MIS background perspective on how scripting--with any of the obvious choices--will make their lives better. Byte's idea was to talk more about technical differences between the languages: how object-oriented each is, who's using a byte-code compiler, and so on. Perhaps that creative tension yielded a better synthesis than either side would have achieved in isolation.

... but fewer URLs. Our drafts had a lot more URLs than the published version.


The published version asserts

One drawback of standard Tcl has been that it lacks code module structures -- except procedures.
I do know about namespaces, of course--'use 'em all the time, myself. I apologize for the confusion this sentence is sure to engender (and thank Chris Nelson for spotting it).

Language choices

The principal languages covered in the article were JavaScript, Perl, Python, Rexx, and Tcl.

We've written more specifically about choosing a particular scripting language elsewhere.


Steve Seidenberg makes the point that "entry level people here [at his employer's find] korn shell easier to learn and maintain." Certainly ksh is almost as portable as the other scripting languages we've featured, for the MKS toolkit provides a good version under WNT. Mr. Seidenberg wonders, therefore, "why korn shell on NT is not mentioned."

First, I quite agree with him that the NT-bound deserve a practical scripting environment to work effectively [give reference to WSH developments]. Not only is MKS's ksh quite reliable in this role, but ksh is certainly capable for CGI work, and it's possible to buy tksh, which gives ksh developers a handy GUI capability. We didn't mention ksh in our article mostly because there's no release for Mac OS. Even beyond that, we were little inclined to mention ksh, because it seems to us

I salute Mr. Seidenberg for the good use he's getting from ksh. As time goes on, I believe he'll want to look into the other scripting languages. His use of ksh certainly sounds as though it's paying off well for now, though.


Örjan J Larsson equally justly asks, "why didnt you make _any_ mention of AppleScript?", then answers his own question, "I agree AppleScript sadly isnt crossplattform."

Our principal aim with this article was to reach experienced MIS workers now missing out on the great opportunities scripting offers them. We particularly wanted to show how unfrightening and secure it can be to begin to "Webify" existing processes. Toward this end, we restricted ourselves to scripting technologies available conveniently in common MIS situations. AppleScript's restriction to MacOS disqualified it. We recognize that, in Mr. Larsson's words, "as an scripting language is it quite good. Used in many web servers, and interestingly, used by many who usually not do either programming nor scripting."

A secondary consideration is that AppleScript is not a general-purpose language. It confines itself rather strictly to scripting (other) applications. This is a design choice that deserves more analysis and consideration than it's received yet. For this article, though, it would have been a distraction for our target audience. Now, the scripting languages such as Python, JavaScript, and so on, which are also suitable for general-purpose data processing, are in the ascendant.




Rich Morin of Prime Time Freeware politely and correctly questioned our remark that in the Programming Republic of Perl, "GUI, Windows, [and] Mac OS maintenance [are] given less attention." We didn't intend by this to slight PTF's MacPerl at all; in fact, we recommend it often, for, as he wrote us, it is a "strong and current port". While Perl's core programming team doesn't appear as committed to Mac OS as is true for their counterparts with Python and Tcl, perhaps it's best just to say that the Mac OS Perl has a different--not necessarily inferior--model of development and maintenance. We've certainly applauded diversity in related contexts.

Getting started

I expect many readers will want to know where to download copies of interpreters for these languages that they can use themselves, and also how to arrange for contractual support, training, and so on. I'll write up these details as I make time. If you have an urgent need, e-mail me.

We've also compared scripting languages in more general contexts, and profiled open-source software, among our other writings.

Perl certainly is in wide use; did you know that there are commercial Web hosts or ISPs which offer access to Python, Rexx, and Tcl?

Cameron Laird's personal notes on scripting for Web applications/