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 <40j8lv$...@geraldo.cc.utexas.edu> jaso...@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...
In article <808300363...@wildcard.demon.co.uk> Cyber Surfer <cyber_sur...@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: s...@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: :-) ===========================================================================
| 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!
: | 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 lever...@rand.org
: 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.
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).
jaso...@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 bl...@edge.net USA
Erik Naggum (e...@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: marc...@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
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?
In article <40l7fp$...@cantaloupe.srv.cs.cmu.edu> s...@CS.CMU.EDU "Scott Fahlman" writes:
> I would argue that marketing, while important, has been a much less > important factor in Lisp's non-success in the mainstream than the lack > of a good, cheap implementation on PC's and poor delivery
I was refering to the marketing of VB, of course. I can't comment on the marketing of, say, Common Lisp systems, as I've seen so little of it. On the other hand, I can't avoid the marketing of VB, as it's in my face every day.
> characteristics. Both of those are solvable problems in Common Lisp, > and have been partially solved, but it was too little, too late. This > is the direct results of some bad strategic decisions by the vendors > and (less important) some bad decisions in the language design that > make it hard to deliver stripped-down systems. I'll take some of the > credit for the latter set of mistakes.
Well, I've no idea who is to "blame" for these mistakes, but I agree that the Lisp implementations I've seen make it hard or impossible to deliver stripped-down systems.
> Well, having been through this once, I think that's kind of naive. A > language that is used by few people will not be supported very well, > either by vendors or by third-party developers of libraries,
I agree, but I've had no problem using Lisp so far. Perhaps I just find it a natural language to work in. Anyway, the only problem I've had so far has been with delivering the code in a form that other people can use. _I_ may be happy using code within a development system, but most people wouldn't be.
Also, I've never relied on vendor support before, so a lack of support for a language system doesn't worry me too much. It could depend on what I'll use it for, of course!
Still, I'm currently using a Scheme with very little support, and doing useful work with it. My Scheme to C compiler may be even better "supported", as I have the source code and access to the developer of it - myself.
I don't expect anyone else to find this a workable solution, and I've yet to use it to deliver code for use by other people, which is a point I made in an earlier post. I do it this way coz _I can_, not coz it's necessarily the best way of doing something. However, it may provide me with the tools that best serve my needs.
> textbooks, tools, and so on. And there's a lot of positive feedback: > if a language is widely used, there are lots of programmers around who > know how to use it, and compaines will tend to choose it for new > projects -- no matter how bad it might be compared to some language > that nobody knows. Once you're a niche language, the advatanges for a > given task have to be really compelling, and eve then some projects > will go with the mainstream.
That's why most of my coding is done in C at present. When I'm working in my own time, I use Scheme. So far, nobody has convinced me that they know how to spent my time better than myself, and very few people have even bothered to try to convince me. ;-)
I find I can avoid a lot of "advocacy" problems if I simply don't tell people which language I used to write a particular app. If they don't ask, why trouble them? If someone were to pay for the development of some code, then I'd agree that they have an interest in the choice of the language (and the language implementation) used to develop that code.
> On the other hand, if the mainstream clogs up in a place where > programmers become sufficiently unhappy and unproductive, there can > occasionally be a mass breakout to something better. But that's a lot > more likely if the better language that people might move to is widely > avilable in the educational market (including, now, highschools and > people's basements), so that people know what they are missing and > aren;t afraid of it. Common Lisp isn't there, and the Schemes that > are there tend to make Lisp look like a neat idea, but not very > practical for big projects. That could change. Or maybe something > like Dylan will keep the good ideas of Lisp in front of people, > somewhat repackaged.
That's why I'm pleased to see that the Open University (an adult education system here in the UK) have a Common Lisp course. See <URL:http://kmi.open.ac.uk/courses/dmzx863.html> for more details. They also mirror CMU's WWW version of CLtL2.
My Scheme to C compiler is designed to be more practical than the systems I've used (MIT Scheme and SCM). I like MIT Scheme a lot, but I don't think it can deliver stand-alone code, while SCM is an interpreter, and a lot slower than the code from my compiler (by a factor of 8+).
Now, this is the first real Lisp compiler I've written (an earlier effort produced an interpreted code), so the code doesn't even begin to look "optimal", and yet it's fast enough for me not to worry about how much faster an app might be if it were written in C.
As a test, I rewrote one app in C and compared the performance. It was only 5 times faster than the Scheme version run by SCM, and yet it was so flackey that it managed to hang my machine at least once. It could be argued that such a program will never complete, and so runs at 0% efficiency! Anyway, it would need a dedicated machine to run it, as any other programs running on that machine would also never terminate.
I consider the performance of SCM compared to the code from a C compiler to be a "big win". The code from my Scheme to C compiler should be an even bigger win. :-) Of course, my definition of "practical" is any code that can be used in a real app, but the what counts as a real app may be debated. Perhaps it's any code which is useful, and is used frequently? Well, I have plenty of code like that! I use it daily, and I find it _very_ useful. -- <URL:http://www.demon.co.uk/community/index.html> <URL:http://www.enrapture.com/cybes/namaste.html> "You can never browse enough."
>>>>> "Brian" == Brian Leverich <lever...@atlantis.rand.org> writes: In article <40nt4u$...@rand.org> lever...@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 <MARCOXA.95Aug14160...@mosaic.nyu.edu> marc...@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."
| 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!
In article <808488230...@wildcard.demon.co.uk> Cyber Surfer <cyber_sur...@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.
* 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.
> : 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.
In article <40ng4k$...@excalibur.edge.net> bl...@edge.net "Blake McBride" writes: > The people involved with lisp appear to be only concerned with > academic use of lisp. They seem to snub their noses at commercial > users. Case in point - the maintainers of GCL and CLISP, two > fundamentally portable systems, insist on making their systems > incompatible with mainstream hardware for absolutely NO REASON.
Well, all I can say is that I'm still waiting for a Windows version of CLISP. I've been told that such a version exists, but it has not been made available. I'm no longer sure it's worth waiting for, as I may either switch to a commercial Common Lisp, or use MIT Scheme instead. If I'm lucky enough to eventually be able to use Linux, then I may use MIT Scheme anyway.
In article <activisDDB6I2....@netcom.com> acti...@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."
In article <808484603...@wildcard.demon.co.uk> Cyber Surfer <cyber_sur...@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.
>>>>> "david" == David Boles <dbo...@news.eng.convex.com> writes: In article <40qld2$...@zeppelin.convex.com> dbo...@news.eng.convex.com (David Boles) writes:
w.r.t. CLISP:
david> Then don't inline the helper functions. Yes there'll be a loss david> of efficiency, but it *would* run. With some decent software david> engineering, it would almost certainly be possible to make the david> system run faster than it does today, and stick to ANSI C. david> I think Blake's problem here is that CLISP is not written in C, david> it's written in GCC. It's a problem that I have with a lot of david> software out there. GCC is a reasonably good compiler (but only david> reasonably), and using it is fine, but people shouldn't claim david> they're writing in C when they use GCC extensions.
First of all, a proprietary compiler would have generate 30% better code before *I* would even *think* about investing significant labor into a non-GCC port. I might try the native compiler once, and tolerate a few limitations, but once I suspected weakness -- I'd just ftp GCC.
If someone else is motivated to bring CLISP up on their development environment / OS that is great. There have been some *very* generous contributors to CLISP.
Second of all, many Unix compilers *can* handle these macros. The few places GCC extensions are used in CLISP, it is only done if the feature is available.
Thirdly, and most importantly, there are already programs that process CLISP source code before it is compiled. It is a simple matter to add another, namely GNU cpp. GNU cpp is already in the distribution. Stop fixating on ANSI C. It is ".d"! Get over it!
What has become clear to me is that these individuals are not content to investigate these simple alternatives for themselves. They do not understand the nature of free software (or care), and would much rather whine and spread misinformation.
Ultimately, it isn't about "loss of efficiency", it is about raping the code without considering perfectly workable alternatives.
>> I'm even more puzzled by your annoyance over the CLISP sources' >> requirement that your C compiler be able to compile large >> translation units or large functions. The C standard doesn't say >> that a conforming compiler reserves the right to refuse service to >> obese source code. I have to agree that compilers that place >> arbitrary restrictions on the size of functions or files are brain- >> dead.
david> Hmmm, perhaps you should actually *read* the C standard, david> specifically section 5.2.4.1 "Translation limits":
Let me be very concrete:
These huge blocks of code Blake McBride vaguely talks about have not even be named!
