[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LispM Market Share
- To: slug@WARBUCKS.AI.SRI.COM
- Subject: LispM Market Share
- From: "RDP%ALAN.kahuna.decnet.lockheed.com %ALAN.kahuna.DECNET.LOCKHEED.COM"@WARBUCKS.AI.SRI.COM
- Date: Tue, 16 Jan 90 17:10:20 EST
Received: from THOMAS.kahuna.decnet.lockheed.com by ALAN.kahuna.decnet.lockheed.com via INTERNET with SMTP id 16503; 16 Jan 90 14:07:28 PST
Date: Tue, 16 Jan 90 14:07 PST
From: Robert D. Pfeiffer <RDP@ALAN.kahuna.decnet.lockheed.com>
Subject: LispM Market Share
Date: Tue, 16 Jan 90 15:12 EST
From: firstname.lastname@example.org (Stephen G. Rowley)
Date: Mon, 15 Jan 90 15:38:04 CST
8. Lisp is still has the aura of being the "AI" language. Lisp
machines are for AI hackers, no?
"It's only because of the impoverished nature of other programming
languages that people don't think AI is for everyone."
-- dogmatic Lisp hacker
I don't know quite how rare it is for somebody to be doing computational
physics on a Symbolics (probably extremely rare aside from the
occasionaly Connection Machine front end) but I guess some (at least
one) people are.
Actually, I've done a modest amount of numerical analysis on the lispm
and like it:
* I don't have to worry about numerical type declarations, since the
generic arithmetic is fast.
* I can make my programs polymorphic with flavors, and not pay nearly
the penalty I would on another machine.
* I can make closures freely, knowing they'll be fast so long as I
arrange for them to be consed on the stack.
* I can use the debugger to get a lot more insight into what the
program is doing than on other machines. (I could use the metering
system too, but I've never had to get that serious.)
(Aside: We have had to "get that serious" on occasion and the metering
system is just wonderful!)
* I get all the expressiveness of Lisp, as opposed to the bit-oriented
nature of C.
* I can shift back & forth between numerical & symbolic analysis in
Macsyma. (This is much harder, apparently, in Mathematica. At
least it seemed so to me when I tried.)
If it wasn't for the Connection Machine I would be
doing fortran on a sun right now (****DEFINITELY**** not by choice), and
as it is, we will probably be concentrating more on Sun SPARC front ends
for the connection machine rather than the symbolics, primarily due to
issues of speed.
Speed of the front end? Perhaps I'm being ignorant, but why does the
front end have to be faster?
Yes, that is rather surprising at first, isn't it?
Monty (Kosma) can answer you in much more elaborate detail but what it
really comes down to is the fact that you can't do a general EVAL on a
Connection Machine processor. Thus, ultimately, the sophisticated
high-level functionality in the application (which must run on the front
end) becomes the bottleneck. If this isn't the case initially, you can
just keep throwing in CM processors until it is so.