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?
In article <··········@geraldo.cc.utexas.edu>
·······@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?
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."
In article <············@wildcard.demon.co.uk> Cyber Surfer <············@wildcard.demon.co.uk> writes:
> 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: ····@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: :-)
===========================================================================
In article <··········@cantaloupe.srv.cs.cmu.edu>
···@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.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
·······@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?
--
Blake McBride Algorithms Corporation
615-791-1636 voice 3020 Liberty Hills Drive
615-791-7736 fax Franklin, TN 37064
·····@edge.net USA
[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!
From: Brian Leverich
Subject: Re: Why is Lisp not more widely used?
Date:
Message-ID: <40nt4u$glk@rand.org>
Erik Naggum (····@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
········@rand.org
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".
·····@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
[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>
--
help! I'm lost in an n-dimensional universe and I don't know what n is!
Blake McBride (·····@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
: ·····@edge.net USA
Paul Snively
Activision, Inc.
········@activision.com
In article <·················@netcom.com>,
ActiVision <·······@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
······@convex.com
In article <·················@netcom.com> ·······@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...
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>In article <·················@netcom.com> ·······@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.
--
Blake McBride Algorithms Corporation
615-791-1636 voice 3020 Liberty Hills Drive
615-791-7736 fax Franklin, TN 37064
·····@edge.net USA
In article <··········@excalibur.edge.net> ·····@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.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
Blake McBride (·····@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?
--
···@roxi.rz.fht-mannheim.de <Dirk Zoller>
Blake McBride (·····@edge.net) wrote:
: Cyber Surfer <············@wildcard.demon.co.uk> wrote:
: >In article <·················@netcom.com> ·······@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
: ·····@edge.net USA
Paul Snively
········@activision.com
·······@netcom.com (ActiVision) wrote:
>Blake McBride (·····@edge.net) wrote:
>
>
>: Cyber Surfer <············@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).
--
Blake McBride Algorithms Corporation
615-791-1636 voice 3020 Liberty Hills Drive
615-791-7736 fax Franklin, TN 37064
·····@edge.net USA
Newsgroups: comp.lang.lisp
From: ·······@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
In article <··················@ix.cs.uoregon.edu>
····@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.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
In article <··········@rand.org> ········@atlantis.rand.org (Brian Leverich) writes:
From: ········@atlantis.rand.org (Brian Leverich)
Newsgroups: comp.lang.lisp
Date: 14 Aug 1995 16:20:46 GMT
Organization: RAND Corporation
Lines: 42
X-Newsreader: TIN [version 1.2 PL2]
Erik Naggum (····@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: ·······@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
In article <·····················@mosaic.nyu.edu>
·······@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...
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
> ... 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...
It ain't exactly expensive either... I get the message that you want
a highly sophisticated common lisp development environment fully
supported by a top notch dedicated development team with unlimited
funding stretching way out into the next millenium for FREE!
Really how much are you prepared to pay for such a product?
What features/facilites would you consider essential?
Which platforms must it support?
How many copies will you buy?
If you can answer these questions realistically I guess the industry
could come up with an answer. Under the definition of free market
economics it already has.
It really depends on how serious you are, I started out playing
with freeware lisp at home on a vaxstation saved from the crusher.
Things are better now and I got to this nirvana by putting my money,
time and career where my mouth was and investing in something
that I believed in. I don't have the gift of direct funding but I use
my rentability, reputation and anything else (duress, screaming
and shouting, foaming at the mouth) to get the message over to
the money people, and make damn sure I deliver if they give me
a shot. In my experience people (managers are people too) are
more impressed by results than rhetoric. Drum up the support/cash to
obtain a single copy of your favourite environment then blow their
socks off with the amazing way you can turn out shit hot applications.
Convince others... spread the word... then lean on the poor old
vendors. The only currency that researchers and engineers can
use is hard cash so get it flowing their way and you may have
some influence on what they do with it. It gets harder and harder
for individuals to influence shit these days so now is a good
time (17:30pm on a friday may be stretching my metaphor a tad here
:-) - Good luck.
/simon
In article <··········@xenon.bt-sys.bt.co.uk>
··············@bt-sys.bt.co.uk "Simon Beaumont" writes:
> It ain't exactly expensive either... I get the message that you want
> a highly sophisticated common lisp development environment fully
> supported by a top notch dedicated development team with unlimited
> funding stretching way out into the next millenium for FREE!
Not so. Any Common Lisp (even a subset) for Windows, with an FFI and
support for callbacks, will suit me. The last version of XLISP that
I looked at came close, since it was available as a Win16 binary.
However, it had less support for Windows than an OS/2 version of
XLISP from a few years earlier. I'll have to look for the latest
version of XLISP again, as it well have been updated.
If I'm looking for a Lisp as alternative to C++, then it'll have
to produce stand alone binaries, just like a C/C++ compiler. I'd
love to program more in Lisp, but sadly, no Common Lisp or subset
that I've seen - so far - has been capable of writing Windows apps.
Allegro CL for Windows is a different matter.
> Really how much are you prepared to pay for such a product?
Personally? No more than for a C++ compiler system for Windows.
Professionally, I could get someone else to pay for it. Of course,
nobody has done this yet.
> What features/facilites would you consider essential?
The option to produce stand alone Win16 or Win32 binaries, so that
a user can install (via a typical installer used in almost all
Windows apps these days) and run the code without the development
enviroment, or knowing - or even caring - which language it was
written in.
Support for calling functions in DLLs, via an FFI. Callback support,
so that other modules can call Lisp functions, e.g. for enumerating
fonts etc.
> Which platforms must it support?
Win16 or Win32. Ideally both, tho not necessarily in the same
package. Allegro CL for Windows and Windows NT is a good example,
tho buying both versions could be very expensive. If the Win32
version costs the same as the Win16 version, then Allegro CL
would be approx 6 times the cost of SC++ (Win16 and Win32 support
in one package), or approx 3 times the cost of VC++ (Win16 and
Win32 support in two packages).
> How many copies will you buy?
Just one. Ideally, the runtime should be royalty free, and I
believe that Allegro CL for Windows is such a product. It's
extemely unlikely that I'll be sharing any Lisp development
with another programmer, but if that were necessary, then it
would be someone else's problem, not mine. Nobody is demanding
that I should code in Lisp, not even me. I can only recommend
it as a language that I'm familiar and _productive_ with.
> If you can answer these questions realistically I guess the industry
> could come up with an answer. Under the definition of free market
> economics it already has.
Well, one answer is Allegro CL for Windows. I'll be interested
in any alternatives, but as I've no details, never mind reviews,
I can't comment on them.
> It really depends on how serious you are, I started out playing
> with freeware lisp at home on a vaxstation saved from the crusher.
I have a DOS machine. It can only just run Windows. I can use
a number of freeware Lisps, and that's exactly what I've been
doing for the last few years. What I can't do is convince anyone
that they can be used for Windows development.
> Things are better now and I got to this nirvana by putting my money,
> time and career where my mouth was and investing in something
> that I believed in. I don't have the gift of direct funding but I use
> my rentability, reputation and anything else (duress, screaming
> and shouting, foaming at the mouth) to get the message over to
> the money people, and make damn sure I deliver if they give me
> a shot. In my experience people (managers are people too) are
> more impressed by results than rhetoric. Drum up the support/cash to
> obtain a single copy of your favourite environment then blow their
> socks off with the amazing way you can turn out shit hot applications.
My money is currently going towards a new machine. Then I may
have chance of running some of the current development systems,
whatever the language may be. Please note that I'm unemployed,
which means that most of my money goes on basic necessities.
The costs of development software make me very conservative, just
like all the potential employers I find. What they want is C++
developent for Windows. What I'm expected to do is look for work
that I'm likely to get, not stuff that is in very little demand.
Fortunately, nobody is asking what I'm spending my money on, so
all I need is the money...
> Convince others... spread the word... then lean on the poor old
> vendors. The only currency that researchers and engineers can
> use is hard cash so get it flowing their way and you may have
> some influence on what they do with it. It gets harder and harder
> for individuals to influence shit these days so now is a good
> time (17:30pm on a friday may be stretching my metaphor a tad here
> :-) - Good luck.
That's what I'm doing. Of course, most people see no reason to
listen to me - they're often too busy arguing over the petty
differences between C and Pascal to worry about the advantages
of Lisp. For some programmers, it's a religious issue. I get odd
looks when I mention Lisp, a little like the looks I got whenever
I mentioned MIDI and Windows in the same breath, 5 years ago.
Those looks said, "You're crazy!"
Well, so what if I'm a little crazy? I'm using Lisp coz _I can_.
What I'm not yet able to do is write Windows apps in Lisp, but
in theory (using, say, Allegro CL), I can. The difficulty is of
a financial, not a technical, nature.
Meanwhile, I have an idea which I'm using to convince someone
that I should use Lisp, as I can use it to implement the software.
Perhaps _he'll_ pay for the hardware and software I need...
Obviously, we both crazy, but the idea is a good one, and if
I get to work on it, it'll someday be possible to say, "Look,
here's something done in Lisp, and it works, and more importantly,
it works better than the alternative, written by MS in C/C++."
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
>>>>> "Blake" == Blake McBride <·····@edge.net> writes:
In article <··········@excalibur.edge.net> Blake McBride <·····@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.
From: Scott Wheeler
Subject: Re: CLISP & GCL portability was Re: Why is Lisp not more widely used?
Date:
Message-ID: <jyxsva@bmtech.demon.co.uk>
In Article <····················@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
>>>>> "Brian" == Brian Leverich <········@atlantis.rand.org> writes:
In article <··········@rand.org> ········@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!!
In article <····················@sayre.sysc.pdx.edu>
······@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.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
In article <············@wildcard.demon.co.uk> Cyber Surfer <············@wildcard.demon.co.uk> writes:
> 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
In article <·················@birch.csl.sri.com>
···@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.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
In article <············@wildcard.demon.co.uk>,
············@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
In article <·························@ip-pdx4-47.teleport.com>
········@teleport.com "David B. Lamkins" writes:
> 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.
As I've explained, I can't use a Mac, and I don't have access to
one for development, and most certainly not for development in Lisp.
C++, using the Win32 API, yes. It's a strange world all right!
> 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.
I have no use at all for DOS - in a month or two I should be able
to stop using DOS completely, and eventually stop using DOS software.
The main problem with Allegro CL for Windows is that it appears to
be available in two versions, Windows and Windows NT. One is Win16,
which I have a use for, and the other is Win32, which I also have
a use for. Now, while I can get many tools that are supplied with
Win16 _and_ Win32 vesions in the same package, Franz appear to be
asking developers to pay for two different versions.
This could mean that I'll have to use C++ instead. ISTR that Allegro
CL for Windows costs $1000 (I'm only considering the professional
version, coz that's what I'd need as an alternative to C++), and
the NT version was $1500. Please correct me if I'm remembering this
wrong. A typical C++ compiler for Windows is a couple of hundred
dollars. A big price gap! Guess who wins?
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
* 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
In article <··········@excalibur.edge.net> ·····@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...
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
>>>>> "CS" == Cyber Surfer <············@wildcard.demon.co.uk> writes:
In article <············@wildcard.demon.co.uk> Cyber Surfer <············@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.
In article <····················@sayre.sysc.pdx.edu>
······@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.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
>>>>> "david" == David Boles <······@news.eng.convex.com> writes:
In article <··········@zeppelin.convex.com> ······@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!
······@sysc.pdx.edu (Marcus Daniels) wrote:
>>>>>> "david" == David Boles <······@news.eng.convex.com> writes:
>In article <··········@zeppelin.convex.com> ······@news.eng.convex.com (David Boles) writes:
>
>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.
So I take it portability is not a factor.
>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.
Absolutly not true! CLISP's _unnecessary_ use of variable argument macros
is _not_ "done if the feature is available". Neither are the
_unnecessarily_ huge functions.
>
>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!
Ture to an extant. However, it's totally academic since the resulting
pre-processed code is so large (_unnecessarily_) many (most?) compilers
can't compile it anyway.
>
>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.
Are you saying free software = use GCC/Unix or the hell with you?
Oh, and I'm not whining, I'm trying to share my opinion on why lisp
isn't more popular. And the information I present _is_ accurate.
I can prove everything I say via CLISP's code and copies of letters from
you and Bruno.
>
>Ultimately, it isn't about "loss of efficiency", it is about raping the
>code without considering perfectly workable alternatives.
Making functions a size which is understandable by humans and commercial
compilers is hardly "raping"! This clearly demonstrates your attitude
(as maintainer of CLISP).
>Let me be very concrete:
>
>These huge blocks of code Blake McBride vaguely talks about have
>not even be named!
>
Absolutly _not_ true! I have been quite explicit with Bruno while
attempting to work with him to solve the problem. He wasn't interested.
--blake
In article <····················@sayre.sysc.pdx.edu>
······@sysc.pdx.edu "Marcus Daniels" writes:
> 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.
Sadly, I don't use Unix, and so I can't use it to cross compiler
for Windows.
> 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!
The C compiler I use was unable to link the GNU preprocessor as a
DOSX binary, and the DOS binary ran out of memory. Obviously I was
using the wrong compiler, but I was unable to change that. These
days it's just too late.
> 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.
I'm well aware of the alternatives. Please note that I'm keen to
stress that my problems were due to the bugs and limitations of
the _commercial C compiler_ that I was using. I'm now using a "fixed"
version, and it still has the ## bug that stopped it reading one
of the CLISP headers (guess which one).
GNU C has many advantages over the compiler I use for Win32
development, but I'm far more familiar with GNU C, and until
Bruno Haible emailed me to let me know that he was porting
CLISP himself, I had no idea that it could be used to produce
Win32 binaries.
I should add that I received excellent help from Bruno, and my
failure to port CLISP was not due to any lack of support from
him. In fact, I was very impressed when he mailed the source
code to me on floppies, and even more impressed when I _saw_
the source code.
> Ultimately, it isn't about "loss of efficiency", it is about raping the
> code without considering perfectly workable alternatives.
I'm not sure what this means, or what it refers to. I didn't find any
workable alternatives, and I was certainly motivated to look for them.
I also had the time, last year.
This year is very different. If it were not so, then I might resume
my interest in porting CLISP to Win32.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
In article <····················@sayre.sysc.pdx.edu> ······@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: ····@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
In article <············@wildcard.demon.co.uk> Cyber Surfer <············@wildcard.demon.co.uk> writes:
From: Cyber Surfer <············@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: ············@wildcard.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
In article <·····················@mosaic.nyu.edu>
·······@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
Cheers
--
Marco G. Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@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
In article <·····················@mosaic.nyu.edu>
·······@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. ;-)
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
>>>>> "Blake" == Blake McBride <·····@edge.net> writes:
In article <··········@excalibur.edge.net> Blake McBride <·····@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
>>>>> "Dirk" == Dirk Zoller <···@roxi.rz.fht-mannheim.de> writes:
In article <······················@roxi.rz.fht-mannheim.de> ···@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.
In article <··········@excalibur.edge.net> ·····@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: ···@arcangel.demon.co.uk
···@arcangel.demon.co.uk (Peter Burwood) wrote:
>In article <··········@excalibur.edge.net> ·····@edge.net (Blake McBride) writes:
>> 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.
It is _not_ false. I don't know or really care which compiler you
use but I can assure you they use macros with missing arguments in
many, many places. This is not ANSI C. I can not speak about what
compilers do or do not support this *feature*. If the thing works
on your machine than obviously your compiler definitly supports the
feature, period.
>> 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.
Oh, I don't doubt that they will insert an ifdef or two. That's not the
problem. The problem has to do with fundemental design issues which
were chosen not out of necessity, but out of disregard for anything
but academic environments (although I understand that they certainly
have this right).
>
>> 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.
In spite of what it may seem my attitude towards Bruno and CLISP is one
of great respect and appreciation! I completely understand that they
wrote it, and they can do with it as they like. I also understand that
they don't owe me or anybody else anything.
I really want lisp and CLISP/GCL to become more popular, used and
supported. I think this would be good for me, lisp and programmers in
general. I think I represent, to a greater or lesser degree, the
biggest block of commercial programmers. I was, have, and am willing
to spend time on making GCL/CLISP available to programmers like myself.
However, I find myself quite put off by the attitudes I have experienced.
It is certainly their choice, but the ramifications will effect lisp
and programmers in general for a long time to come.
--blake
In article <··········@excalibur.edge.net> ·····@edge.net (Blake McBride) writes:
> ···@arcangel.demon.co.uk (Peter Burwood) wrote:
> >In article <··········@excalibur.edge.net> ·····@edge.net (Blake McBride) writes:
>
> >> 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.
>
> It is _not_ false.
Oh yes it is (said in best pantomime voice).
I'll highlight the relevant part of your complaint :-
> >> 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.
As I said, I use a commercial compiler and can compile CLISP with it.
Hence your statement is false, period.
> I don't know or really care which compiler you
> use but I can assure you they use macros with missing arguments in
> many, many places. This is not ANSI C. I can not speak about what
> compilers do or do not support this *feature*. If the thing works
> on your machine than obviously your compiler definitly supports the
> feature, period.
There are plenty of uses of macros without arguments between all the
commas, which is what I presume you mean about missing arguments, rather
than the incorrect number of arguments. The compiler I use certainly
complains if there are the wrong number, but seems happy as long as
there are the right number of commas. I wasn't aware that using a blank
argument was not ANSI C, but seeing as I am not an expert in C, I'll bow
to your greater knowledge here. I always, apparantly mistakenly, assumed
a parameter to a macro could be blank.
However, in your original comment (see above), you said `variable
argument macros'. This is defined in the GNU CC documentation to be one
using ellipses in the argument list of the macro definition, ala printf.
Well after a quick grep of the source code, I can see no such occurence
of a macro definition. So again, your accusation was false.
> >> 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.
>
> Oh, I don't doubt that they will insert an ifdef or two. That's not the
> problem. The problem has to do with fundemental design issues which
> were chosen not out of necessity, but out of disregard for anything
> but academic environments (although I understand that they certainly
> have this right).
I mentioned fix for a bug to highlight the fact that they will `support
patches for "brain dead" [comercial] compilers.' Again your false
accusation.
I also mentioned that Bruno helped with my OS's pathname system. This
was considerably more work than a few #ifdef's. For example, in one of
the source files it amounted to more than 1000 lines or a 10% increment
in size. My OS is not Unix and has it's percularities like MSDOS or
AMIGA DOS, etc., and I had to make changes to a number of other files to
support it. Again, Bruno helped considerably and I am grateful that he
did so.
I'm sure there are some `fundemental design issues' which may cause a
problem and perhaps you could clarify which design decisions caused you
so much grief ? I'm certainly interested providing it is not down to
lame limitations of your compiler.
I don't like speculating, but it is starting to sound like you wanted
Bruno to split the source into smaller modules and functions and he
refused. Maybe I'm wrong, and I suspect there is more to it, but if not,
then I repeat - get a decent compiler.
> In spite of what it may seem my attitude towards Bruno and CLISP is one
> of great respect and appreciation! I completely understand that they
> wrote it, and they can do with it as they like. I also understand that
> they don't owe me or anybody else anything.
>
> I really want lisp and CLISP/GCL to become more popular, used and
> supported. I think this would be good for me, lisp and programmers in
> general. I think I represent, to a greater or lesser degree, the
> biggest block of commercial programmers. I was, have, and am willing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ah, yes, those that want it on a plate, wrapped up and working. I am
certainly glad that I am not a member of this block of commercial
programmers, the vultures of humanity, but rather a member of the
smaller block of commercial programmers who realise `there ain't no
such thing as a free lunch'. CLISP is available on a large range of
hardware, so there is nothing stopping anyone using supported hardware
from grabbing it and using it.
> to spend time on making GCL/CLISP available to programmers like myself.
> However, I find myself quite put off by the attitudes I have experienced.
> It is certainly their choice, but the ramifications will effect lisp
> and programmers in general for a long time to come.
It all reminds me of the old adage,
`Those that can do, those that can't moan'.
Pete
···@arcangel.demon.co.uk
>>>>> "Blake" == Blake McBride <·····@edge.net> writes:
In article <··········@excalibur.edge.net> Blake McBride <·····@edge.net> writes:
me> Second of all, many Unix compilers *can* handle these macros. The
me few places GCC extensions are used in CLISP, it is only done if the
me> feature is available.
Blake> Absolutly not true! CLISP's _unnecessary_ use of variable
Blake> argument macros is _not_ "done if the feature is available".
Blake> Neither are the _unnecessarily_ huge functions.
Let's at least use the correct term. By "variable argument"
you mean that some arguments are unused at times.
me> Thirdly, and most importantly, there are already programs that
me> process CLISP source code before it is compiled. It is a simple
me> matter to add another, namely GNU cpp. GNU cpp is already in the
me> distribution. Stop fixating on ANSI C. It is ".d"! Get over it!
Blake> Ture to an extant. However, it's totally academic since the
Blake> resulting pre-processed code is so large (_unnecessarily_) many
Blake> (most?) compilers can't compile it anyway.
Here is all you need to do:
1. Preprocess the thing with GNU CPP.
2. Build the .i files until it breaks your compiler.
3. Email me the location where it breaks, so that we can consider
how it might be appropriate to divide the code.
me> What has become clear to me is that these individuals are not
me> content to investigate these simple alternatives for themselves.
me> They do not understand the nature of free software (or care), and
me> would much rather whine and spread misinformation.
Blake> Are you saying free software = use GCC/Unix or the hell with
Blake> you? Oh, and I'm not whining, I'm trying to share my opinion
Blake> on why lisp isn't more popular. And the information I present
Blake> _is_ accurate. I can prove everything I say via CLISP's code
Blake> and copies of letters from you and Bruno.
Feel free to post anything you like, you certainly haven't hesitated
thus far. It would be much more helpful if you'd simply show where
compiler is breaking. I have no email from you with any real detail;
just a lot of posturing and demands.
I will not make any effort in the direction of changing the usages of
macros in CLISP. Overall, it is a good solution for clarity,
performance, and portability. If some compilers can't handle these
macros, GNU cpp is a workable alternative. I may accept patches if
the effort is executed in a clean way. Personally, *I* don't think it
can be done, and if it could be done, *I* wouldn't do it because it,
because *I* don' tsee the payoff.
I welcome patches to break up unnecessarily large functions (in spite
of the fact I believe your compiler is brain dead). I'm not going
to go changing every function above some arbitrary threshold.
Give me a list of functions that break your compiler.
Blake> Absolutly _not_ true! I have been quite explicit with Bruno
Blake> while attempting to work with him to solve the problem. He
Blake> wasn't interested.
Well, you aren't arguing with Bruno Haible, are you? He probably wasn't
interested because he lacked my naivete. Perhaps he knew better than to
think that you actually wanted to accomplish something.
I apologize for bothering readers of comp.lang.lisp with this matter.
In article <··········@excalibur.edge.net> Blake McBride <·····@edge.net> writes:
Path: cmcl2!rockyd!news.sprintlink.net!news.edge.net!news
From: Blake McBride <·····@edge.net>
Newsgroups: comp.lang.lisp
Date: 17 Aug 1995 18:37:47 GMT
Organization: Algorithms Corporation (615-791-1636)
Lines: 66
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.1N (Windows; I; 32bit)
······@sysc.pdx.edu (Marcus Daniels) wrote:
>>>>>> "david" == David Boles <······@news.eng.convex.com> writes:
>In article <··········@zeppelin.convex.com> ······@news.eng.convex.com (David Boles) writes:
>
>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.
So I take it portability is not a factor.
>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.
Absolutly not true! CLISP's _unnecessary_ use of variable argument macros
is _not_ "done if the feature is available". Neither are the
_unnecessarily_ huge functions.
I have been following this thread and I have not yet read which is the
compiler that does not compile large pieces of code. I want to ask:
1 - what is the compiler (supposedly commercial) which cannot compile
CLISP and
2 - does this compiler comply with the published C standards (whatever
they are)?
3 - if not, has the company producing it made any statement about
compliance in a NEAR future?
Cheers
--
Marco G. Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@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
·······@mosaic.nyu.edu (Marco Antoniotti) wrote:
#>I have been following this thread and I have not yet read which is the
#>compiler that does not compile large pieces of code. I want to ask:
#>
#>1 - what is the compiler (supposedly commercial) which cannot compile
#> CLISP and
32 bit Microsoft and WATCOM compilers (I wouldn't even try Borland
or Symantic). Keep in mind that these compilers are used by thousands
and thousands (millions?) of programmers. They are also used to compile
Windows 3.1, Windows NT and thousands (millions?) of applications.
I think it is somewhat nieve to call these compilers "brain dead"
just because they don't have boundless limitations.
#>2 - does this compiler comply with the published C standards (whatever
#> they are)?
Yes. As previously posted, the standards do not allow for arbitrarly
large modules (or missing argument macros).
[Blake McBride]
| 32 bit Microsoft and WATCOM compilers (I wouldn't even try Borland or
| Symantic).
why wouldn't you "even try" Borland or Symantec (note spelling)?
| Keep in mind that these compilers are used by thousands and thousands
| (millions?) of programmers.
a huge number of users do not make anything non-brain-dead, unless you wish
to say something about those millions at the same time, in which case it is
more likely that something used by millions of _amateurs_ _is_ brain-dead.
which is the brain-dead video tape format: VHS or Betamax? which is used
by professionals, and which by millions of casual users?
| They are also used to compile Windows 3.1, Windows NT
now, if true, this would be very interesting. please provide references!
| I think it is somewhat nieve to call these compilers "brain dead" just
| because they don't have boundless limitations.
if you mean "naive", then no. from _experience_ and sophistication comes
the realization that arbitrary limits is very bad for you and your users.
in case you didn't know, "naive" and "experienced" or "sophisticated" are
as close as you get to antonyms. it is precisely _naivite_ that invite the
unwashed masses to write code with arbitrary limits. just because the
unwashed masses outnumber the professionals doesn't mean they're right. in
fact, quite the opposite is true in the general case.
| Yes. As previously posted, the standards do not allow for arbitrarly
| large modules (or missing argument macros).
look, just because you can't read standards doesn't make them mean what you
want them to mean. of _course_ standards "allow for" arbitrarily large
anything. what standards do, is to avoid _requiring_ arbitrarily large
objects or numbers of things, but instead _require_ that no implementation
impose a maximum smaller than some specific limit. the "minixum maximum"
rule has two goals: (1) discourage boneheads from implementing standards,
and (2) ensure the maximal portability of programs within those limits. in
no way does the "minimum maximum" requirements mean that compilers or
programs that exceed them are non-conforming.
I can't believe you have managed to lead people on for so long. you're
obviously clueless and uncurably so. if you wish to make a shot at
changing this impression, make up your mind that you have posted your last
guess and that you will make all the effort that is required to ensure that
you will never again post wrong information. above all, do not lie.
#<Erik 3017836048>
--
trigraph ??!??! die
In article <··········@excalibur.edge.net> Blake McBride <·····@edge.net> writes:
> ······@sysc.pdx.edu (Marcus Daniels) wrote:
> >>>>>> "david" == David Boles <······@news.eng.convex.com> writes:
> Absolutly not true! CLISP's _unnecessary_ use of variable argument macros
> is _not_ "done if the feature is available". Neither are the
> _unnecessarily_ huge functions.
Then just send us good smaller functions and we could be happy.
> Ture to an extant. However, it's totally academic since the resulting
> pre-processed code is so large (_unnecessarily_) many (most?) compilers
> can't compile it anyway.
In my opinion, a compiler that's not able to cope with a huge
function, lines longer than 251 characters and other unnecessary
limits is not worth its money.
This is especially important as more and more code today is not
humanly written any more, but preprocessed or cross-compiled (maybe
from a language to another). Would you expect a C++ to C (or Fortran
to C or Lisp to C) compiler to generate C source that is easily
readable, with short lines and short function bodies? I wouldn't.
Too many C programmers program with stupid assumptions about the
length and size of objects in their mind. C just makes the use of
known-size object so much easier than arbitrary length objects (not to
say they are a nightmare). The fact that some of those people write C
compilers makes the situation even worse. GNU people generally
don't. The list of programs written in C that barf when fed lines
longer than say 255 characters is too large IMHO.
> Oh, and I'm not whining, I'm trying to share my opinion on why lisp
> isn't more popular.
The availability of CLISP on MS-Windows or any Win* form would
change this? It looks like we all missed the Lisp revolution :)
Just yesterday I saw the Visual C++ editor truncate a line longer than
251 characters. Shouldn't I complain to the vendor of such a limited
piece of software?
Only the C compiler is to blame if it cannot process long lines or
long function bodies, not CLISP. Complain to Micro*oft.
Joerg Hoehle
author of Amiga-CLISP port (just to say that I'm biased)
······@inf-wiss.uni-konstanz.de
>>>>> "CS" == Cyber Surfer <············@wildcard.demon.co.uk> writes:
In article <············@wildcard.demon.co.uk> Cyber Surfer <············@wildcard.demon.co.uk> writes:
CS> Sadly, I don't use Unix, and so I can't use it to cross compiler
CS> for Windows.
From the Win32 GCC readme (at ftp.cygnus.com:/pub/sac)
---------------------------
H-linux.tar.gz linux hosted Win32 target compiler
H-win32.tar.gz Win32 hosted Win32 target compiler
-----------------------------
GCC is hosted on win32; no need for Unix.
CS> The C compiler I use was unable to link the GNU preprocessor as a
CS> DOSX binary, and the DOS binary ran out of memory. Obviously I was
CS> using the wrong compiler, but I was unable to change that. These
CS> days it's just too late.
GNU cpp binaries are everywhere, and have been for several years.
oak.oakland.edu, for example.
me> Ultimately, it isn't about "loss of efficiency", it is about raping
me> the code without considering perfectly workable alternatives.
CS> I'm not sure what this means, or what it refers to.
It only refers to the misguided goal of removing empty macro usages.
CS> I didn't any workable alternatives, and I was certainly motivated to look
CS> for them. I also had the time, last year.
It never occured to you to try preprocessing with a EMX or DJGPP GCC?
Interesting.
Oh and BTW, the MSWindows work that was done on CLISP was released; it is
in the source tree.
Cyber Surfer, you could help me get a win32 binary
release out in a timely fashion! If you could provide me with the
following information:
1. How do file maps work on win32? Like many people I cannot afford
to buy technical manuals for five minutes of use. I understand
that WinNT/Windows95 has a tiered division of virtual
memory. I heard that filemaps go in the same region as DLLs.
What is the maximum VM space I can get my hands on? Code samples
would be useful. I'm discouraged to see that mallocs start
at 0x20000000. If there is a kernel VM ring, that would basically
nukes an ideal singlemap configuration, even for NT.
2. How can I check for available data on a file descriptor?
I see no "select" or FIONREAD ioctls. The only thing
close I see is a win32 "console" peek. I assume this
means only keyboard events. Ideas?
3. Is it realistic to have a single win32 binary. Or are
there too many tradeoffs? For example: 8+3 filenames or long filenames.
NT private maps vs global '95 maps.
In article <····················@sayre.sysc.pdx.edu>
······@sysc.pdx.edu "Marcus Daniels" writes:
> GCC is hosted on win32; no need for Unix.
NT? I can't currently use NT, either. I use Win32s. If GCC is hosted
by Win32s, then that may be ok, but I have some doubts, mainly coz
the Win16 platform does not support command line tools very well
(or all?).
Even if I were to switch to NT now, it would be too late for me to
port CLISP to Win32.
> GNU cpp binaries are everywhere, and have been for several years.
> oak.oakland.edu, for example.
True, and I had GNU C when I asked Bruno Haible about porting CLISP.
However, I had no idea that it was possible to use it to produce
Win32 binaries. I had (and still have) no interest in creating a
DOS binary of CLISP, as that exists already.
> CS> I didn't any workable alternatives, and I was certainly motivated to look
> CS> for them. I also had the time, last year.
>
> It never occured to you to try preprocessing with a EMX or DJGPP GCC?
> Interesting.
As I've explained already, I tried that. It _failed_. The DOSX binary
of the preprocessor failed, and I've no idea why. ISTR there may have
been a link problem. The 16bit DOS binary also failed, coz it ran out
of memory.
> Oh and BTW, the MSWindows work that was done on CLISP was released; it is
> in the source tree.
Really? When I asked recently Bruno how the Win32 port was doing, he
didn't mention this.
> Cyber Surfer, you could help me get a win32 binary
> release out in a timely fashion! If you could provide me with the
> following information:
Only if I had the time, which I no longer have. I'm too busy
doing Win16 development - in C. This frustrates me, as you might
imagine!
> 1. How do file maps work on win32? Like many people I cannot afford
> to buy technical manuals for five minutes of use. I understand
> that WinNT/Windows95 has a tiered division of virtual
> memory. I heard that filemaps go in the same region as DLLs.
File mapping? That's an NT/Win95 feature. As I understand it,
NT maps code into memory. I'm not too familier with it, as all
my Win32 development is done with Win32s, which is a subsystem
for Win16 that allows it to run Win32 software usign a subset
of the full Win32 API. File mapping is not supported.
> What is the maximum VM space I can get my hands on? Code samples
> would be useful. I'm discouraged to see that mallocs start
> at 0x20000000. If there is a kernel VM ring, that would basically
> nukes an ideal singlemap configuration, even for NT.
As I've said, I don't use NT. I have no docs for that kind of info.
> 2. How can I check for available data on a file descriptor?
> I see no "select" or FIONREAD ioctls. The only thing
> close I see is a win32 "console" peek. I assume this
> means only keyboard events. Ideas?
See above. The console API is not supported under Win32s, as
Win16 works very differently. MS appear to have assumed that
no command line apps will be needed for 16bit Windows.
> 3. Is it realistic to have a single win32 binary. Or are
> there too many tradeoffs? For example: 8+3 filenames or long filenames.
> NT private maps vs global '95 maps.
There are a lot of tradeoffs. You lose most of the really tasty
Win32 featues if you use Win32s. However, this shouldn't be a
problem for CLISP, unless it needs file mapping, threads, pipes,
etc. One solution might be to produce Win32 and Win32s versions,
but that could create more problems. It's certainly more work,
which could be why some developers don't bother doing it that way.
I've no idea if it would be useful, necessary, or even worth the
trouble.
Of course, if CLISP can use features such as pipes, then
supporting them would certainly be worth the effort! It could
be done in such a way that if CLISP were run under Win32s,
where pipes are unavailable, then those features would simply
fail. Win32s would "fail" to create the pipe, and the CLISP
function to create it could indicate this failure. Such a
Win32 CLISP would run under Win32s, but not every feature
would be supported.
On the other hand, if a Win32 CLISP were to use the console
functions as the main interface with the user, then it would
not work with Win32s at all. I've no idea if this would be a
reasonable tradeoff, but if Win95 supports console apps, then
it might be reasonable to think of Win95 as the minimum Win32
platform for CLISP.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
On Sat, 19 Aug 95 09:41:51 GMT, Cyber Surfer <············@wildcard.demon.co.uk> said:
>> Really how much are you prepared to pay for such a product?
> Personally? No more than for a C++ compiler system for Windows.
Is it not worth more to you? I would personally find a good CL
development environment much more useful than a C++ environment, and
would be willing to pay a difference commensurate with that increase
in value. Of course, I also understand that I can't pay C++-like
commodity prices for what is, sadly, a niche product.
Regards,
-- Robert
In article <··············@hrothgar.mindspring.com>
········@mindspring.com "Robert Sanders" writes:
> Is it not worth more to you? I would personally find a good CL
> development environment much more useful than a C++ environment, and
> would be willing to pay a difference commensurate with that increase
> in value. Of course, I also understand that I can't pay C++-like
> commodity prices for what is, sadly, a niche product.
I agree that a good CL would be more useful than a C++ system.
However, I can't use that argument to pay for a CL system. I need
the money, and I don't have it. If I don't have it, then I may
have to pursuade someone else to pay for it, and that's not as
easy as it would be for a C++ system. That's my point.
If it were possible for my to use CL, then I'd be using it. If it
becomes possible to use it in the future, then I will. However,
it's incredibly easy to get hold of a C++ system, and even easier
to justify it. I'm in the position where I have to justify using
Lisp, so a $1000 price tag doesn't help.
I'm sure there are many other programmers with the same difficulty.
The problem could be summed up like this: never mind what it may
be worth _to me_, what counts is what it's worth to an employer.
So far, I've found very few employers who are interested in Lisp,
and most of them are on the other side of the Atlantic from me.
I'm not knocking Lisp (CL, Scheme, whatever), as I love it, but
if I want someone to pay me to use it, I may be disappointed.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
In article <··············@hrothgar.mindspring.com> Robert Sanders <········@mindspring.com> writes:
From: Robert Sanders <········@mindspring.com>
Newsgroups: comp.lang.lisp
Date: 20 Aug 1995 01:47:03 -0400
Organization: MindSpring Enterprises, Inc.
Lines: 13
Sender: ········@hrothgar.mindspring.com
X-Newsreader: (ding) Gnus v0.99.11
On Sat, 19 Aug 95 09:41:51 GMT, Cyber Surfer <············@wildcard.demon.co.uk> said:
>> Really how much are you prepared to pay for such a product?
> Personally? No more than for a C++ compiler system for Windows.
Is it not worth more to you? I would personally find a good CL
development environment much more useful than a C++ environment, and
would be willing to pay a difference commensurate with that increase
in value. Of course, I also understand that I can't pay C++-like
commodity prices for what is, sadly, a niche product.
This is actually a problem for the (lisp) vendors. It affect me, but
that is just unfortunate. The question is for the vendors: do you want
to increase you market share and win (with all the ambiguities that
the verb "win" has) in the long run?
Once again, wouldn't we all be using Macs, if Apple had not kept their
prices up for so long wrt the "average" PC running MSDOS?
Of course, "tombs are filled with afterthoughts". See you in four
days, as Microsoft would say. :)
Happy Lisping
--
Marco G. Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@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
>>>>> "CS" == Cyber Surfer <············@wildcard.demon.co.uk> writes:
In article <············@wildcard.demon.co.uk> Cyber Surfer <············@wildcard.demon.co.uk> writes:
me> It never occured to you to try preprocessing with a EMX or DJGPP
me> GCC? Interesting.
CS> As I've explained already, I tried that. It _failed_. The DOSX
CS> binary of the preprocessor failed, and I've no idea why.
What does DOSX have to do with using the EMX or GO32 extenders?
The binary EMX/CLISP DOS distribution is an existence proof.
me> Oh and BTW, the MSWindows work that was done on CLISP was released;
me> it is in the source tree.
CS> Really? When I asked recently Bruno how the Win32 port was doing,
CS> he didn't mention this.
You have been intimating that work is being withheld or was
promised and was not forthcoming; neither is true.
Where are the letters `3' or `2' in my previous sentence? How did they
find their way into yours? It is difficult to see why you would be so
interested in "the Win32" port when you say things like:
CS> NT? I can't currently use NT, either. I use Win32s. If GCC is hosted
CS> by Win32s, then that may be ok, but I have some doubts, mainly coz
CS> the Win16 platform does not support command line tools very well
CS> (or all?).
I guess what we in the Lisp "community" really need in order to
leverage your programming skills is win32s support, not 3.1 support,
and not NT or Win95 support.
In article <····················@sayre.sysc.pdx.edu>
······@sysc.pdx.edu "Marcus Daniels" writes:
> CS> As I've explained already, I tried that. It _failed_. The DOSX
> CS> binary of the preprocessor failed, and I've no idea why.
>
> What does DOSX have to do with using the EMX or GO32 extenders?
Well, I wasn't using GNU C to compile and link the preprocessor,
I was using Symantec C. DOSX is the Symantec DOS extender.
> CS> Really? When I asked recently Bruno how the Win32 port was doing,
> CS> he didn't mention this.
>
> You have been intimating that work is being withheld or was
> promised and was not forthcoming; neither is true.
Wrong. Bruno has explained to me that he's no longer working on
CLISP. I've no idea what the current status of the Win32 port is.
> Where are the letters `3' or `2' in my previous sentence? How did they
> find their way into yours? It is difficult to see why you would be so
> interested in "the Win32" port when you say things like:
>
> CS> NT? I can't currently use NT, either. I use Win32s. If GCC is hosted
> CS> by Win32s, then that may be ok, but I have some doubts, mainly coz
> CS> the Win16 platform does not support command line tools very well
> CS> (or all?).
The Win32s API is a subset of the full Win32 API used by NT. The
Win95 API used to be called Win32c, for similar reasons. I think
this is getting a little off-topic for comp.lang.lisp, BTW. I'll
be happy to continue this by email, of course.
> I guess what we in the Lisp "community" really need in order to
> leverage your programming skills is win32s support, not 3.1 support,
> and not NT or Win95 support.
I'm not sure I understand that. Is it a question? What does the
phrase, "leverage your programming skills", mean? Win32s is
subsystem that runs on top of Win16, providing a subset of the
Win32 API. If CLISP can run under DOS, using a DOS extender,
then I guess it can run under Windows using Win32s.
When I had offered to port CLISP to Windows, a year ago, it was
after assuming that this was possible. I offered my time and Windows
programming skills to Bruno Haible because nobody else was using
them. I no longer have that free time, and I'm still using the
same bug-ridden tools - which are for a commercial C/C++ compiler,
by the way - which prevented me from compiling the CLISP source
code. When Bruno emailed me to say that he was porting CLISP
himself, there little point in continuing with my own port.
Anyway, I'm not demanding a Win32 port of CLISP. I'm not demanding
_anything_. Asking Symantec for a compiler without a bug in the
preprocessor that left a space when you used ## didn't produce
much of a result, altho I did get a new version. Perhaps they
didn't get around to fixing such a "minor" bug? I dunno.
As someone who is unemployed, I have bigger problems to worry
about, and some of them demanded my attention. Ultimately, _that_
is the real reason why I didn't port CLISP. I've never suggested
that it was coz of any lack of support from Bruno, Symantec, or
anyone else. I'm more than satisfied with the help I received.
If you have any more questions, please ask by email, as I'm not
sure that anyone else is interested in this matter. If they are,
then perhaps they should also email me.
Finally, please don't confuse anything I've posted with anything
posted by Blake McBride (or anyone else). We have very different
views. I joined this thread to make a different point.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
Tim Bradshaw <···@ed.ac.uk> writes:
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.
Exactly. Originally, as designed and implemented by two mathematics students,
CLISP should be the basis for a computer algebra system. A better bignum
calculator for the mathematician's every day use.
It is not surprising that academics don't pay much attention to possible
commercial success, unless their funds depend on it.
Bruno
Bruno Haible email: <······@ilog.fr>
Software Engineer phone: +33-1-49083585
Blake McBride <·····@edge.net> writes:
I'll port any of them so long as I don't have to fight the thing.
Any port of a big piece of software is a fight. Since the ports of CLISP
and GCL are usually doable within a couple of days or (at most) weeks, I
guess you were actually fighting your environment, notably your C compilers,
not "the thing".
Bruno Haible email: <······@ilog.fr>
Software Engineer phone: +33-1-49083585
Blake McBride <·····@edge.net> writes:
GCC doesn't really support Windows 3.1, NT 3.x or '95. It's just
good for command line utilities.
That's not true. Even the statement "GCC doesn't support Windows 3.1" is not
true. There is a package named `rsxwdk' (Windows development kit with RSX)
available via ftp which, together with emx+gcc, lets you build Windows 3.1
32-bit binaries. The package is certainly not beta software, but with some
fighting (yes!) it is possible to build CLISP binaries which run under
MS-Windows 3.1 (not DOS box).
Bruno Haible email: <······@ilog.fr>
Software Engineer phone: +33-1-49083585
Blake McBride <·····@edge.net> writes:
I don't know or really care which compiler you
use but I can assure you they use macros with missing arguments in
many, many places. This is not ANSI C. I can not speak about what
compilers do or do not support this *feature*. If the thing works
on your machine than obviously your compiler definitly supports the
feature, period.
Yes, the CLISP source use this kind of C feature. For those C compilers
which don't support it, the Makefile gets a little bit more complicated
by the use of "sed -e 's/,)/,__EMPTY_MACRO_ARGUMENT__)/g'" commands.
It is not worth talking about.
Oh, I don't doubt that they will insert an ifdef or two. That's not the
problem. The problem has to do with fundemental design issues which
were chosen not out of necessity, but out of disregard for anything
but academic environments (although I understand that they certainly
have this right).
You are alluding to three design decisions in CLISP:
- To write half of CLISP in C, and rely on existing C compilers (ANSI C
or C++ compilers are not required). Some other Lisp's ability to be widely
used is suffering from the fact they are written in 8086 or 68k assembly
language.
- To write the entire bytecode interpreter as a single C function.
This is your "functions so large" complaint. It did hurt me with
Turbo C 2.0 three years ago because this compiler could not compile
functions with more than 32 KB object code. Please tell us, did you
encounter a similar limitation with Microsoft C?
- To implement the arithmetic and number system as a single compilation unit,
about 950 KB C code. This was done because a lot of subroutines are
realized as macros (similar to inline functions), for efficiency.
When this is compiled using WATCOM C (9.5 or 10.0) the C compiler reports
an "internal table overflow" because it cannot handle more than 108 KB
object code per compilation, and suggests splitting the module.
And, no, the CLISP maintainers will not revise these design decisions.
Peter Burwood <···@arcangel.demon.co.uk> writes:
I don't like speculating, but it is starting to sound like you wanted
Bruno to split the source into smaller modules and functions and he
refused. Maybe I'm wrong, and I suspect there is more to it, but if not,
then I repeat - get a decent compiler.
That's exactly what Blake McBride wanted me to do, and I refused and
suggested complaining at WATCOM.
Similarly, when your text editor says it cannot handle text files larger
than 64 KB, will you split your files or will you choose another text
editor? I would choose another text editor.
Bruno
Bruno Haible email: <······@ilog.fr>
Software Engineer phone: +33-1-49083585
From: Johann Friedrich Heinrichmeyer
Subject: Re: Why is Lisp not more widely used?
Date:
Message-ID: <JFH.95Aug23091834@ES-sun2>
One thing which have elisp clisp and gcl sources in common is the heavy
use of large macros and (maybe due to this?) extremely large
binaries. Is the win in efficiency really noticeable?
--
Fritz Heinrichmeyer FernUniversitaet Hagen
FAX: +49 2371/566236 LG Elektronische Schaltungen
EMAIL: ···················@fernuni-hagen.de Frauenstuhlweg 31
PHONE: +49 02371/566-243 58644 Iserlohn (Germany)
WWW: http://ES-sun2.fernuni-hagen.de
>>>>> "CS" == Cyber Surfer <············@wildcard.demon.co.uk> writes:
In article <············@wildcard.demon.co.uk> Cyber Surfer <············@wildcard.demon.co.uk> writes:
CS> Really? When I asked recently Bruno how the Win32 port was doing,
CS> he didn't mention this.
me> You have been intimating that work is being withheld or was
me> promised and was not forthcoming; neither is true.
CS> Wrong. Bruno has explained to me that he's no longer working on
CS> CLISP. I've no idea what the current status of the Win32 port is.
Try: http://sayre.sysc.pdx.edu:8001/clisp/win32.zip
The partial Windows 3.1 work that was done is in the distribution,
but you obviously didn't bother to check. Or for that matter
even pay attention to the CLISP mailing list.
me> I guess what we in the Lisp "community" really need in order to
me> leverage your programming skills is win32s support, not 3.1
me> support, and not NT or Win95 support.
CS> I'm not sure I understand that. Is it a question? What does the
CS> phrase, "leverage your programming skills", mean? Win32s is
CS> subsystem that runs on top of Win16, providing a subset of the
CS> Win32 API. If CLISP can run under DOS, using a DOS extender, then
CS> I guess it can run under Windows using Win32s.
Correct! You can use the rsx GCC system for Windows 3.1, or write NT/Win95
applications with GCC. So, what is the problem?
CS> As someone who is unemployed, I have bigger problems to worry
CS> about, and some of them demanded my attention. Ultimately, _that_
CS> is the real reason why I didn't port CLISP. I've never suggested
CS> that it was coz of any lack of support from Bruno, Symantec, or
CS> anyone else. I'm more than satisfied with the help I received.
I don't know where you got this notion that this discussion is about
you porting CLISP to win32. Who cares?? This discussion about
"Why is not Lisp widely used". I submit the reason has absolutely
nothing to do with the efforts, or the attitude of the people involved
in free software. CLISP is one example.
In article <····················@sayre.sysc.pdx.edu>
······@sysc.pdx.edu "Marcus Daniels" writes:
> CS> Wrong. Bruno has explained to me that he's no longer working on
> CS> CLISP. I've no idea what the current status of the Win32 port is.
>
> Try: http://sayre.sysc.pdx.edu:8001/clisp/win32.zip
Thanks, that's news to me.
> The partial Windows 3.1 work that was done is in the distribution,
> but you obviously didn't bother to check. Or for that matter
> even pay attention to the CLISP mailing list.
I prefer not to read CLISP mailing list, as I have more than
enough to read already. Instead, tend to look for things on
FTP or WWW sites.
Which distributions are you refering to, BTW? I looked on the
ma2s2.mathematik.uni-karlsruhe.de FTP site.
> Correct! You can use the rsx GCC system for Windows 3.1, or write NT/Win95
> applications with GCC. So, what is the problem?
As I've explain severla times before, I don't have the time to
port CLISP myself. In case you've missed it _in this article_,
I'll repeat it: I don't have the time to port CLISP myself.
Please note (in case this is something else that you've missed)
my name is not Blake McBride. I have no problem with the freeware
Lisps available. If I had a problem, I'd have mentioned it. All
I've said is that I don't have a Lisp that I can use to write
Windows apps in.
Of course, I don't _need_ to write Windows apps in Lisp, but if
I did, I could probably acquire a commercial Common Lisp system.
It's just a matter of convincing someone that such a system is
needed to develop an app, instead of C++.
> CS> As someone who is unemployed, I have bigger problems to worry
> CS> about, and some of them demanded my attention. Ultimately, _that_
> CS> is the real reason why I didn't port CLISP. I've never suggested
> CS> that it was coz of any lack of support from Bruno, Symantec, or
> CS> anyone else. I'm more than satisfied with the help I received.
>
> I don't know where you got this notion that this discussion is about
> you porting CLISP to win32. Who cares?? This discussion about
> "Why is not Lisp widely used". I submit the reason has absolutely
> nothing to do with the efforts, or the attitude of the people involved
> in free software. CLISP is one example.
You asked me about the difficulties I've had, and I answered.
I'm more interested in discussing why Lisp is not more widely
used, as I'd prefer to be developing software in Lisp than in
C/C++. I recall that it was Blake McBride who mentioned CLISP
before I did. I was simply pointing out that I've not yet found
a CLISP for Win32, which may help explain why Lisp isn't used
by many Windows developers.
I think of it as a matter of education. It's not an issue of
whether CLISP, for example, is a commercial Lisp or not, but
the fact that it is freely available may make it easier for
anyone curious about Lisp to try at. There's almost no risk
at all, and it's far from a "toy" Lisp. However, the old myths
about Lisp (too slow, too big, unrealistic etc) are perpetuated
by the smaller systems, like XLISP, which are interpreted.
I can remember how only 5 years ago, it was possible to get an
odd look from a MIDI user if you mentioned MIDI and Windows in
the same sentence. These days, I expect to get those same looks
if I use Lisp and Windows in the same sentence!
Perhaps they think Lisp is dead? I wish I could show that this
wasn't true. A Lisp for DOS won't help, coz DOS = Dead Operating
System. A Lisp for Win32 would be at the front of the race, where
the top runners are.
What I'm talking about is how Lisp is perceived by developers.
That's determined by marketing, and the marketing of Lisp for
the Windows market is not as strong as it the marketing for C++,
which may explain why C++ is used so much more widely, at least
for Windows.
Do you see now why I mentioned CLISP (and the lack of a Win32
version) 9 days ago? It could be too late to help me, but then,
I'm already convinced. Sadly, this doesn't help me use Lisp,
instead of C++, to develop software.
We could probably be just as easily talking about GNU CL, of
course, or any other freely available Common Lisp system, as
long as such a system would be available to developers who
might want to try Lisp, and see for themselves how good it is.
Without a real system to play with, it's a lot easier to believe
the myths.
This also applies to Smalltalk, Prolog, and any other language
for which implementations are not sold in vast quantities or
advertised as heavily as, let's say, VC++. I said it was a
marketing problem over a week ago. At the very least, it's the
reason why I've yet to meet a Windows developer using Lisp for
commercial software.
The software market for Windows is a big one...
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
In <············@wildcard.demon.co.uk> Cyber Surfer
<············@wildcard.demon.co.uk> writes:
>What exactly what make a Lisp system qualify as "VC++/Delphi-like",
>in your opinion? Would VBX support and a forms designer be necessary,
>or would a framework for the Windows API be good enough? VC++ and
>Delphi offer _both_ of these.
I would like a visual-lisp package that has all the ease of use of the
aformentioned packages (to insulate me from the GUI programming issues)
as well as the power of common lisp, or at least Scheme, for any really
tough algorithmic problems that come up. My requirements are those of
an occasional programmer who doesn't have time to learn about the
Windows API (or interest, for that matter.)
It would also be nice if the compiler afforded some degree of
cross-platform portability, so that algorithms (like state machines,
control loops, etc.) could be rapidly prototyped on the PC and then
ported to a target system, perhaps using intermediate C source output
code for portability. Besides real-time control (my field) I can
imagine other fields where these capabilities could be useful, e.g.,
neural networks, client/server, systems modelling, etc.
--
Marty
In article <··········@ixnews7.ix.netcom.com> ······@ix.netcom.com (Martin Brundage) writes:
>In <············@wildcard.demon.co.uk> Cyber Surfer
>
>Sorry to jump into the middle of this thread, but I was curious about
>this issue. I still remember my disappointment when Borland introduced
>Delphi based on (of all languages) Pascal!
>
On the other hand, they could have followed the others -- MSVB, Power
Builder, etc. -- and used (of all languages) basic. I was pleased
that they didn't. I guess it's a matter of viewpoint. :-)
Pete.
>>>>> "Johann" == Johann Friedrich Heinrichmeyer <···@ES-sun2> writes:
Johann> One thing which have elisp clisp and gcl sources in common
Johann> is the heavy use of large macros and (maybe due to this?)
Johann> extremely large binaries. Is the win in efficiency really
Johann> noticeable?
On a sparc, lisp.run for clisp is only 1MB, and the lispinit.mem is
about 800K. While running, the size is about 1 MB. The X11R6 server
is 2 MB or so. XEmacs takes 4 MB or more while running. I don't find
this to be extremely large.
Ray
--
----> Raymond Toy
----> Ericsson Inc.
>>>>> "Johann" == Johann Friedrich Heinrichmeyer <···@ES-sun2> writes:
In article <·················@ES-sun2> ···@ES-sun2 (Johann Friedrich Heinrichmeyer) writes:
Johann> One thing which have elisp clisp and gcl sources in common is
Johann> the heavy use of large macros and (maybe due to this?)
Johann> extremely large binaries. Is the win in efficiency really
Johann> noticeable?
750K is a large executable for a Common Lisp implementation?
In article <····················@sayre.sysc.pdx.edu>
······@sysc.pdx.edu "Marcus Daniels" writes:
> It might sound like I intended to denigrate XLISP in some way. I did
> not mean to flame XLISP. My experience is with xlispstat, so I've
> always thought of XLISP as being more application-oriented. What I
> was trying to emphasize was that since XLISP is small and its claims
> are modest, it seems silly to think anyone would be misled into
> thinking it was possible to replace a full blown native code compiler
> -- and thereby form a prejudice about Lisp (or Common Lisp). It is
> just goofy. At the same time, just because something isn't the
> end-all of tools, doesn't mean it is a toy. XLISP and xlispstat (!)
> are not toys.
I agree that XLISP is not a toy, but I know how it'll appear to
a typical C/C++ developer. Remember Small C? My first C compiler
was based on Small C, and was far from being a toy. At the time
(the early 80s), most micro users were more likely to see Small C
than any other C compiler.
5 years ago, XLISP was in a similar position, as an example of a
Lisp system. I'm not sure this has changed much, as XLISP is still
small enough to be uploaded to a BBS very easily. With the high
speed modems available today, the size of larger Lisp, like CLISP,
shouldn't be such a problem, but it _is_ larger, and I know that
can deter people - esp in the UK, where telecoms charges are still
high - from uploading a file.
If anyone knows of a BBS in the UK, or anywhere else, with a copy
of CLISP on it, please let me know. I'm curious. When I was looking
for Lisp systems on any BBS I used, I only rarely found XLISP, and
that was the _only_ Lisp I could find. Perhaps a few years later,
it's different?
Let's hope that as more people flood onto the Internet, they find
a wider variety of Lisps, and try a few of them.
> However, CMU Lisp is not touted so modestly, so directing
> criticism its way would be more appropriate. In my opinion,
> CMU Lisp much more accurately reflects the strengths and weaknesses of
> Common Lisp. If someone says "Common Lisp is slow" or "Common Lisp is huge"
> (when they are actually thinking of CMU Common Lisp), then we *really* have
> something to argue about.
I can't really comment on CMU CL, as I've not seen it, and I
don't yet even have a machine that can run it. This will change,
of course. Even now, CMU CL is being ported to Linux, which I
may be using by this time next year. I'll probably not be using
Linux most of the time, but at least it'll give me - and many
others like me - a chance to try a high quality Common Lisp
system with a native code compiler, for very little money (no
more than the cost of a CD-ROM, and some disk space, possibly
much less than that).
Meanwhile, I can still safely argue that a great many programmers
will find it hard to use such a Lisp, while XLISP is available in
a form that will run on their machines _today_. So is CLISP, if
you count the DOS version. However, DOS is not the "great" platform
it once was, for developers.
If you'd rather only look at Unix, then none of this may be
relevant. CMU CL is already available for various Unix systems,
as I'm sure you're aware. I'm just pointing out that I'm more
interested in the non-Unix platforms, such as NT and Windows 95.
I'm also interested in Linux, but I'd love to be able to use
a Lisp on the same platform that I'll be developing for. It
might help me convince a few people that it can be done! Right
now, I get strange looks every time I mention Lisp and Windows
development in the same sentence, which means that I'm more
likely to be coding in C than in Lisp. That's a pity.
--
<URL:http://www.demon.co.uk/community/index.html>
<URL:http://www.enrapture.com/cybes/namaste.html>
"You can never browse enough."
From: Brandon Van every
Subject: Re: Why is Lisp not more widely used?
Date:
Message-ID: <40s01k$eh0@rbdc.rbdc.com>
·······@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,
········@rbdc.rbdc.com | C++ UNIX X11 Motif | as white as
http://rbdc.rbdc.com/~vanevery | HTML CGI Perl TCL/Tk | daytime.
>>>>> On 16 Aug 1995 01:34:44 -0400, ········@rbdc.rbdc.com (Brandon Van every) said:
Brandon> ·······@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 <·············@PC-Labor.Uni-Bremen.DE>
D - 28334 Bremen <http://www.pc-labor.uni-bremen.de/Duerer/Holger.html>