In Praise of Scripting: Real Programming Pragmatism

Ronald Loui, In Praise of Scripting: Real Programming Pragmatism, IEEE Computer, vol. 41, no. 7, July 2008. [Openly accessible draft here]

The July IEEE Computer carries an article arguing for the use of scripting languages as first programming languages, and also arguing for a greater study of what the author calls "language pragmatics" (the original article is behind the IEEE paywall, but you can find a draft that has roughly the same content here). The argument for using scripting languages as educational languages can be summed up by Loui's abstract:

The author recommends that scripting, not Java, be taught first, asserting that students should learn to love their own possibilities before they learn to loathe other people's restrictions.
The bulk of the article is devoted to exploring this basic theme in more depth, and provides an interesting contrast to the arguments in favor of moving away from Java (and scripting languages) advanced in Computer Science Education: Where Are the Software Engineers of Tomorrow? (discussed earlier on LtU here).

Loui spends the latter part of the article arguing that, in addition to syntax and semantics, research on programming language should include a formal study of language pragmatics. According to Loui, a formal study of pragmatics would address questions such as:

  • What is the average lifetime of a program written in language X for programmers of type Y, for a program of type Z?
  • What is the average time spent authoring versus debugging a program in language X for programmers of type Y, for a program of type Z?
  • What is the consumption of short-term memory when programming in language X for programmers of type Y, for a program of type Z?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Open access

LtU usually links to papers that are available outside pay-walls. This is a way to help a good cause, and more importantly it serves the interests of many LtU readers who do not have access to sites that require costly subscriptions.

IS this paper freely available, perhaps in draft from etc.?

Freely available draft

I included a link to a freely available draft within the text of the story. Here it is again. I wouldn't have posted the story at all if there wasn't some kind of free version available (hard to have a useful discussion when most of the participants can't read the article under discussion). I've edited the story to try to give the open access link a bit more prominence.

Thanks. Sorry for missing

Thanks. Sorry for missing that link. I guess now I have evidence to support my hypothesis that I am too tired and should stop working...

What about maintenance?

"What about maintenance? The developers and management were both happy to rewrite code for redesigned services rather than deal with legacy code."

That's the only words in the paper (free version) for by far the most costly part of software lifecycle. Are the authors really serious?

Hard to say

It's hard to say, based on a single comment, just how serious the author was about the "rewrite it from scratch" approach to maintenance. However, if it really does cost less (using a scripting language) to rewrite from scratch instead of tweaking legacy code, then surely that would reduce the cost of "by far the most costly part of software lifecycle". This isn't exactly a brand new idea: Joe Armstrong has previously written about the benefits of (given a sufficiently powerful set of abstractions) writing from scratch even when there are existing solutions that are "almost right". Loui claims that one of the reasons that scripting languages are so useful is that "To script an environment is to be powerfully embedded in that environment." In that sense, I guess you could see Erlang as a "scripting language" for distributed systems.

It'd be nice to see some actual statistics on the cost of rewriting versus modifying for the kind of programs the Loui is talking about. It'd also be nice to see some statistics on the frequency of rewriting verses modification, instead of just an assertion by the author. Hmmm... I guess what I'm asking for is some kind of study of the pragmatics of the "rewrite from scratch" approach to maintenance :-)

Rewrite, but not exactly the same

Rewriting can be the time to remove accumulated cruft, and take advantage of new opportunities to simplify.

- Paddy.

Two quotes from the draft

... every benefit claimed for scripting appears to be genuine (flexibility of typelessness, rapid turnaround of interpretation, higher level semantics, development speed, appropriateness for gluing components and internet programming, ease of learning and increase in amount of casual programming).


...(I too voted to shift from scheme to java in our CS1, over a decade ago, so I am complicit in the java debacle).

Are you subtly suggesting

Are you subtly suggesting that the author might be subject to exagerated enthusiasms ? Or did you have another point I'm not catching ?
Note that some of those benefits are clearly real even if I would take exception to the "flexibility of typelessness" and I'm not sure the increase in amount of casual programming is such a good thing.

Depends on what is being programmed

Untrained grandmothers shouldn't be writing avionics software. Untrained CEOs shouldn't be implementing corporate information systems in VBA or similar.

But there are many top-of-the-software-stack, highly-application-specific things that might be more productively done by a domain expert with limited programming skills (but given appropriate tools), then by a professional programmer/computer scientist who knows nothing about the domain. Indeed, there are many problem domains that are user-specific; for which it would make no economic sense whatsoever to commission a professional to tackle, but which that user might be able to improve by some level of programming.

Assuming that mission-critical or infrastructure software is not being written by the incompetent (and unfortunately there are many degreed and well-paid programmers who are lousy at their jobs, so credentials and/or employment don't always indicate competence)--why do you think ghat "casual programming" is bad?

While I appreciate your

While I appreciate your arguments, as you say yourself, even now a lot of "important" programming is being done by persons that aren't really qualified for it. My definition of "important" being here that the program realized have consequences on the live/work of others without a choice given. While I surely hope that for example medical software is held to an higher standard, we know it's not always as good as it should be.
But the main problem today is that even "casual" programming can have bad consequences on others by the mean of the internet, and bad piece of work with vaunted features tend to spread very fast. We've seen that phenomenon already with PHP for instance.

Anyway, I think most "casual" programming while not bad in itself shoud be done in sandboxes or isolated devices. And I would prefer that this casual programming be done with languages that favor a secure style of programmation and enforce a minimum of rules, contrary to most script languages currently (PHP being one of the worse of its kind).

Are you saying...

...that lots of sloppy code is written in PHP, or that PHP itself is a sloppy design? Or both?

I'm not sure that PHP in itself is a major problem. While PHP the language is fast and loose in many ways (lots of implicit type conversions, not terribly modular); it the places it is used, it's just "glue" between a webserver and a RDBMS; both of which have security models not easily subverted by poorly-written PHP programs. I've not heard reports of buggy PHP programs causing the runtime to exhibit undefined or exploitable behavior; the language doesn't appear to permit its abstractions from being violated anywhere near as easily as C/C++.

Not that I like PHP (I consider it the open source equivalent to Visual Basic--not a compliment)--but bad code written in PHP is not as risky as bad code written in C.

PHP is secure in the

PHP is secure in the original sense of the word - semantics not impacted by hardware choice - not in the more modern sense. As most of what you care about in systems running PHP is accessible by the PHP process, this latter sense is critical. *Because* it is the VB of the open source community, it has encouraged non-traditional developers (eg., designers) into the server-page community: before PHP, it was all perl/cgi. I'd hope for even more hand-holding by the language and libraries because of this easy-to-use intent!

While no longer as true (but still to a great extent), PHP encourages sloppy code when gluing a web server to the RDMS in terms of security. This can and does break data integrity and confidentiality on the server (injection), and anything on the client (XSS). As a similar problem, there are/were also many cases of exploits to inject malicious files through the modularity mechanisms (dynamic includes, etc). Every year, the security community publishes new analyses to detect this stuff in PHP, and while fun to read, it's hard for me to believe addressing it at the language level wouldn't eliminate most instances of these problems, and without the effort many/most developers already traditionally forgo in running these analyses.


From the draft:

Already by mid-decade, the shift from scheme to java as the dominant CS1 language was complete, and the superiority of c++ over c was unquestioned in industry.

(It's not super-clear what decade the author's referring to, but the previous paragraph talked about 1996-1998, so I guess it's the 90s)

Was Scheme ever the "dominant" CS1 language? I wasn't around in the 1990s, but the school I went to used Pascal until around 1995, then C with iostream (which is what I learned).

Indeed, we too were taught

Indeed, we too were taught Pascal. This was a required course for both CS students, and non CS students. The first CS specific course (well known for being the weeder) was then Dylan (Mac campus), a Lisp variant. It strikes me as unfortunate that the emphasis in this debate sounds like the question what is the language we should teach our CS students. I would hope it would be, what are the languages we will teach them. It would seem best to have one of each major discipline represented, perhaps the first one taught could just be chosen chronologically... Lisp? ;)


The types of questions groups here under "pragmatics" were discussed here many times, and it was practically agreed by everyone that research on them is needed. While I find the term "pragmatics" misleading, I can even let that slide.

The real issue is that doing empirical research on software engineering, let alone language use, raises a whole slew of methodological difficulties, most of which computer scientists are not trained to address (e.g., language is but one factor in all these questions, and language choice itself reflects other issues). I actually collected material once for writing a paper about the problems associated with such research, but even that project proved intractable...


I agree that the term "pragmatics" perhaps isn't the best choice. However, Loui justifies it with the following:
Linguists recognize something above syntax and semantics, and they call it "pragmatics". Pragmatics has to do with more abstract social and cognitive functions of language: situations, speakers and hearers, discourse, plans and actions, and performance. We are entering an era of comparative programming language study when the issues are higher-level, social, and cognitive too.

I agree also that these types of questions have popped up here a lot. That was one of the reasons I thought that the LtU community might be interested in what Loui had to say.

I don't have any particularly good ideas for addressing the methodological issues myself. I assume that we could probably learn something from the linguists who carry out research in the pragmatics of natural languages, although I'm sure some of the issues arising in the context of programming will be quite different than anything a linguist has to deal with.

It is definitely

It is definitely interesting. By criticizing the approach I wasn't criticizing the LtU-worthiness of the story...

As for pragmatics: the syntax/semantics/pragmatics model, especially if understood hierarchically (see the use of "above" above) is rather problematic and antiquated in linguistics itself, and more so in the philosophy of language. When linguists talk about pragmatics these days they are much more precise than the vague description you quoted above. This is one reason I objected to this terminology. Second, by using this classification one is implicitly suggesting that the issues involved are linguistic (i.e., this is about linguistic pragmatics: the pragmatics of linguistic expressions etc.). But many other, non-linguistic, issues play an important role as well.


I have to admit that I'm fairly ignorant of linguistics, and had never heard of this particular use of the term pragmatics. Thanks for insight into the current status of pragmatics within modern linguistics.

From the archive

A couple of previous discussions may be of interest #1 (from 2001, where I mention the lack of attention to pragmatics), #2, #3.

Scripting, or the right language for the right audience?

Is the author more concerned about scripting, or the right language for the right audience?

"Teaching languages" come to mind here...

Gawk for AI

To lift a quote:

I reported in SIGPLAN 1996 (Why gawk for AI?) [Classic Papers on Scripting] that only the scripting programmers could generate code fast enough to keep up with the demands of the artificial intelligence laboratory class. Even though students were allowed to choose any language they wanted, and many had to unlearn the java ways of doing things in order to benefit from scripting, there were few who could develop ideas into code effectively and rapidly without scripting.

Ronald P. Loui's earlier work (the aforementioned Awk paper) was previously discussed on LtU here and here.

Thanks for helping maintain

Thanks for helping maintain the continuity of the LtU archive!