🚀 go-pugleaf

> 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