Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why is Lisp not more widely used?

55 views
Skip to first unread message

Jason Fossen

unread,
Aug 12, 1995, 3:00:00 AM8/12/95
to
Why is Lisp not more commonly used for commercial programming?
To my knowledge, Visual Basic is the most widely used. Is it merely
historical precedent, you know, positive feedback in the market?


Cyber Surfer

unread,
Aug 13, 1995, 3:00:00 AM8/13/95
to
In article <40j8lv$l...@geraldo.cc.utexas.edu>
jas...@mail.utexas.edu "Jason Fossen" writes:

One word: marketing. No, make that two words: good marketing. VB
has all the marketing might of Microsoft behind it. Try to imagine
how popular a Lisp dialect like Common Lisp might be if MS openly
used it, sold their own (probably non-standard) implementation of it,
and recommended that developers use it, and finally, perhaps even
bundled it with a few of their top applications.

I've read that MS have used CLOS to implement their "Bob" user interface.
Let's hope that we'll read about it in a few widely read magazines...
Lisp could use the (good) PR.

Meanwhile, if I have a tool that gives me an edge as a programmer,
I don't really care if not many other programmers know about it.
All that really counts is how good the tool is, how well supported
it is, how long it'll continue to be supported for, and if I can
convince anyone that I should be allowed to develop with it.

Apart from that last bit, I have nothing to prove to other programmers...

Of course, we should also ask ourselves which dialect of "Lisp" it is
that we're discussing. If you distingusish between VB for DOS and VB
for Windows, we could have yet another question.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."

Scott Fahlman

unread,
Aug 13, 1995, 3:00:00 AM8/13/95
to

> Why is Lisp not more commonly used for commercial programming?

One word: marketing. No, make that two words: good marketing.

I would argue that marketing, while important, has been a much less
important factor in Lisp's non-success in the mainstream than the lack
of a good, cheap implementation on PC's and poor delivery
characteristics. Both of those are solvable problems in Common Lisp,
and have been partially solved, but it was too little, too late. This
is the direct results of some bad strategic decisions by the vendors
and (less important) some bad decisions in the language design that
make it hard to deliver stripped-down systems. I'll take some of the
credit for the latter set of mistakes.

Meanwhile, if I have a tool that gives me an edge as a programmer,
I don't really care if not many other programmers know about it.
All that really counts is how good the tool is, how well supported
it is, how long it'll continue to be supported for, and if I can
convince anyone that I should be allowed to develop with it.

Well, having been through this once, I think that's kind of naive. A
language that is used by few people will not be supported very well,
either by vendors or by third-party developers of libraries,
textbooks, tools, and so on. And there's a lot of positive feedback:
if a language is widely used, there are lots of programmers around who
know how to use it, and compaines will tend to choose it for new
projects -- no matter how bad it might be compared to some language
that nobody knows. Once you're a niche language, the advatanges for a
given task have to be really compelling, and eve then some projects
will go with the mainstream.

On the other hand, if the mainstream clogs up in a place where
programmers become sufficiently unhappy and unproductive, there can
occasionally be a mass breakout to something better. But that's a lot
more likely if the better language that people might move to is widely
avilable in the educational market (including, now, highschools and
people's basements), so that people know what they are missing and
aren;t afraid of it. Common Lisp isn't there, and the Schemes that
are there tend to make Lisp look like a neat idea, but not very
practical for big projects. That could change. Or maybe something
like Dylan will keep the good ideas of Lisp in front of people,
somewhat repackaged.

-- Scott

===========================================================================
Scott E. Fahlman Internet: se...@cs.cmu.edu
Principal Research Scientist Phone: 412 268-2575
School of Computer Science Fax: 412 268-5576
Carnegie Mellon University Latitude: 40:26:46 N
5000 Forbes Avenue Longitude: 79:56:55 W
Pittsburgh, PA 15213 Mood: :-)
===========================================================================

Erik Naggum

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to
[Blake McBride]

| 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.

hardware? mainstream _hardware_? you seem to be talking about mainstream
_software_ on that hardware, not the hardware. be accurate when flaming!

| 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.

stop lying, and maybe people will listen to you.

| Their attitude is that any compiler which can't handle those two
| features is garbage.

of _course_ it is! compiler vendors who cripple their products on purpose
should be flogged. it's a _bug_ in that sorry excuse for a "commercial"
compiler.

| The maintainers of CLISP flat out told me they will not integrate and
| support patches for "brain dead" [commercial] compilers.

I don't think they are representative of the lisp community, though. you
obviously haven't seen the comment in the timezone tables about PRC, yet.

| A simple change which would make GCL entirely portable and allow GCL's
| usage in commercial environments.

please explain.

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

you have obviously mistaken free software for commercially supported
software. that is just not the case. "you want it, you do it." if you
would like to pay for somebody else to do it, go ahead. quit whining.

| 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.

have you asked yourself why _anyone_ who has made software for free would
_ever_ want to do as you ask them to? it could be as simple as the fact
that you behave like a freaking manager who thinks he has paid for support
(or "support"). you haven't. you got it for free. behave accordingly.

| Look at how well netscape is doing.

my gawd. have you looked at _what_ Netscape is doing? you'd have to have
cat food for brains to write software like that. yes, it's marketed very
well, and it's extremely glitzy. big deal. I suppose you think Windows is
cool, too. popularity is the new holy grail, and quality is too heavy a
burden to carry while running after it.

| How well do you think they'd be doing if they arbitrarily insisted on
| requiring academic environments?

take a look at their licences, you dimwit. I cannot in good conscience use
Netscape because it asks me to accept an evil licence agreement when it
starts up, and this is at an academic site.

| Remember the commercial world is where the resources are.

yeah, right. the commerical world is where the managers are, too, who have
as much brains as your average toad when it comes to what is or is not good
software. Netscape and Windows are manager-type products: rotten code with
nice packaging. that's all they care about. would _you_ care to go into
that kind of prostitution? I guess you would. well, I don't, and I'm
still a free man, running my own consulting business, writing and helping
to write free software because I'm sick and tired of those brainless twits
deciding what's good and what isn't. the commercial world may have money,
but that is in no way related to whether they have good people.

| 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?

that's your own frustration, dude, not "you people". do you think it would
be appropriate if some of us who are happy users of free Lisp environments
took _you_ as the paradigm of "commercial people", and waxed frustrated
about how "you people" in business never give us any money and always want
more features, all the while consciously and deliberately crippling both
software and hardware to make _our_ life unnecessarily harder?

if there's animosity between the commercial and the academic world, it's
your pathetic kind that creates it. now go away and learn to respect other
people's voluntary and charitable contributions to your well-being without
demanding anything back, like that "commercial world" does for shoddy
products and rotten support.

note that the Lisp vendors are not behaving like that. the Lisp vendors I
have talked to have been very kind and friendly, always helpful, staffed by
excellent people. it's in your "mainstream" world that the shitheads rule.
you play _their_ game, at _their_ beck and call, don't you?

#<Erik 3017398635>
--
help! I'm lost in an n-dimensional universe and I don't know what n is!

Brian Leverich

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to
Erik Naggum (er...@naggum.no) wrote:
: [Blake McBride]

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

: you have obviously mistaken free software for commercially supported
: software. that is just not the case. "you want it, you do it." if you
: would like to pay for somebody else to do it, go ahead. quit whining.

: | 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.

: have you asked yourself why _anyone_ who has made software for free would
: _ever_ want to do as you ask them to? it could be as simple as the fact
: that you behave like a freaking manager who thinks he has paid for support
: (or "support"). you haven't. you got it for free. behave accordingly.


Wrong attitude.

Perhaps fatally wrong attitude.

A large portion of "free" software is actually funded by government
and corporate grants. While that kind of funding frees you from the
day-in-day-out need to be responsive in a slavish commercial sense,
you've still got to keep your research domain "hot" or funding goes
away. You keep your domain hot by, among other things, showing that
your work is opening up opportunities for other folks to do neat
things that they've never been able to do before.

The problem in the Lisp community is that we're not "hot" anymore and
the dollars are disappearing fast. I'm not sure how to fix that, but
it's pretty clear that one of the first steps needs to be understanding
why our user base is decaying and then doing whatever is needed to stop
the bleeding. -B


--
Dr. Brian Leverich
Information Systems Scientist, The RAND Corporation
leve...@rand.org

ActiVision

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to
Blake McBride (bl...@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
: bl...@edge.net USA


Paul Snively
Activision, Inc.
psni...@activision.com

Rajendra Wall

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to
Erik Naggum
> [spews forth pointlessly bile-laden insults while ignoring the real issues]

Blake,

I think Erik's attitude nicely sums up what happened to Lisp and why
it is where it is, don't you think?

Regards,
Raj

#43: The FBI didn't kill anyone at Jonestown.
P.J. O'Rourke, "100 Reasons Why Jimmy Carter Was a Better President
Than Bill Clinton".


Blake McBride

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to

rw...@fohnix.metronet.com (Rajendra Wall) wrote:
>Erik Naggum
>> [spews forth pointlessly bile-laden insults while ignoring the real issues]
>
>Blake,
>
>I think Erik's attitude nicely sums up what happened to Lisp and why
>it is where it is, don't you think?

Yes, I do. Thanks for the support and saving me the time of responding to
his note.

--blake


Carl L. Gay

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to

Newsgroups: comp.lang.lisp
From: act...@netcom.com (Paul Snively)
Date: Mon, 14 Aug 1995 16:15:38 GMT

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.

Just a small correction here. Symbolics *was* gone, but is now
back. see the recent announcement to various Lisp-related mailing
lists.

Franz is *certainly* still around (and responding to my bug reports).

-Carl

Blake McBride

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to

jas...@mail.utexas.edu (Jason Fossen) wrote:
>Why is Lisp not more commonly used for commercial programming?
>To my knowledge, Visual Basic is the most widely used. Is it merely
>historical precedent, you know, positive feedback in the market?
>


Here I go again!

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.

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!

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.

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.

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. 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. Especially if they
won't integrate and support the changes thereafter. You can expect


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

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

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. 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. 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 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.

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?

--

Marco Antoniotti

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to
In article <40nt4u$g...@rand.org> leve...@atlantis.rand.org (Brian Leverich) writes:


From: leve...@atlantis.rand.org (Brian Leverich)
Newsgroups: comp.lang.lisp
Date: 14 Aug 1995 16:20:46 GMT
Organization: RAND Corporation
Lines: 42
NNTP-Posting-Host: atlantis.rand.org
X-Newsreader: TIN [version 1.2 PL2]

Erik Naggum (er...@naggum.no) wrote:
: [Blake McBride]

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

: you have obviously mistaken free software for commercially supported
: software. that is just not the case. "you want it, you do it." if you
: would like to pay for somebody else to do it, go ahead. quit whining.

: | 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.

: have you asked yourself why _anyone_ who has made software for free would


: _ever_ want to do as you ask them to? it could be as simple as the fact
: that you behave like a freaking manager who thinks he has paid for support
: (or "support"). you haven't. you got it for free. behave accordingly.


Wrong attitude.

Perhaps fatally wrong attitude.

A large portion of "free" software is actually funded by government
and corporate grants. While that kind of funding frees you from the
day-in-day-out need to be responsive in a slavish commercial sense,
you've still got to keep your research domain "hot" or funding goes
away. You keep your domain hot by, among other things, showing that
your work is opening up opportunities for other folks to do neat
things that they've never been able to do before.

The problem in the Lisp community is that we're not "hot" anymore and
the dollars are disappearing fast. I'm not sure how to fix that, but
it's pretty clear that one of the first steps needs to be understanding
why our user base is decaying and then doing whatever is needed to stop
the bleeding. -B

What about a free (or at least below-100-bucks) CLIM with Motif and
Windows attachment? What about a standard FFI?

Sorry, you threw the flame bait :)

Cheers

--
Marco G. Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: mar...@cs.nyu.edu
| WWW: http://found.cs.nyu.edu/marcoxa

...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht

Marcus Daniels

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to
>>>>> "Blake" == Blake McBride <bl...@edge.net> writes:
In article <40ng4k$k...@excalibur.edge.net> Blake McBride <bl...@edge.net> writes:

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

I have several points:

1. It is true that CLISP uses macros in a fairly aggressive way.
The alternative would be to use inline functions; a feature which is
not standardized (although prevalent).

2. Dare I say CLISP is a mature implementation. The empty macro
substitutions you mention are a result of conventions that exist
throughout the C code of CLISP. It would be a huge job to change
these usages, and would almost certainly result in many bugs. In any
case, a lot of work. In my opinion, the only "necessity" is dealing
with actual *bugs*.

3. CLISP is already preprocessed. The obvious, and better, way to
solve your problem is to make GNU cpp (a seamless) part of the build
process. Today, GNU cpp is included, but not used by default.
CLISP's C code is like ANSI C, but is actually ".d", a C superset.
The GNU cpp solution will work, but would require some effort on the
part of the users of commercial compilers. This effort would
basically be to identify the default defines of that compiler, and
mirror them in GNU cpp. A person doing a port of CLISP would really
need to know much of this information anyway, in order to complete the
port.

4. Speaking only for myself, at no time have I rejected patches or
told you (Blake McBride) that I would reject such patches. What I
have said, is that *I* have no interest in attempting such radical
surgery on CLISP. Giving you the benefit of the doubt, I think you
underestimate the scale of the changes you propose.

I will accept such patches, if an individual performs the work
themselves, and was willing to be somewhat incremental about the whole
thing. If this translates to "no", I don't know what to say.

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

If you say so.

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

Hmm, CLISP supports at least:
MSDOS, OS/2, Amiga, 386BSD 0.1 NetBSD 1.0 BSDI 1.0 Sun4 (Sparc) under
SunOS 4 Sun3 (68020) under SunOS 4 Sun4 (Sparc) under SunOS 5.2-4 386
under SunOS 5.3 HP9000/8xx under HP-UX version 8 HP9000/3xx under
HP-UX version 8 Consensys System V 4.0 Consensys System V 4.2 386 UHC
UNIX System V release 4 Onsite System V 4.2 UnixWare SINIX-Z 5.42
SINIX-N 5.42 IRIX 3.2.1 IRIX 4 IRIX 5 DECstation 5000, Ultrix Apple
Macintosh, A/UX Amiga running AMIX 2.1 SVR4.0 AIX Sequent ptx SCO
Convex C2 running ConvexOS 10.1 Atari ST/TT running MiNT DEC Alpha AXP
running OSF/1 1.3 or OSF/1 2.0 or OSF/1 3.0

When I hear crazy complaints like yours, yes, my "attitude" is that
portability (in your definition) is a MASSIVE time sink. I *would*
much rather favor developer-friendly GNU environments. This
has nothing to do with academic bias, it is sheer self-preservation!

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

Entertain the notion that perhaps the people who volunteer years of
their lives, such as Bruno Haible and Bill Schelter, might actually be
aware of some of the issues you've alluded to!! Imagine!

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

I'm sorry for failing you.

Cyber Surfer

unread,
Aug 14, 1995, 3:00:00 AM8/14/95
to
In article <40l7fp$5...@cantaloupe.srv.cs.cmu.edu>
s...@CS.CMU.EDU "Scott Fahlman" writes:

> I would argue that marketing, while important, has been a much less
> important factor in Lisp's non-success in the mainstream than the lack
> of a good, cheap implementation on PC's and poor delivery

I was refering to the marketing of VB, of course. I can't comment
on the marketing of, say, Common Lisp systems, as I've seen so little
of it. On the other hand, I can't avoid the marketing of VB, as it's
in my face every day.

> characteristics. Both of those are solvable problems in Common Lisp,
> and have been partially solved, but it was too little, too late. This
> is the direct results of some bad strategic decisions by the vendors
> and (less important) some bad decisions in the language design that
> make it hard to deliver stripped-down systems. I'll take some of the
> credit for the latter set of mistakes.

Well, I've no idea who is to "blame" for these mistakes, but I agree
that the Lisp implementations I've seen make it hard or impossible to
deliver stripped-down systems.



> Well, having been through this once, I think that's kind of naive. A
> language that is used by few people will not be supported very well,
> either by vendors or by third-party developers of libraries,

I agree, but I've had no problem using Lisp so far. Perhaps I just
find it a natural language to work in. Anyway, the only problem I've
had so far has been with delivering the code in a form that other
people can use. _I_ may be happy using code within a development
system, but most people wouldn't be.

Also, I've never relied on vendor support before, so a lack of
support for a language system doesn't worry me too much. It could
depend on what I'll use it for, of course!

Still, I'm currently using a Scheme with very little support, and
doing useful work with it. My Scheme to C compiler may be even better
"supported", as I have the source code and access to the developer
of it - myself.

I don't expect anyone else to find this a workable solution, and
I've yet to use it to deliver code for use by other people, which
is a point I made in an earlier post. I do it this way coz _I can_,
not coz it's necessarily the best way of doing something. However,
it may provide me with the tools that best serve my needs.

> textbooks, tools, and so on. And there's a lot of positive feedback:
> if a language is widely used, there are lots of programmers around who
> know how to use it, and compaines will tend to choose it for new
> projects -- no matter how bad it might be compared to some language
> that nobody knows. Once you're a niche language, the advatanges for a
> given task have to be really compelling, and eve then some projects
> will go with the mainstream.

That's why most of my coding is done in C at present. When I'm
working in my own time, I use Scheme. So far, nobody has convinced
me that they know how to spent my time better than myself, and
very few people have even bothered to try to convince me. ;-)

I find I can avoid a lot of "advocacy" problems if I simply don't
tell people which language I used to write a particular app. If
they don't ask, why trouble them? If someone were to pay for the
development of some code, then I'd agree that they have an interest
in the choice of the language (and the language implementation)
used to develop that code.

> On the other hand, if the mainstream clogs up in a place where
> programmers become sufficiently unhappy and unproductive, there can
> occasionally be a mass breakout to something better. But that's a lot
> more likely if the better language that people might move to is widely
> avilable in the educational market (including, now, highschools and
> people's basements), so that people know what they are missing and
> aren;t afraid of it. Common Lisp isn't there, and the Schemes that
> are there tend to make Lisp look like a neat idea, but not very
> practical for big projects. That could change. Or maybe something
> like Dylan will keep the good ideas of Lisp in front of people,
> somewhat repackaged.

That's why I'm pleased to see that the Open University (an adult
education system here in the UK) have a Common Lisp course. See
<URL:http://kmi.open.ac.uk/courses/dmzx863.html> for more details.
They also mirror CMU's WWW version of CLtL2.

My Scheme to C compiler is designed to be more practical than the
systems I've used (MIT Scheme and SCM). I like MIT Scheme a lot,
but I don't think it can deliver stand-alone code, while SCM is
an interpreter, and a lot slower than the code from my compiler
(by a factor of 8+).

Now, this is the first real Lisp compiler I've written (an earlier
effort produced an interpreted code), so the code doesn't even
begin to look "optimal", and yet it's fast enough for me not to
worry about how much faster an app might be if it were written in C.

As a test, I rewrote one app in C and compared the performance. It
was only 5 times faster than the Scheme version run by SCM, and yet
it was so flackey that it managed to hang my machine at least once.
It could be argued that such a program will never complete, and so
runs at 0% efficiency! Anyway, it would need a dedicated machine to
run it, as any other programs running on that machine would also
never terminate.

I consider the performance of SCM compared to the code from a C
compiler to be a "big win". The code from my Scheme to C compiler
should be an even bigger win. :-) Of course, my definition of
"practical" is any code that can be used in a real app, but the
what counts as a real app may be debated. Perhaps it's any code
which is useful, and is used frequently? Well, I have plenty of
code like that! I use it daily, and I find it _very_ useful.

Marcus Daniels

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
>>>>> "Brian" == Brian Leverich <leve...@atlantis.rand.org> writes:
In article <40nt4u$g...@rand.org> leve...@atlantis.rand.org (Brian Leverich) writes:

Brian> The problem in the Lisp community is that we're not "hot"
Brian> anymore and the dollars are disappearing fast. I'm not sure
Brian> how to fix that, but it's pretty clear that one of the first
Brian> steps needs to be understanding why our user base is decaying
Brian> and then doing whatever is needed to stop the bleeding. -B

The lingo-speak is bloody endless. Being a "community" is fully
equivalent to being a powerless and pathetic minority group. How
silly. A programming language is nothing to share a
collective-identity about.

Much free software is written without any funding, and without any
expectation of expectation. Yes, I know.. arbitrary and foolish.

..So the Lisp "community" bleeds to death. Gasp, rip my heart out.
Guess what: Lisp still exists!!


Cyber Surfer

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
In article <MARCOXA.95...@mosaic.nyu.edu>
mar...@mosaic.nyu.edu "Marco Antoniotti" writes:

> What about a free (or at least below-100-bucks) CLIM with Motif and
> Windows attachment? What about a standard FFI?
>
> Sorry, you threw the flame bait :)

When you refer to a standard FFI, do you mean one that is standard
at the source level, or at the binary level? MS Windows has an FFI
convention already - just use the Pascal parameter passing that MS
Windows itself uses. I don't know of a language system for Windows
that uses any other FFI at the binary level, altho the non-C FFIs
may differ widely at the source level.

CL + CLIM for less than $100 would be dynamite! $300 would be still
be good value, in my opinion. It might be competitive with Smalltalk/V,
for example. Allegro CL for Windows costs <ahem> a lot more than that,
and it's the cheapest commercial CL that I know of. "Cheap" is not
the word that springs to mind...

Cyber Surfer

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
In article <MARCUS.95A...@sayre.sysc.pdx.edu>
mar...@sysc.pdx.edu "Marcus Daniels" writes:

> ..So the Lisp "community" bleeds to death. Gasp, rip my heart out.
> Guess what: Lisp still exists!!

Do you remember the last line from The Incredible Shrinking Man?
"To God there is no zero. I still exist!"

I wish Franz and Symbolics etc a lot of luck. For many programmers,
only commercial products "exist". We need the commercial vendors.

Erik Naggum

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
[Rajendra Wall]

| Blake,
|
| I think Erik's attitude nicely sums up what happened to Lisp and why it
| is where it is, don't you think?

the problem with you two guys is that you are much too willing to attribute
individual opinions (first your interaction with the volunteer maintainers
of the freely available Lisp environments GCL and CLISP, and now mine) as
that of a whole community of people, even to the point of faulting a
purported "community" for your dislike of opinions that are expressed a
decade after the fact. your stupidity is offensive, and anything you might
"sum up" is unlikely to do anything but "support" your prejudice.

#<Erik 3017503286>

Bob Riemenschneider

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to

> CL + CLIM for less than $100 would be dynamite! $300 would be still
> be good value, in my opinion. It might be competitive with Smalltalk/V,
> for example. Allegro CL for Windows costs <ahem> a lot more than that,
> and it's the cheapest commercial CL that I know of. "Cheap" is not
> the word that springs to mind...

Digitool's MCL 3.0 Champion Edition, "available only to individuals and
students for championing the use of MCL at home, in companies, or
universities" but "identical in software content and capability" to the
regular MCL 3.0 release, is $135 for students and $295 for non-students.
(If you're a company, MCL 3.0 is $595, still considerably cheaper than
Allegro for Windows.) No CLIM at the moment, but there's a Mac version of
Garnet.

-- rar

Tim Bradshaw

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
* Blake McBride 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.

I think you actually mean `the people involved in writing free /
academic lisp systems' here. Well, yes, those people are indeed
interested in academic uses of Lisp: they are generally academics,
it's what they're paid to do. The people involved in commercial Lisp
systems are more interested in commercial uses.

> 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.

I don't know about variable argument macros, but are commercial C
compilers still written with arbitrary table size limits all over
them? It's sad if so, and yes, such compilers are basically garbage,
aren't they?

> [...]

> 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.

This could of course be done, but it doesn't give you the kind of
resident Lisp environment that is what people like to use for using
lisp in its traditional academic / research type environment: I would
find such a Lisp rather hard to use for instance. I'm sure you could
pay someone to support the more common compile-link-go cycle.


So the free / academic Lisp systems don't hack it for commercial
systems, surprise! Your obvious choice is to buy a commercial,
supported, Lisp, the same way I assume you buy a commercial,
supported, C compiler, isn't it? If you are working on some platform
where there is no such Lisp available, then you are in the same
position as if you are working on a platform where there is no such C
compiler: you need to pay for a supported port, or perhaps pay someone
to support one of the free Lisp systems, the way commercial people now
support GNU stuff. What is so strange or odd about this? There are
no free lunches.

--tim


David Boles

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
In article <activisD...@netcom.com>,

ActiVision <act...@netcom.com> wrote:
> : 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.

Then don't inline the helper functions. Yes there'll be a loss of
efficiency, but it *would* run. With some decent software engineering,
it would almost certainly be possible to make the system run faster than
it does today, and stick to ANSI C. I think Blake's problem here is that
CLISP is not written in C, it's written in GCC. It's a problem that I
have with a lot of software out there. GCC is a reasonably good
compiler (but only reasonably), and using it is fine, but people
shouldn't claim they're writing in C when they use GCC extensions.

> 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.

Hmmm, perhaps you should actually *read* the C standard, specifically
section 5.2.4.1 "Translation limits":

===========================================================================

The implementation shall be able to translate and execute at least
one program that contains at least one instance of every one of the
following limits:

-- 15 nesting levels of compound statements, iteration control
structures, and selection control structures

-- 8 nesting levels of conditional inclusion

-- 12 pointer, array, and fuction declarators (in any combinations)
modifying an arithmetic, a structure, a union, or an incomplete
type in a declaration

-- 31 nesting levels of parenthesized declarators within a full
declarator

-- 32 nesting levels of parenthesized expressions within a full
expression

-- 31 significant initial characters in an internal identifier or
a macro name

-- 6 significant initial characters in an external identifier

-- 511 external identifiers in one translation unit

-- 127 identifiers with block scope declared in one block

-- 31 parameters in one function definition

-- 31 arguments in one function call

-- 31 parameters in one macro definition

-- 31 arguments in one macro invocation

-- 509 characters in a logical source line

-- 509 characters in a character string literal or wide string
literal (after concatenation)

-- 32767 bytes in an object (in a hosted environment only)

-- 8 nesting levels for `#include`d files

-- 257 `case` labels for a `switch` statement (excluding
those for any nested `switch` statements)

-- 127 members in a single structure or union

-- 127 enumeration constants in a single enumeration

-- 15 levels of nested structure or union definitions
in a single struct-delcaration-list

===========================================================================

> Explain to us why the _commercial_ Common Lisp implementations haven't
> been successful in the marketplace, and perhaps we'll all learn
> something.

Well, for my part I find that I can't use Lisp for some tasks where it
is otherwise well suited because of the poor I/O facilities. Specifically,
an interactive programming environment is an ideal place to play what-if
games with your data. The Lisp compilers do a good job giving me adequate
performance for that sort of work (with 2-3X of C). However, the lack of
reasonable support for binary I/O (specifically floating-point) causes me
to give up >90% of my effective I/O bandwidth and costs me ~2.25X in
storage space.

Cheers,

Dave Boles
dbo...@convex.com


Cyber Surfer

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
In article <40ng4k$k...@excalibur.edge.net> bl...@edge.net "Blake McBride" writes:

> 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.

Well, all I can say is that I'm still waiting for a Windows version
of CLISP. I've been told that such a version exists, but it has not
been made available. I'm no longer sure it's worth waiting for, as
I may either switch to a commercial Common Lisp, or use MIT Scheme
instead. If I'm lucky enough to eventually be able to use Linux, then
I may use MIT Scheme anyway.

Alternately, I could go back to using Actor (for Windows), and just
forget about Lisp...

Cyber Surfer

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
In article <activisD...@netcom.com> act...@netcom.com "ActiVision" writes:

> 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

In the last email I received from Bruno, he told me that he no longer
is responsible for CLISP's development.

I'd probably buy a commercial CL if it were not for the high prices.
I'd rather save the $1000 for a new machine, and then install Linux
on it, and run one (or more) of the Lisps that come with it. I can
_afford_ that, _and_ I get a faster machine as a bonus.

What I can't afford at the moment is a language system that costs 3+
times as much as the C compiler I'm using. Perhaps that's the reason
why Lisp is not as popular as C? In my case, I'd rather use Lisp,
but I can't justify a commercial implementation. It's on my list of
Things To Get, but when something costs as much as $1000, those
things have to pay for themselves. In other words, other people
decide whether I can buy them or not.

> 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.

My reason is simply. I already a 3 C compilers, and it's pain making
them all work under DOS. I have to keep switching enviroment variables
each time I change project. I have GNU C, and that makes the list one
C compiler longer. Of course, I try to avoid using C...

I'd love a Lisp system, and I'd prefer not to have to write or port
my own, esp if it's a CL system we're talking about. CLISP is not yet
available for Windows. NT or Win95 support would make it very popular,
esp these days.

It's easy to understand someone's frustration at the current is
situation, altho I feel that Blake McBride is expressing his
feelings as little too strongely. That's why my point is more
of a question: where are the freeware Lisps for Windows? The
only one I know of is MIT Scheme, which looks like a very flaky
beta when it runs on my 386 under Windows 3.1. I'm hoping that
a Win32 version of CLISP would perform better, but I've yet to
even see a beta.

Perhaps I'm just being difficult coz I insist on using Lisp in
a graphical enviroment? Oh dear. That might also explain why
Lisp is not so widely used - I'm far from alone in this making
this odd demand! Almost everyone I know who using a computer
these days expects the "luxury" of a GUI, and software that'll
take advantage of it. It's hard to argue with them...

Cyber Surfer

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
In article <CGAY.95Au...@ix.cs.uoregon.edu>

cg...@ix.cs.uoregon.edu "Carl L. Gay" writes:

> Franz is *certainly* still around (and responding to my bug reports).

I hope so! The only commercial CL for Windows that I know of is sold
by them. If there are any other CL systems for Windows, I'd love to
know about them, whether they're commercial or otherwise.

Marcus Daniels

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
>>>>> "CS" == Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
In article <808484...@wildcard.demon.co.uk> Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:

CS> I'd love a Lisp system, and I'd prefer not to have to write or
CS> port my own, esp if it's a CL system we're talking about. CLISP is
CS> not yet available for Windows. NT or Win95 support would make it
CS> very popular, esp these days.

A NT port is being studied -- using win32 GCC from Cygnus. No promises.


Marcus Daniels

unread,
Aug 15, 1995, 3:00:00 AM8/15/95
to
>>>>> "david" == David Boles <dbo...@news.eng.convex.com> writes:
In article <40qld2$5...@zeppelin.convex.com> dbo...@news.eng.convex.com (David Boles) writes:

w.r.t. CLISP:

david> Then don't inline the helper functions. Yes there'll be a loss
david> of efficiency, but it *would* run. With some decent software
david> engineering, it would almost certainly be possible to make the
david> system run faster than it does today, and stick to ANSI C.
david> I think Blake's problem here is that CLISP is not written in C,
david> it's written in GCC. It's a problem that I have with a lot of
david> software out there. GCC is a reasonably good compiler (but only
david> reasonably), and using it is fine, but people shouldn't claim
david> they're writing in C when they use GCC extensions.

First of all, a proprietary compiler would have generate 30% better
code before *I* would even *think* about investing significant labor
into a non-GCC port. I might try the native compiler once, and
tolerate a few limitations, but once I suspected weakness -- I'd just ftp GCC.

If someone else is motivated to bring CLISP up on their development
environment / OS that is great. There have been some *very* generous
contributors to CLISP.

Second of all, many Unix compilers *can* handle these macros. The few
places GCC extensions are used in CLISP, it is only done if the
feature is available.

Thirdly, and most importantly, there are already programs that process
CLISP source code before it is compiled. It is a simple matter to add
another, namely GNU cpp. GNU cpp is already in the distribution.
Stop fixating on ANSI C. It is ".d"! Get over it!

What has become clear to me is that these individuals are not content to
investigate these simple alternatives for themselves. They do not
understand the nature of free software (or care), and would much rather
whine and spread misinformation.

Ultimately, it isn't about "loss of efficiency", it is about raping the
code without considering perfectly workable alternatives.

>> 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.

david> Hmmm, perhaps you should actually *read* the C standard,
david> specifically section 5.2.4.1 "Translation limits":

Let me be very concrete:

These huge blocks of code Blake McBride vaguely talks about have
not even be named!

Holger Duerer

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
>>>>> On 16 Aug 1995 01:34:44 -0400, vane...@rbdc.rbdc.com (Brandon Van every) said:

Brandon> jas...@mail.utexas.edu (Jason Fossen) writes:
>Why is Lisp not more commonly used for commercial programming?
>To my knowledge, Visual Basic is the most widely used. Is it merely
>historical precedent, you know, positive feedback in the market?

Brandon> If you know something about Lisp, and you know something about Visual
Brandon> Basic, then you know that these are terribly different languages.
Brandon> Which would give you a lot of material for answering your own
Brandon> question.

Also, I am not too sure about the `most widely used' attribute of VB.
I once heard that the extension language of, say, Excel was far more
widely used.
I myself get the impression that, since everbody needs to hack at
least his/her autoexec.bat to get the beast running, the most widely
used language is DOS-Batch.

Now, what does that tell us about the Lisp market?

Holger

--
------------------------------------------------------------------------------
Holger D"urer Tel.: ++49 421 218-2452
Universit"at Bremen Fax.: ++49 421 218-2720
Zentrum f. Kognitionswissenschaften und
FB 3 -- Informatik
Postfach 330 440 <Holger...@PC-Labor.Uni-Bremen.DE>
D - 28334 Bremen <http://www.pc-labor.uni-bremen.de/Duerer/Holger.html>

ActiVision

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
Blake McBride (bl...@edge.net) wrote:


: Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
: >In article <activisD...@netcom.com> act...@netcom.com "ActiVision" writes:

: >> 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.
: >

: >My reason is simply. I already a 3 C compilers, and it's pain making


: >them all work under DOS. I have to keep switching enviroment variables
: >each time I change project. I have GNU C, and that makes the list one
: >C compiler longer. Of course, I try to avoid using C...

: GCC doesn't really support Windows 3.1, NT 3.x or '95. It's just
: good for command line utilities.

Basically true until recently; there's a DJGPP port of Win32 on the Cygnus FTP
site.

: >
: >I'd love a Lisp system, and I'd prefer not to have to write or port
: >my own, esp if it's a CL system we're talking about. CLISP is not yet
: >available for Windows. NT or Win95 support would make it very popular,
: >esp these days.
: >

: I was/am willing to do the NT/95 port and add a really easy to use GUI
: - if I could only get CLISP to compile with the Microsoft compiler
: without devoting my life and without fighting the lisp maintainers.

Ok, so what about GNU CL or AKCL, other Common-Lisps-in-C that I know of?
If you're feeling a bit ambitious, what about a Windows port of CMU CL?

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


Paul Snively
psni...@activision.com

Blake McBride

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to

Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
>In article <activisD...@netcom.com> act...@netcom.com "ActiVision" writes:

>> 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.
>

>My reason is simply. I already a 3 C compilers, and it's pain making
>them all work under DOS. I have to keep switching enviroment variables
>each time I change project. I have GNU C, and that makes the list one
>C compiler longer. Of course, I try to avoid using C...

GCC doesn't really support Windows 3.1, NT 3.x or '95. It's just
good for command line utilities.


>


>I'd love a Lisp system, and I'd prefer not to have to write or port
>my own, esp if it's a CL system we're talking about. CLISP is not yet
>available for Windows. NT or Win95 support would make it very popular,
>esp these days.
>

I was/am willing to do the NT/95 port and add a really easy to use GUI
- if I could only get CLISP to compile with the Microsoft compiler
without devoting my life and without fighting the lisp maintainers.

Brandon Van every

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
jas...@mail.utexas.edu (Jason Fossen) writes:

>Why is Lisp not more commonly used for commercial programming?
>To my knowledge, Visual Basic is the most widely used. Is it merely
>historical precedent, you know, positive feedback in the market?

If you know something about Lisp, and you know something about Visual


Basic, then you know that these are terribly different languages.

Which would give you a lot of material for answering your own

question.

Cheers,
Brandon
--
Brandon J. Van Every | Computer Graphics | The sun attempts
| | to be white,
vane...@rbdc.rbdc.com | C++ UNIX X11 Motif | as white as
http://rbdc.rbdc.com/~vanevery | HTML CGI Perl TCL/Tk | daytime.

Norbert Reithinger

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to

In article <MARCUS.95A...@sayre.sysc.pdx.edu> mar...@sysc.pdx.edu (Marcus Daniels) writes:

[ ... stuff deleted ...]

2. Dare I say CLISP is a mature implementation. The empty macro
substitutions you mention are a result of conventions that exist
throughout the C code of CLISP. It would be a huge job to change
these usages, and would almost certainly result in many bugs. In any
case, a lot of work. In my opinion, the only "necessity" is dealing
with actual *bugs*.


From my point of view, it is a mature implementation! We develop stuff
with ACL on Suns and HPs and had to install it at a university without
an Allegro licence. And as far as I can see, CLISP runs on almost any
iron with cables inside, that is why we chose it as the most portable
system. Porting itself took me two evenings at home using my Linux-PC.
No problems 'till now. And it is half as fast on my PC (486DX-100)
as on a Sun-10!

When I tried to install CLISP on Sun/HP I got weird compiler errors
(our application needs lots of memory for arrays). Bruno's support was
immediate and very helpful.

Ok, there are some ugly corners (if heavily loaded, it core-dumps
sometimes when encountering an error). But, hey, it's more stable than
Windoze '95/96/97/98/99 ever will be :-)

Just $0.02 from a thankful "customer", Norbert

--
o---------------------------------------------------------------o
|NET: be...@dfki.uni-sb.de | PHONE: +49-681-302-5346 |
o---------------------------------------------------------------o
|POST: Norbert Reithinger, DFKI GmbH, Stuhlsatzenhausweg 3 |
| D-66123 Saarbruecken, Germany |
o---------------------------------------------------------------o
| "Je einfacher denken, meine Damen und Herren, ist oft eine |
| gute Gabe Gottes." Konrad Adenauer |
o---------------------------------------------------------------o

Marco Antoniotti

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to


From: Cyber Surfer <cyber_...@wildcard.demon.co.uk>
Newsgroups: comp.lang.lisp
Date: Tue, 15 Aug 95 12:03:50 GMT
Organization: The Wildcard Killer Butterfly Breeding Ground
Lines: 25
Reply-To: cyber_...@wildcard.demon.co.uk
X-NNTP-Posting-Host: wildcard.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27

In article <MARCOXA.95...@mosaic.nyu.edu>
mar...@mosaic.nyu.edu "Marco Antoniotti" writes:

> What about a free (or at least below-100-bucks) CLIM with Motif and
> Windows attachment? What about a standard FFI?
>
> Sorry, you threw the flame bait :)

When you refer to a standard FFI, do you mean one that is standard
at the source level, or at the binary level? MS Windows has an FFI
convention already - just use the Pascal parameter passing that MS
Windows itself uses. I don't know of a language system for Windows
that uses any other FFI at the binary level, altho the non-C FFIs
may differ widely at the source level.

I mean at the source code level. C is C and Pascal is Pascal. Why are
the FFI's of CMUCL and Allegro different ?!? Why does not Franz
provide a compatibility package with the CMUCL FFI conventions?

CL + CLIM for less than $100 would be dynamite! $300 would be still
be good value, in my opinion. It might be competitive with Smalltalk/V,
for example. Allegro CL for Windows costs <ahem> a lot more than that,
and it's the cheapest commercial CL that I know of. "Cheap" is not
the word that springs to mind...

SARCASTIC MODE ON

Well! The Apple management is wondering why they did not sell their
computers and OS for much less, seven or eight years ago. But Aug 24th
is approaching now :)

Give me a Visual Basic environment! :)

SARCASTIC MODE OFF

Blake McBride

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to

act...@netcom.com (ActiVision) wrote:
>Blake McBride (bl...@edge.net) wrote:
>
>
>: Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
>: >
>: >I'd love a Lisp system, and I'd prefer not to have to write or port

>: >my own, esp if it's a CL system we're talking about. CLISP is not yet
>: >available for Windows. NT or Win95 support would make it very popular,
>: >esp these days.
>: >
>
>: I was/am willing to do the NT/95 port and add a really easy to use GUI
>: - if I could only get CLISP to compile with the Microsoft compiler
>: without devoting my life and without fighting the lisp maintainers.
>
>Ok, so what about GNU CL or AKCL, other Common-Lisps-in-C that I know of?
>If you're feeling a bit ambitious, what about a Windows port of CMU CL?

I'll port any of them so long as I don't have to fight the thing. That
means no variable argument C macros and reasonably sized modules in CLISP,
or the ability to perform normal links with GCL. Basically, I'm willing
to port anything that "should" work but doesn't, as opposed to something
that obviously won't work (as described above).

Scott Wheeler

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
In Article <MARCUS.95A...@sayre.sysc.pdx.edu> Marcus Daniels
writes:
>...

>1. It is true that CLISP uses macros in a fairly aggressive way.
>The alternative would be to use inline functions; a feature which is
>not standardized (although prevalent).
>...

This is standardised in C++, including variable numbers of arguments.
Given the wide availability of GNU C++, have you considered using the
"better C" subset of C++ as the intermediate language? There is one
limitation with respect to C macros - since "inline" is a compiler
hint like "register", different implementation are at liberty not to
inline some constructions (i.e. there could be a performance loss
relative to macros with some compilers).

Scott

Cyber Surfer

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
In article <RAR.95Au...@birch.csl.sri.com>
r...@birch.csl.sri.com "Bob Riemenschneider" writes:

> Digitool's MCL 3.0 Champion Edition, "available only to individuals and
> students for championing the use of MCL at home, in companies, or
> universities" but "identical in software content and capability" to the
> regular MCL 3.0 release, is $135 for students and $295 for non-students.
> (If you're a company, MCL 3.0 is $595, still considerably cheaper than
> Allegro for Windows.) No CLIM at the moment, but there's a Mac version of
> Garnet.

Can Digitool's MCL 3.0 Champion Edition deliver stand alone code, and
does it use native code?

Would that be a Mac version that you're talking about? Sadly, altho
I may have access to a Mac, I can't use one for programming. I'm looking
for a CL for Windows. Put another way, I can't choose the hardware,
and my OS choices are also limited - to Windows. If I'm lucky, I may
possibly be able to use Linux.

Thanks.

Cyber Surfer

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
In article <40rhgg$6...@excalibur.edge.net> bl...@edge.net "Blake McBride" writes:

> GCC doesn't really support Windows 3.1, NT 3.x or '95. It's just
> good for command line utilities.

That's what I suspected. Anyway, I already have access to all the
C/C++ compilers I'll ever need. The only way I can imagine myself
using GCC would be if I were using Linux, but I'd much rather be
using Lisp, as I've said before. It's hard to avoid using C, but
that's why I'm so interested in Lisp implementations.

> I was/am willing to do the NT/95 port and add a really easy to use GUI
> - if I could only get CLISP to compile with the Microsoft compiler
> without devoting my life and without fighting the lisp maintainers.

I know the problem - I tried it last year (or was it earlier?) using
Symantec's C compiler. The proprocessor had a bug in it (known to
Symantec, I think) that stopped it reading one of the CLISP header
files properly, plus it couldn't compiler the GNU C proprocessor.

I didn't get far enough to find any more problems, but as the compiler
version (6.0) I was using was known to have a fair number of bugs,
I felt my time could be better used either looking for another
compiler, or another Lisp. Then Bruno Haible emailed me to say that
he was porting CLISP using GNU C, and I left it to him. After all,
he was the ideal person to do the port.

These days, I don't have any choice, as the time just isn't available
anymore. I barely have time to _use_ CLISP, never mind port it.

Cyber Surfer

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
In article <MARCUS.95A...@sayre.sysc.pdx.edu>
mar...@sysc.pdx.edu "Marcus Daniels" writes:

> A NT port is being studied -- using win32 GCC from Cygnus. No promises.

Excellent! Well, whatever happens, I wish you good luck. CLISP is
a fine CL implementation. I wasn't aware of the Cygnus compiler.

If you get to the beta stage, I'll be happy to be a beta tester.
I may possibly have access to an NT machine (ideally _mine_), but
if I can't use NT, Win95 is a likely possiblity. I can't make any
promises, either, but it'll be very hard for me to avoid NT and
Win95 in the next year.

Thanks for the information.

Dirk Zoller

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
Blake McBride (bl...@edge.net) wrote:
: GCC doesn't really support Windows 3.1, NT 3.x or '95. It's just

: good for command line utilities.

Gcc works fine with Emacs. I don't miss much from Borland C when I use
emacs/gcc and I miss a lot from Emacs when I use Borland C. If you
dislike emacs, then it might be worthwile to have a look at xwpe, an
astonishing clone of the Borland Develompent environment for X11.

If you dislike Emacs but on the other hand you are so fit in Windows
that you easily would hack a GUI for clisp (if only that damn clisp
would compile with MS-C) then here's a suggestion: As a sort of
warming up hack something like xwpe for Windows, then use that
combination to do that clisp port and GUI. Many people would be
grateful. Otherwise please consider becoming a little more realistic.

Apropos GUIs. Some Lisps/Schemes seem to use the Tk toolkit. Does
anybody know if clisp might go the same direction some day?

--
d...@roxi.rz.fht-mannheim.de <Dirk Zoller>

Marcus Daniels

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
>>>>> "Blake" == Blake McBride <bl...@edge.net> writes:
In article <40rhgg$6...@excalibur.edge.net> Blake McBride <bl...@edge.net> writes:

Blake> GCC doesn't really support Windows 3.1, NT 3.x or '95. It's
Blake> just good for command line utilities.

ftp.cygnus.com:/pub/sac


Cyber Surfer

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
In article <MARCOXA.95...@mosaic.nyu.edu>
mar...@mosaic.nyu.edu "Marco Antoniotti" writes:

> I mean at the source code level. C is C and Pascal is Pascal. Why are
> the FFI's of CMUCL and Allegro different ?!? Why does not Franz
> provide a compatibility package with the CMUCL FFI conventions?

I can only guess, as I've not used either of these systems, and
if you're refering to Allegro for Unix, then it's unlikely that
I'll ever be able to comment on it. As for CMUCL, that may depend
on whether a Linux version is or will become available.

Meanwhile, I can't comment on either system.



> CL + CLIM for less than $100 would be dynamite! $300 would be still
> be good value, in my opinion. It might be competitive with Smalltalk/V,
> for example. Allegro CL for Windows costs <ahem> a lot more than that,
> and it's the cheapest commercial CL that I know of. "Cheap" is not
> the word that springs to mind...
>
> SARCASTIC MODE ON
>
> Well! The Apple management is wondering why they did not sell their
> computers and OS for much less, seven or eight years ago. But Aug 24th
> is approaching now :)
>
> Give me a Visual Basic environment! :)
>
> SARCASTIC MODE OFF

Of course, a produce may not be "cheap" (that's subjective), but
still be good value for money. However, for many programmers,
it may be acedemic, if they can't afford the development software
that'll allow them to use Common Lisp (he said, picking a Lisp
dialet at random (-; ) professionally.

I'm currently trying to get someone else to buy me Allegro CL
for Windows. If it works, I may get it sometime later this year.
Of course, it's much easier for me to get C++ compilers, or
even a Smalltalk system. I don't even have to justify them!
I can just pull them off a shelf...

The world is mad, I say. ;-)

David B. Lamkins

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
In article <808558...@wildcard.demon.co.uk>,
cyber_...@wildcard.demon.co.uk wrote:

{...]

> Can Digitool's MCL 3.0 Champion Edition deliver stand alone code, and
> does it use native code?
>
> Would that be a Mac version that you're talking about? Sadly, altho
> I may have access to a Mac, I can't use one for programming. I'm looking
> for a CL for Windows. Put another way, I can't choose the hardware,
> and my OS choices are also limited - to Windows. If I'm lucky, I may
> possibly be able to use Linux.

MCL is Mac-specific. It generates very good 68K code. A version is in
the works to generate PPC code, again for the Mac. See
http://www.digitool.com/ for more info.

I think you have literally one choice if you're constrained to Windows and
Common Lisp: Franz Allegro Common Lisp for Windows. Venue has a DOS
version of Medley -- you should talk to them about future plans.

Dave
--
CPU Cycles: Use them now or lose them forever...
http://www.teleport.com/~dlamkins

Marcus Daniels

unread,
Aug 16, 1995, 3:00:00 AM8/16/95
to
>>>>> "Dirk" == Dirk Zoller <d...@roxi.rz.fht-mannheim.de> writes:
In article <1995Aug16.2...@roxi.rz.fht-mannheim.de> d...@roxi.rz.fht-mannheim.de (Dirk Zoller) writes:

Dirk> Apropos GUIs. Some Lisps/Schemes seem to use the Tk
Dirk> toolkit. Does anybody know if clisp might go the same direction
Dirk> some day?

I'm not sure what you mean by GUI. Some folks have been talking about
GUI development environments. Other people are apparently simply
refering to delivery libraries and tools.

A GUI library library much like Stklos could be implemented
more-or-less independently of the CLISP sources. The FFI declarations
could even be isolated in their own file, so that the library would
be easy to port to other Common Lisp implementations. Someone just
needs to do it!

From what I've seen of STk, I'm not convinced it is such a great idea
to try to hide Tk inside CLOS wrappers. I think it gives users
unreasonable expectations about the precision they command as
programmers. Maybe this is just a case of *my own* unreasonable
expectations :-). Stk is a certainly a useful package.

The alternatives to Tk I see are: the objcX library, and Amulet. The
objcX library is a Motif-based OpenStep appkit clone. Amulet, of
course, is the successor to Garnet. I'd go in the direction of the former
because I think Objective C would be much cooler to integrate into
CLISP; especially since the plan with GUILE is to implement elisp
primitives, and there already exists a network-ready GUILE/ObjC
callin/callout facility.

With RPC glue between CLISP, Emacs, GUILE, and ObjC the possibilities
for a application delivery *and* implementation of GUI debugging
environment would be broad.


Peter Burwood

unread,
Aug 17, 1995, 3:00:00 AM8/17/95
to
In article <40ng4k$k...@excalibur.edge.net> bl...@edge.net (Blake McBride) writes:

> 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.

This is false.

I have ported CLISP using a commercial compiler that does not support
variable argument macros and I never came across this problem. Further,
I had no problem with the size of the modules. The compiler I used is
*standard ANSI C*. I started with the 26/01/94 distribution and the
commercial compiler I use still works with the 23/06/95 distribution. So
either things changed or you need to flame you crappy commercial
compiler and `mainstream' hardware instead and not CLISP.

Looking at the source, it also appears that I am not alone here. Other
commercial compilers are listed as being able to compile CLISP.

> 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!

Again I disagree. For example, there was a bug in the previous version
of my compiler which manifested itself in three routines in one of the
files. A patch was included in the main distribution for this compiler
by using #define's and #ifdef's. Bruno also helped immensely with
getting my machine's brain dead pathname system into the main
distribution.

> 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.

Well given my experience noted above, it sounds like you had the wrong
attitude and it's not suprising that maybe Bruno told you where to go.

> [lots of further anti-academic attitude snipped]

regards,
Pete
-- Email: p...@arcangel.demon.co.uk