Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!activis
From: activis@netcom.com (ActiVision)
Subject: Re: Why is Lisp not more widely used?
Message-ID: <activisDDB6I2.2xw@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <40j8lv$l5j@geraldo.cc.utexas.edu> <40ng4k$kg8@excalibur.edge.net>
Date: Mon, 14 Aug 1995 16:15:38 GMT
Lines: 191
Sender: activis@netcom21.netcom.com

Blake McBride (blake@edge.net) wrote:

: The people involved with lisp appear to be only concerned with
: academic use of lisp.  They seem to snub their noses at commercial
: users.  Case in point - the maintainers of GCL and CLISP, two
: fundamentally portable systems, insist on making their systems
: incompatible with mainstream hardware for absolutely NO REASON.

: CLISP uses variable argument C macros (not ANSI C) and functions and
: modules so large that they can not be compiled by any commercial
: compiler.  The requirement for these two features (only available with
: GCC) is totally arbitrary and only serves to keep commercial users
: away from CLISP.  There is NO NECESSITY for these requirements!  Their
: attitude is that any compiler which can't handle those two features is
: garbage.

Are you certain that there's no necessity?  A limitation of the C programming
language is that there's no standard way to request the compiler to inline
short helper functions, e.g. accessor functions that might be useful in
abstracting client code away from the specifics of how a given data structure
works.  Macros are really the only facility that C supports for inlining.
Given that Common Lisp permits a variable number of arguments for its
functions, writing a C macro using a variable number of arguments to represent
the equivalent Common Lisp function seems not only desirable, but necessary, if
only for the sake of good software engineering.

I'm even more puzzled by your annoyance over the CLISP sources' requirement
that your C compiler be able to compile large translation units or large
functions.  The C standard doesn't say that a conforming compiler reserves the
right to refuse service to obese source code.  I have to agree that compilers
that place arbitrary restrictions on the size of functions or files are brain-
dead.

: Oh, and please don't tell me to fix it myself.  The maintainers of
: CLISP flat out told me they will not integrate and support patches
: for "brain dead" [commercial] compilers.  I don't have the time to
: maintain a separate development and support branch of the code!
: I want to be a lisp user, not a lisp vendor!

Then buy one of the several commercially-available Common Lisp implementations
for PC-class machines--you'd undoubtedly be much happier with the performance
of a commercial system, to say nothing of the support.  Bruno Haible and
friends make CLISP available freely and certainly aren't responsible for making
it possible to compile CLISP using arbitrary C compiler X that you specify.
Completely apart from the afore-mentioned nice features of GCC that they use,
another good reason to use GCC is that it's available on practically every
platform under the sun, and often generates better code than the commercially-
available compiler(s) for the platform!

Incidentally, if you really have your heart set on using CLISP, why not FTP a
copy of DJGPP from some site that has it, and use that to compile it?  You'd
have a free C development system and a free Common Lisp development system--
quite a bargain.

: I don't mind porting, debugging or even adding some possible
: enhancements.  I don't, however, have the time to reverse out
: arbitrary portability issues specifically put in which in turn will
: not be integrated and supported.

Once again, it's not their responsibility to make their code compile under
every compiler out there, or even N compilers out there, where N > 1.

: GCL on the other hand insists on loading object files.  Thats nice on
: the x number of supported unix systems, however, why require it??!!
: Can't they put the stuff in a library, compile lisp -> C -> obj and
: link the whole thing in a conventional and portable way?  A simple
: change which would make GCL entirely portable and allow GCL's usage in
: commercial environments.

Most Common Lisp vendors who support compilation at all attempt to support
loading what are usually called FASL (FASt Loading) files, for the reason that
the name states.  For a Common Lisp compiler to always have to load source code
and recompile it at load time would place an onerous burden on the user.  Also,
it seems from a commercial point of view that few programmers would be willing
to ship a product written using a development system in which the only way to
distribute patches, extensions, etc. was in source form!

As for Lisp -> C -> obj, not all Lisp compilers use C as an intermediate
language for a number of reasons.  One is that there's a rather obvious loss in
efficiency in the approach.  Another is that on many platforms other than UNIX,
there's no standard way to have the Lisp compiler invoke the C compiler.
Another is that on platforms other than UNIX, assuming that the Lisp user even
_has_ a C compiler is a bad idea.

Incidentally, turning a Lisp compiler that doesn't use C as an intermediate
language into one that does would _not_ be a "simple change."

: Don't expect me to spend the next ten years fixing and supporting
: those systems.  These are easy changes for the maintainers of those
: systems.

Wrong.

: I'm especially not going to spend time on fixing arbitrary
: portability issues chosen by the designers as a reflection of their
: poor attitudes towards the commercial market place.

Nothing you've written demonstrates any such attitude on their parts.  Rather
what comes across is your poor attitude toward GCC and the realities of free
software, e.g. CLISP.

: Especially if they
: won't integrate and support the changes thereafter.

Not even _commercial_ software concerns will take changes that _you_ may make
to their code, integrate it, and support it thereafter.

: You can expect
: me to port the thing (add some defines, modify a line here and there),

Most real porting efforts are quite a bit more involved than this--try porting
a Mac application to Microsoft Windows, for example.

: report bugs beyond my abilities, use the system, spread the good news,
: and provide financial support when I make a profit.

So you want not just a free lunch, but a free lunch that works the way _you_
want, until you can make money from someone else's free lunch, at which point
you'll reward the free-lunch providers monetarily?  That's mighty big of you.

: It's kind of a chicken or egg problem.  As long as you have an
: anti-commercial attitude only a few academics (with no financial
: resources) use the system.  If you support the commercial world up
: front (by not building in arbitrary portability restrictions), the
: possibilities are endless.

Your argument may actually be a good one; I can't tell because your examples
are so poor.  In particular, you seem hell-bent on making some absolute
connection between your notion of "commercial" and "compilable with something
other than GCC."  In the shrink-wrapped commercial world in which I've been a
programmer for 15 years, you generally don't _get_ source code, let alone
source code that's guaranteed to compile with your particular compiler.  And
your arguments about CLISP in particular just come across as self-serving,
given that CLISP is a free system being contributed to the Internet community
out of the generosity of its authors.  Explain to us why the _commercial_
Common Lisp implementations haven't been successful in the marketplace, and
perhaps we'll all learn something.

: Look at how well netscape is doing.  How
: well do you think they'd be doing if they arbitrarily insisted on
: requiring academic environments?  They put the thing on a PC and boom
: - it's ubiquitous.

Most Web browsers actually _do_ insist on an academic environment inasmuch as
they crawl across anything less than a dedicated T-1 line.  Once again, your
choice of examples is poor in the extreme, because in this particular instance,
there's a case to be made that Netscape became successful by leveraging a good
shareware effort into a successful commercial effort (in much the same way that
id Software did with the wildly-successful DOOM marketing effort--incidentally,
id Software's next _commercial_ game is being developed with DJGPP).

: They don't have to rudely tell users of their
: system to fix it themselves.  They now have more money and resources
: than God.

I wasn't aware that the source code to Netscape was available.  Where can I get
it?

: I understand that it takes resources to properly support these
: environments.  If you'd stop unnecessarily ignoring portability and
: commercial issues I'm sure many more people would use _and_
: consequently support lisp!  Remember the commercial world is where the
: resources are.

You apparently missed Lisp's wild commercial days in the '80s.  There were
companies like Symbolics, Inc.; Lisp Machines, Inc.; Texas Instruments, Inc.;
Lucid, Inc.; Franz, Inc. and others.  At one point in recent history, Symbolics
pretty much owned the broadcast-quality computer-graphics world, thanks to
their S-series products (S-paint, S-geometry, etc.).  Symbolics is gone, as is
LMI, TI isn't in Lisp anymore, Lucid is gone, I think Franz is still around...
It's not that the Lisp community ignores the commercial world; it's that the
commercial world ignores Lisp.

: I'm frustrated!  I love lisp and want to use it on real life
: (commercial) projects.  Popular hardware is now able to host such
: environments.  Lisp now has a chance!  Why do you people keep snubbing
: your noses at the commercial world?

Well, again, perhaps you should remove yourself from the net and take a look in
the commercial Lisp world--I'd talk to Harlequin or Venue to start with.

: -- 
: Blake McBride				Algorithms Corporation
: 615-791-1636 voice			3020 Liberty Hills Drive
: 615-791-7736 fax			Franklin, TN  37064
: blake@edge.net				USA


Paul Snively
Activision, Inc.
psnively@activision.com
