Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
From: Erik Naggum <>
Date: 1997/04/10
Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.lang.functional,comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang.eiffel
Message-ID: <>

| [posted and mailed]

the header "mail-copies-to: never" was supposed to discourage discourtesy
copies.  if you wish to be kind and helpful, wait for people to ask you
mail them copies before you do it.  otherwise, you just bother them
needlessly.  receiving this gunk of yours twice has not helped, either.

* Erik Naggum
| languages have more than one implementation.  perl doesn't.  does Tcl?

* Douglas Seay
| If I understand you correctly, you are saying that the definition of a
| language (as opposed to a tool) is multiple implementations?

I cannot fathom how you could draw that conclusion from what I wrote, but
since you would have asked how I define languages to the exclusion of mere
tools if you were able to recognize when you overstep your understanding:

languages exhibit the property that they have more than one implementation.
languages exhibit the _defining_ property that there is a specification of
the syntax, semantics, etc, apart from any implementation; or, briefly,
that specification is superior in importance to implementation.  tools
exhibit the property that their input or control languages are inferior in
importance to the implementation and thus subject to change according as
changes to the implementation are deemed necessary.

| This might be ancient history, but was there a formal specification of
| COBOL, FORTRAN or APL before the first implementation?

no, languages didn't evolve ex nihilo in ancient history.  that's a trait
of modern languages.  languages naturally evolve from useful tools with
user experience.  one reason to favor a language specification over just
the implementation is that more programmers can take part in the language
design process than just the colleagues of the designer, the merits of the
design can be discussed outside of the scope of the implementation, the
specification can be a source of much-needed stability as implementations
grow, bugs in the implementation can be bugs in the implementation instead
of random "features", etc.

the rest of your article is below the threshold of hopelessly stupid.

I'm no longer young enough to know everything.