Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830713); site hwcs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!ukc!cstvax!hwcs!greg
From: greg@hwcs.UUCP (Greg Michaelson)
Newsgroups: net.lang,net.lang.lisp
Subject: Re: Using LISP for scientific programming? (gasp!)
Message-ID: <603@hwcs.UUCP>
Date: Wed, 4-Sep-85 08:29:17 EDT
Article-I.D.: hwcs.603
Posted: Wed Sep  4 08:29:17 1985
Date-Received: Wed, 18-Sep-85 02:44:22 EDT
References: <1057@sdcsvax.UUCP> <1418@umcp-cs.UUCP> <1071@sdcsvax.UUCP>
Distribution: net
Organization: Computer Sci., Heriot-Watt U., Scotland
Lines: 37
Keywords: LISP, FORTRAN, C, Ada, Forth, Syntax, Efficiency
Xref: watmath net.lang:1798 net.lang.lisp:542

> > Fortran tends to be faster, even in the face of compiled,
> > optimized Lisp.
> 
> Agreed.  This is because more effort is put into the efficiency of Fortran
> compilers on numerical code than any other language, including C and
> Ada as well as LISP.  This is despite the poor correspondence between
> Fortran and modern computer architectures, not because of it.
> ...  FORTRAN is the most used language, hence gets the most attention
> from compiler writers, hence is usually the most efficient language, hence
> continues to be the most used.  How can we break this vicious cycle of
> mediocrity?

LISP is slow because its memory model is non-linear and dynamic. FORTRAN
has linear, static memory which corresponds 100% to VonN architecture.
Most speed loss in LISP implementations, compiled or interpreted, is due to
dynamic memory allocation and garbage collection. To 'break the vicious
cycle of mediocrity' involves realising that LISP is now nearly 30 years
and that times have changed. Pro-LISP arguments are awfully like pro-COBOL:
they all come down to familiarity & investment. Have a look at ML for a
clean, modern functional language with fast implementations.

> > In an interactive debugging mode, Lisp is almost always much slower.
> 	
> In interactive debugging, LISP is almost always faster, since Fortran
> programmers are trapped in the slow and expensive edit/compile/run cycle.
> A typical Lisp system's mixture of interpretation or compilation (often
> incremental compilation as a third alternative) is much more efficient of
> both machine and human time.

This is a confusion between a language, its implementation and its development
environment. Compilation and interpreation are implementation techniques which
can be used with any language. Similarly, any language can be implemented in
an interactive or 'batch' environment. For example, does using Pascal with
EMACS make Pascal interactive? Does typing straight into 'cc' make C
interactive? Does running LISP from punched cards make it a batch language?
Incidentally, there was an interactive FORTRAN developed around 1975 though
I don't have the details.


Brought to you by Super Global Mega Corp .com