firstname.lastname@example.org (John Ousterhout) writes:
>2. Many people objected to the fact that their favorite programming
> was left out of the white paper. Yes, I have heard of Scheme,
> Smalltalk, ML, etc. I left these languages out because they
> didn't seem particularly relevant for the discussion. No offense
Lisp having been used as a scripting language for a lot longer than TCL,
it was a *relevant* omission. (Yes, I have used Lisp as my command and
scripting language, and yes, it was before TCL.)
> - It is possible to make languages with execution speeds like C or C++,
> that use dynamic typing successfully, whilst being high-level enough
> in the creation of abstractions to "glue" things together quite
> nicely and easily.
>Can you point to a specific language and identify a large community of
>users who agree with this assessment?
But restricting it to a large community smuggles in another criterion:
marketing. SELF, for example, has dynamic typing, and published benchmarks
show it close to C or C++. I imagine people at Sun would understand more
about SELF than I do. I've certainly had Scheme code perform close to C
(with the aid of comilers that do a fair amount of type inference, admitted.)
I would also expect someone from Sun to be aware of the awesome ease of
interoperability with C/C++ offered by ESH.
>Either you have a strongly typed language, which gives high
>speed and manageability but makes gluing hard, or you have a weakly
>typed language with the opposite properties.
This is clearly false. You can have a language with *optional*
declarations which can be checked and relied on if they are there.
Mercury programs, for example (a statically typed language) can usually
by run by NU Prolog (a dynamically typed language) if you erase the
declarations. Common Lisp type information is optional. There are
people currently designing a type system for Erlang (Ericsson's
functional + concurrent language); that will be yet another example
of a system with optional declarations for speed and static checking
yet able to run without them. (Henry Baker has a paper on a type
inference algorithm for Common Lisp types.)
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.