I like what John Ousterhout has done for the history of computer science. I had a chance to exchange notes on Tcl with him when he was at Sun Labs. Over the years I lerned that Rabit holes stifle innovation. The ability to rapidly prototype and prove a concept is a key element in utilizing Tcl. I personally prefer to prove a concept with a language that I can prototype with, such as Tcl, 100x faster than a systems language. The pace of invention moves too fast to ignore this advantage.

The criticism that there is no straightforward way to divide programming languages by whether they are compiled or interpreted is correct. But in my eyes, Ousterhout's point wasn't to divide languages into two camps. He correctly observed that some languages outperform others in system desgin, and others outperform others in supportive roles. There is no single language to rule them all, and that's the beauty of our craft.

> in my eyes, Ousterhout's point wasn't to divide languages into two camps.

But that is exactly what the word dichotomy implies. If he wasn't dividing languages in camps, there is no reason why there couldn't be a single language to rule them all, and the dichotomy reduces to an observation of the programming languages available at the time, instead of a general, inherent characteristic of programming languages.

Also, what is beautiful about not having a single language? A single language is, prima facie, much more elegant.

Single language in one codebase is indeed elegant, and so is interop between languages. The nature of software that leads us to using different languages for various jobs means that developers will keep coming up with new languages, and these languages will have a chance to see the light of day.

In my view, a scripting language is one thing, and one thing only -- a language designed to run scripts. And scripts are lines of computer code that are used to automate another application, and usually intended to be written by an end user (or power user, or their support personnel).

Based on the above definition, lets look at some examples:

* Communications App scripting (the scripting languages used on programs such as Procomm or Crosstalk, or the old log in scripts used on Trumpet Winsock). These obviously automate something the user would normally have to do manually.

* Game scripting engines

* Shell scripting -- this one is a bit tough. Most shell scripts are simple automation that replaces typing in several lines of commands. But some of them can be considered mini applications themselves.

Now, based on the intended use (short, quick programs that doesn't take a lot of programming skill to create), these languages typically are interpreted, have dynamic un-typed variables, and little to no boilerplate or setup code.

* Perl / Python / Ruby -- These I would classify as application languages, that happen to be interpreted. And because they are interpreted (like most scripting languages are), they have access to features that make scripting languages easy to use, such as dynamic un-typed variables and a loose syntax.

What does Perl/Python/Ruby have that other scripting languages ike Tcl, Erlang and Lua don't? It seems a bit arbitrary to label those as "Application" languages.

The main thing is that they are stand-alone. Erlang is also stand-alone, so I would put that more in the application category. Initially, Tcl and Lua were designed to be attached to other programs, so they would be scripting languages.

Of course, this doesn't mean that a scripting language is necessarily missing certain things that an app language has in it, this just means that the design decisions were being driven by the intended use of the language. And in some cases (such as Tcl and Lua), they were designed with more functionality than typical scripting languages, so they can also function as a standalone application language.

Given Stallman's background with Emacs and lisps in general, the idea that he doesn't understand the idea of implementing a program in two languages is pretty hilarious.

Upvoted your comment. I personally lean more towards the LGPL side than BSD/MIT when I can. So it wouldn't be unreasonable to expect me to side with Stallman's view quite often. In spite of that I find this Tcl vs Guile flame wars as a distinct low point in the permissive licenses eco-system / cultural history. I cannot see anything good that came out of it. I will however qualify my disapproval a bit, may be the fear that Sun would exert and impose unwelcome control was a real one at that time, I wouldn't know. So my (easy, lazy) criticism is of course from the privileged position of hindsight.

I think that in 1998 the dichotomy was mostly true. The modern landscape is very different, though. Taking Java as an example (or C# as a similar cousin) it only fulfills some of the systems language stereotypes (correctly so, as it is not a systems programming language). However, if fails to fulfill all of the scripting language stereotypes. It simply doesn't fall into either camp. Where does Go fit in? It's not "statically typed" in the 1998 sense of the classification.

C# and Java both fall into the top 10 most used languages. Java being #1 in some studies. If two of the most widely languages can't fit into one of the two camps the idea must be obsolete.

The modern situation seems to be more of a spectrum. Ousterhout's dichotomy is now an artifact of a past fact.