jonl%kuwait@LUCID.COM (Jon L White) (05/30/91)
Hmmmm, Walter sure has "pushed a lot of buttons" with his critique of
industrial-quality lisp usage! I had wanted to reply to them -- point
by point -- as to what the various vendors are doing, and to outline why,
in theory, these problems are solvable. But many of you folks have
already beaten me to the punch on this. And besides, _I_ might appear to
be biased to the point of propangandizing for Lucid's particular delivery
solutions. Instead, I want to explore a point that is orthogonal to the
usual "bull session discussions" that proffer potential technical solutions
to these real-or-imagined technical bottlenecks.
One thing you said is most interesting:
Yes, from what i've read ProKappa sounds like a cleverly disguised LISP in
C clothing. This certainly may have some marketing advantages these days,
but who knows about technical. . . .
This may provide some insight into the spate of judgements, rendered during
the past couple of years, against Lisp and towards C. For example, what
Walter says can often be directly verified; e.g.,
"...the language [Lisp] is sufficiently remote from the machine that
it is not always easy to understand the efficiency tradeoffs of
using different constructs."
This is true even when his main sub-point is trivially refutable -- i.e.:
"LISP code is *** always *** significantly slower than C code . . ."
[my emphasis added]. Similary, he claims Lisp is a "Memory hog" -- a point
which can more or less be conceded -- yet he also claims:
"The base development image for Sun Common LISP takes 14 MB!"
despite the fact that Sun Common Lisp's so-called base image takes only
about 6.5MB on disk (maybe he was referring to his developmental "base",
which might include a humongous amount of optional software? and he
didn't comment at all about the working-set size, which is of infinite
more importance than the requisite virtual memory size.)
I can also appreciate his comment about the cultural isolation of the
world of Lisp programmers.
But what Walter DIDN'T touch upon at all is the really hard part -- the
part that usually cannot be easily verified, and the part that makes your
remark about the "LISP in C" clothing so cogent. One usually cannot tell
just what effect the Lisp "defects" have on the marketability of a winning
product. So what! if some stellar, cost-saving application runs 15% slower
when delivered in Lisp than would be _theoretically_ possible if delivered
in C; or even 50% slower! [Why, the Lisp-to-C conversion cost itself could
be on the order of hundreds of thousands of dollars; how expensive do CPU
cycles have to be to amortize that kind of development cost?] So what! if
one needs 16MB or more of real memory, rather than the paltry 8MB or 12MB
common to the low-end workstations, when the software product itself costs
well in excess of even a high-end workstation? And with commercial prices
for SparcStation memory hovering around $50/MB, the incremental cost here
is less than the total cost for the workstation's CRT monitor!
The critical observation is -- It's a lot easier to document the micro-
benchmark technical issues of an OS, or a Computer Language, one is using
than to analyze, even in hindsight, the true contribution to software product
success due to one's choice of programming methodology, programming language,
or programming tools.
Indeed, there may be marketing advantages to dress up the old Lisp wolf in
the C Sheep's clothing (such as by pushing a ProKappa over a Lisp-based KEE.)
Or, perhaps, it simply is time to admit that no matter how easy and fun it
was to code up the product in Lisp, it really didn't didn't take advantage
of Lisp's features -- e.g., do we really need a Lotus-1-2-3 clone written in
Lisp? (by the way, I certainly don't consider KEE in this category.) And
there may even be a hint of technological obsolescence in some products
regardless of the language upon which they are built, which could happen for
any product that has been essentially riding the AI bandwagon.
However, the new re-packaging gives an opportunity to sell new hopes and
dreams. The consumers of software, like so many consumers in so many other
markets, are too frequently in the business of buying "hopes and dreams" as
much as of buying secure, certified solutions. Mike Thome's comparative
figures, for Lisp-comparable functionality when stacked up in the "C/Unix
world", tend to show that the speed/size arguments really are a murky
question; and they can just as easily be used for scapeGoating as for the
technological prelude to some Wolf-and-Sheep games.
-- JonL --jeff@aiai.edinburgh.ac.uk (Jeff Dalton) (05/31/91)
> One thing you said is most interesting: > > Yes, from what i've read ProKappa sounds like a cleverly disguised LISP in > C clothing. This certainly may have some marketing advantages these days, > but who knows about technical. . . . > But what Walter DIDN'T touch upon at all is the really hard part -- the > part that usually cannot be easily verified, and the part that makes your > remark about the "LISP in C" clothing so cogent. One usually cannot tell > just what effect the Lisp "defects" have on the marketability of a winning > product. So what! if some stellar, cost-saving application runs 15% slower > when delivered in Lisp than would be _theoretically_ possible if delivered > in C; or even 50% slower! Well, that's right -- in cases where the users don't find the application especially slow, don't think they have a fair idea how much faster it could be theoretically, and don't see much prospect of getting the theoretical alternative in any case. > [Why, the Lisp-to-C conversion cost itself could be on the order of > hundreds of thousands of dollars; how expensive do CPU cycles have > to be to amortize that kind of development cost?] There doesn't have to be any Lisp-to-C conversion if you start in C. In my opinion, that is one reason why tools, such as ProKappa, that will be used for developing applications, are moving towards C. People want to start in C and avoid Lisp altogether. > So what! if needs 16MB or more of real memory, rather than the paltry > 8MB or 12MB common to the low-end workstations, when the software product > itself costs well in excess of even a high-end workstation? And with > commercial prices for SparcStation memory hovering around $50/MB, the > incremental cost here is less than the total cost for the workstation's > CRT monitor! Well, that might explain why some Common Lisp implementations are so large. The people who can't afford to get enough 16M+ machines, or who need all the megabytes they can get just for their application, or who are trying to sell software that does not cost well in excess of even a low-end workstation, for example, are just not part of the intended market for those Common Lisps. That would be fine, if there were other Common Lisps that met their needs. But for many purposes there are not, and Lisp's image has suffered accordingly. Nonetheless, I agree with much of what you say. Indeed, I introduced ProKappa (at least I think it was me) into this thread because: it seems rather strange that when machines are becoming so much faster and memory so much cheaper we find people thinking it will be a big win to move from, say, KEE to ProKappa. The advanatges of a C-based system are relatively less than they used to be, I would think. One factor may be that there is sometimes a feeling that ProKappa applications will be easier to move to PCs -- a bigger market than the workstation one. > The critical observation is -- It's a lot easier to document the micro- > benchmark technical issues of an OS, or a Computer Language, one is using > than to analyze, even in hindsight, the true contribution to software product > success due to one's choice of programming methodology, programming language, > or programming tools. But decisions aren't always based on a correct analysis of the true contributions. For example, if a program is slow and spends lots of time garbage collecting and is written in Lisp, people may well think: "Lisp uses garbage collection, hence these delays. C doesn't use garbage collection so it won't have this problem." And they may even be right, though C may have other problems. > However, the new re-packaging gives an opportunity to sell new hopes and > dreams. The consumers of software, like so many consumers in so many other > markets, are too frequently in the business of buying "hopes and dreams" as > much as of buying secure, certified solutions. Many people are convinced that systems written in Lisp will automatically be unacceptably be large and slow. C's reputation is the opposite. It's not irrelevant that it's a change to C rather than just a change. -- jd