

Ousterhout's Dichotomy - marktangotango
https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy

======
meeper16
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.

------
amadeusw
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.

~~~
andreasvc
> 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.

~~~
amadeusw
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.

------
derekp7
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.

~~~
wrenky
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.

~~~
derekp7
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.

------
technomancy
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.

~~~
srean
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.

------
zamalek
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.

