Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...) From: Erik Naggum <erik@naggum.no> 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: <3069681642982192@naggum.no> | [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. #\Erik -- I'm no longer young enough to know everything.