Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!utah-cs!shebs
From: shebs@utah-cs.UUCP (Stanley Shebs)
Newsgroups: net.lang
Subject: Re: Efficiency of Languages ?
Message-ID: <3494@utah-cs.UUCP>
Date: Tue, 22-Oct-85 15:30:33 EDT
Article-I.D.: utah-cs.3494
Posted: Tue Oct 22 15:30:33 1985
Date-Received: Thu, 24-Oct-85 06:04:52 EDT
References: <15100004@ada-uts.UUCP>
Reply-To: shebs@utah-cs.UUCP (Stanley shebs)
Organization: Univ of Utah CS Dept
Lines: 44

In article <15100004@ada-uts.UUCP> richw@ada-uts.UUCP writes:

>First of all, I don't know of any features of any languages which are
>"inherently" expensive to implement, regardless of the machine
>architecture.

Right, because any expensive feature can be done directly in
hardware! :-)  But simply compiling a call to "(sort x)" into
"SORT (X)+,0" doesn't mean that the sorting won't still be O(n log n)...

>(BTW it'd be nice to see a LISP implementation that used one of the
>incremental garbage collection algorithms I've been hearing about;
>be nice for any GC'ed language, e.g. CLU & Smalltalk, too)

All Lisp Machines that I know of use incremental GC.

>I also think that, like time/space tradeoffs in algorithm design,
>there are "abstraction/implementation-difficulty" tradeoffs in language
>design. That is, the more high-level abstractions provided by a language
>(e.g. GC), the harder it is to come up with a relatively efficient
>implementation (compiled or interpreted) of the language. ...
>
>I use this argument as a defense to critics of CLU, which I feel provides
>one of the most useful high-level constructs (iterators) of any language.
>I am willing to pay the price (which can actually be small) for this
>step towards more abstract languages.  Remember that if a higher-level
>construct really costs in execution time, the lost time may be made up
>in program development time!

>-- Rich Wagner

I personally think that the argument for "reducing development time"
is a red herring.  In a real software engineering environment, people
spend their days reading and modifying existing code, not developing
it.  The advantage of higher-level constructs is that they can be
understood more easily and modified more safely.  CLU wins in some
of these respects, but it has little advantage over a modern Lisp
style.

The idea of tradeoffs in language implementation is a very interesting
one.  I have studied the possibility of mechanizing decisions about tradeoffs,
but the state of the art is still too primitive to really do it yet...

							stan shebs