Newsgroups: comp.lang.beta,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!fs7.ece.cmu.edu!europa.eng.gtefsd.com!news.umbc.edu!haven.umd.edu!ames!ncar!csn!gw1.att.com!nntpa!nntpa.cb.att.com!lgm
From: lgm@polaris.ih.att.com (Lawrence G. Mayka)
Subject: Re: Comparison: Beta - Lisp
In-Reply-To: mafm@cs.uwa.edu.au's message of 16 Sep 1994 05:30:30 GMT
Message-ID: <LGM.94Sep18154603@polaris.ih.att.com>
Sender: news@nntpa.cb.att.com (Netnews Administration)
Nntp-Posting-Host: polaris.ih.att.com
Organization: AT&T Bell Laboratories, Naperville, Illinois, USA
References: <34n2qe$d74@nz12.rz.uni-karlsruhe.de> <lenngrayCvunsr.448@netcom.com>
	<34pfea$6ee@belfort.daimi.aau.dk> <354q47$60i@belfort.daimi.aau.dk>
	<MAFM.94Sep16133030@wambenger.cs.uwa.edu.au>
Date: Sun, 18 Sep 1994 20:46:03 GMT
Lines: 65
Xref: glinda.oz.cs.cmu.edu comp.lang.beta:68 comp.lang.lisp:14719

In article <MAFM.94Sep16133030@wambenger.cs.uwa.edu.au> mafm@cs.uwa.edu.au (Matthew McDonald) writes:

	   I know this is about beta rather than lisp, but what Jacob is
   saying about beta sounds a lot like what many people have been saying
   about lisp.
	...
   What Jacob's saying is 
	   (a) Typical code written in c performs more than 5 times
	       better than code in his favourite language using available
	       implementations, and

For Common Lisp (LispWorks and CMU, at least), the factor was 2, not
5.  Moreover, I certainly disagree that this small numerical-analysis
benchmark is a typical C program.  It's certainly not typical of, say,
telecommunications switching systems.  Nevertheless, I agree that the
potential difference in efficiency of generated code between CL and
(the best) C compilers remains an obstacle to broadening CL's market.

   Telling people that a factor of 5 difference in run-time doesn't
   really matter doesn't encourage them to use your language.  Neither
   does telling them that *in principle* or *some day in the future*,
   your language could be competitive.

I agree that "in principle" is a weak argument; "can be fixed by the
vendor within n months/years" is a somewhat better argument (if
true!).

   Unless you have competitive ports to x86, Sparc, Alpha, DEC & SG Mips,
   PA-RISC, and RS6k, few people are going to use a language. Not many

Common Lisp has all these.

   At least Jacob's actually working on improving the beta
   implementation. As far as I can tell, the usual lisp advocate response
   to performance complaints is to either:
	   (a) deny there's a problem,

I don't deny the existence of a problem.

	   (b) say one day there won't be a problem, or

I think a concerted effort by vendors could substantially solve the
problem--i.e., make the best Common Lisp compilers generate code
substantially competitive with the code generated by the best C
compilers--within a reasonably short time period (perhaps 1-2 years).
Presumably, this will occur only if/when CL users raise its priority
above that of other new features and quality improvements.

	   (c) suggest you write code that looks like FORTRAN and
	   manually weigh expression trees and other insanity.

Ideally, code should "look like" the abstract solution to the problem
at hand.  If the problem is numerical analysis, then shuffling vector
elements is precisely the =correct= abstraction of the
solution--mathematician have no abstraction higher-level than that.
If you want to say that the ideal compiler would deduce all datatypes
so that explicit type declarations would be unnecessary, I agree; but
I don't see how you can hold this lack of type inferencing against
Common Lisp when C does no such thing either.
--
        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@ieain.att.com

Standard disclaimer.
