Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sdcsvax.UUCP
Path: utzoo!watmath!clyde!cbosgd!cbdkc1!desoto!packard!hoxna!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!sdcsvax!davidson
From: davidson@sdcsvax.UUCP (Greg Davidson)
Newsgroups: net.lang
Subject: Using LISP for scientific programming? (gasp!)
Message-ID: <1057@sdcsvax.UUCP>
Date: Sun, 25-Aug-85 01:04:18 EDT
Article-I.D.: sdcsvax.1057
Posted: Sun Aug 25 01:04:18 1985
Date-Received: Wed, 28-Aug-85 09:28:58 EDT
References: <909@oddjob.UUCP> <163@ho95e.UUCP> <152@rtp47.UUCP>
Reply-To: Greg Davidson <davidson@sdcsvax.UUCP>
Distribution: net
Organization: EECS Dept. U.C. San Diego
Lines: 74

People who know and love LISP, such as myself, probably thought ``of
course, how natural'' to the suggestion of using LISP for scientific
and engineering programming.  Yet I would expect anyone not intimately
familiar with LISP to dismiss the notion as absurd.  I'd like to say a
little something about why.

LISP is in a completely different language family (applicative
languages) from FORTRAN/Pascal/C/Ada/Turing/etc.  Crossing language
barriers is hard (remember going from thinking in FORTRAN to thinking
in Pascal or C, making proper use of pointers, recursion, etc.?).
Crossing family barriers is rarely done by people not forced to do so.
It can take years of exposure to the new language before habits of
thought change enough to allow natural use of the new language.

Going from FORTRAN/Pascal/C to LISP means mastering true procedural
datatypes (allowing higher order procedures and object oriented style),
continuations (for streams, multiple coroutines, etc.), macros
(not the weak, flabby macros of mainstream languages), etc.  Each of
these mechanisms is as powerful and fruitful as the constructs separating
FORTRAN from either Pascal or C.  These things seem natural if LISP is
your first programming language (children take to it quickly), but are
major stumbling blocks to those used to other ways of doing things.

As if the semantic gulf were not enough, there's the syntax problem,
which stops most people cold at first glance.  LISP's default syntax,
Cambridge prefix, looks confusing and awkward to the unpracticed, and
the ability to change syntax at will (necessary for any truly general
purpose language) is really confusing to the novice (its probably
overused by beginning LISP programmers).

For example, when you're used to seeing:
		 _____________
		|   2
	 - b + \| b   - 4 a c
	________________________
		2 a

as	( - b + sqrt( b**2 - 4 * a * c ) ) / ( 2 * a )

you will find no sense in the default rendition in LISP:

	(/ (+ (- b)
	      (sqrt (- (sqr b)
		       (* 4 a c))))
	   (* 2 a))

Of course, you could just as easily define some read macros and write
it using infix notation, but few people do (Interlisp programmers are
the only exception I know of).  Most LISP programmers are not only used
to reading Cambridge prefix but make great use of its equal suitability
for evaluation or automatic algebraic manipulation.  Some LISP programmers
are really strange (like me) and write such things as:

	(/ (+ b/-			; b/- sameas (- b)
	      (- b/sqr (* 4 a c))/sqrt)	; etc.
	   (* 2 a))

using / to abbreviate monadic function applications, or as:

	(/ $ (* 2 a)) 	; read $ as ``something''
	(+ (- b) $)	; fills in hole in last list
	(sqrt $)	; etc.
	(- (sqr b) $)
	(* 4 a c)

using $ to postpone subexpressions in a first come first serve
recursive fashion (an idea of Marvin Minsky's).  Both of these
handy macros are in my default reader.

Well, enough of silly syntax games, I think you get the point.
Now who has a suggestion about how to convince the skeptical that
the effort in changing models is worth it?

_Greg Davidson			Virtual Infinity Systems, San Diego