Chris.Bitmead@alcatel.com.au (Chris Bitmead uid(x22068)) writes:
>You don't tell us though what typing has got to do with "systems vs
>scripting". You don't say why a dynamically typed language can't be a
>good systems language (lisp), or a statically typed language can't be
>good at scripting (ML perhaps?)
I note that Unisys (formerly the Burroughs part) have been using a
statically typed 'scripting language' for decades. It's called WFL
(Work Flow Language). Was it ICL whose language SCL (?something Command
Language) was loosely modelled on Algol 68?
Ousterhout wrote:
>> Lisp isn't a good system programming language because it's too hard to
>> write efficient programs
This is a truly weird comment. From where I sit, Lisp is a perfectly
ordinary language with perfectly ordinary data types, and the costs of
operations on those data types follow perfectly obvious rules. Writing
efficient code in Lisp isn't just as easy as writing efficient code in
a high level language (say, Modula 3, Ada, Eiffel) it's pretty much the
*same* thing. You design or select clean data structures, you profile
to find where the time is really going, you tune where necessary (in
Lisp this may involve adding declarations). Like all languages,
- you need to understand your problem
- you need to understand the primitives the language gives you
- you need clean code that the compiler can understand well.
Now, I would love to spit on PERL's grave, but I have to say that the
built in data structures of PERL are a pretty practical set which are
actually fairly close to Lisp. I would say that it is much easier to
write efficient code in Perl than it is in Tcl, simply because you
have better data structure primitives and structuring methods to start
from.
Ousterhout says
>> in it and it doesn't provide good low-level
>> access to machine facilities.
Well, I'm constantly amazed at the people who think 'pointer' types
in C are guaranteed to be identical to machine 'addresses'. Of
course they aren't, and this fact is actually very useful. (Yes
friends, there _is_ a "bounds checking" version of gcc.) There are
quite a few things on this machine (an UltraSPARC) that are not
accessible from C except by calling an external function.
Of all people, Ousterhout should know that Sun have a very nice
Scheme implementation which is freely available. It's called "esh"
(I believe it originally stood for 'embeddable shell' hint hint).
And it offers the smoothest simplest interoperation with C that I
have ever seen. I do wish Sun would either make it a product or
else release the sources so that someone else could. Is the attempt
to pretend that Scheme _can't_ work well with C really an piece of
internal politicking against the ESH people?
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
|