For opposing viewpoints see: WhyWeLoveLisp
----

We hate Lisp because in spite of reading the first half of several books, and, in spite of writing Lisp code in college which might have done unification (whatever that is) but didn't even do file I/O, we now find that we are nothing but outsiders who are scorned for not having the insight of Moon (whoever he was) whenever we try to bring one iota of our hard won and elsewhere valuable experience to Lisp programming.

For example, if a C programmer asked HowToSumFromOneToTenInLispOrScheme, he might start thinking along the lines of...
	for (int i = 1; i <= 10; i++) ...
which may not be original but seems to be a string of tokens that all pretty directly address the problem at hand. Rather than write something slightly recognizable like...
	(for (i (span 1 10)) ... )
the Lisp guys start talking about the elegance of lambda and cons and PeanoArithmetic for which even a "first order" text is judged "difficult reading for a newcomer to the area". Who needs the putdowns? We hate Lisp.

(To be fair, the original web page that contained the "difficult reading" quote is discussing a text book called "Metamathematics of First-order Arithmetic". The "first-order" refers to the type of mathematics covered in the book, not the audience level that the text book is intended for.)  ('''This statement reminds me of when I was taking an "Advanced Calculus" class as a Junior in college, and a Senior was complaining that he was about to graduate as a math major, yet he was taking classes with textbooks that had titles like "Analysis with an Introduction to Proof".  (My taking the class as a Junior only reflects the fact that the class was offerred every other year, rather than the fact that I was some sort of "advanced" student.)  The funny thing is, I was taking "Introduction to this-or-that" classes well into my Graduate Studies!  In any case, I would confirm that "first-order arithmetic" describes the arithmetic, not the easiness of the material; it's similar to "first-order differential equations" describing differential equations that have only first derivatives.'''  -- Alpheus)

''That's not what I would do. I'm not too experienced with Lisp, but in Common Lisp, I would just say''
	(loop for i from 1 to 10
	  do (format t "~A~%" i))	;; or whatever else is in the body
''and be done with it.''

Even shorter: 
	(dotimes (i 10)
	 (format t "~A~%" i))
and be drinking my beer while you are typing "and be done with it"
''Except that the correct answer delivers the numbers from 1 to 10, not 0 to 9 :-), hence:''
	(dotimes (i 10)
	 (format t "~A~%" (1+ i)))

''Don't forget that the task is to sum the numbers, rather than print them to a stream:

	(loop for i from 1 to 10 sum) 

''And I'd do it in Clojure as:''
	(apply + (range 1 11))
''and sip my tea while you are typing before you get to drink your beer''

''In Smalltalk:''
	(1 to: 10) inject: 0 into: [ :acc :each | acc + each ] 

''Although you could just switch to RubyLanguage, which is debatably an acceptable lisp, write''
	(1..10).inject(&:+)
''and enjoy a nice mineral water before anyone's tea has finished brewing.''

Can't resist adding the Swindle/PltScheme version

	(sum-of x (x <- (list-of k (<- 1 .. 10))))

''Though HaskellLanguage's''
	sum [1..10]
''is obviously ineffectual,''
	foldl' (+) 0 [1..10]
''is fine for the strict, and''
	foldl1 (+) [1..10]
''is for the lazy.''

AplLanguage!
	+/ι10

In Lisp-dialect, Shen, using array functions,
    (adds (it0 10))

Or more precisely,
    (adds (it0 11))

----
I've been programming in Lisp for 14 years and though I have a passive familiarity of PeanoArithmetic, it's not from a Lisp context. I've never used it in Lisp (or in any development, period). You are confusing Lisp programming with your academic Lisp course that you had to take, in which Lisp was a vehicle for some formal, mathematical language, and not really a software tool. Too bad for you. I never took a Lisp course at university. (Oh, the courses were available, but I heard it sucked, so I avoided taking them. Then I found out well into my software career that it doesn't suck.)

Lisp has great, normal arithmetic. Bignum integers. Floats of various sizes. Rational numbers. Complex numbers.  Rant about PeanoArithmetic? WTF ...

Never mind lambda calculus or Peano. Never mind fancy macros or recursion: look, can use GOTO in Lisp if you want!

	(prog ((accum 0) (i 1))
	again
	  (when (<= i 10)
	    (incf accum i)
	    (incf i)
	    (go again))
	  (return accum))

	-> 55

----
What follows is largely a discussion of how to sum the first ten integers in Lisp wherein zealots are allowed to exhibit their predictable scorn of c syntax. It may still be worth skimming since several posts show some insight into Lisp's real problem, namely that the patterns required for Lisp's effective use are slow to spread outside pocket communities and that people within those communities are so used to this problem that they discount any pattern originating outside these pockets. -- WardCunningham

A good portion of the discussion below regards CommonLisp vs Scheme idioms - and they're two different languages, really, even if they're both in the Lisp family. Another portion discusses alternate ways of a doing a simple task. The possibility of such is inevitable in any expressive programming language. I could come up with several ways of summing the first ten integers in C++, too. Any programmer working on a real task, rather than amusing himself by discussing language features, would simply pick a favored method and be done with it. To read more into this discussion of summing numbers would be silly. Or were you referring to the parts that follow the summing discussion? 

''Sounds like MentalMasturbation is happening.''
----
Even the insiders get mildly annoyed at Lisp because ...
* Code ends up distributed in a gazillion little functions everywhere (this is the same gripe as RavioliCode, only no OO involved)
** That's a good thing, little functions are easy work with, and are great for building other little functions, it's called abstraction.
* The down side of MultiMethods is that, since classes don't own methods, it's hard to decide where to place them
** You place them in the multimethod, nothing hard about it.
* It's easy to write slow code fast, but can be hard to write fast code
* It spoils the programmer, so writing in anything else feels like working blindfolded with two hands tied behind your back. HaHaOnlySerious.
-- AlainPicard
----
Re: "gazillion little functions everywhere" - The problem is not that there are many little functions. The problem is if they really are ''everywhere''. So try to group them in the source code by layer and by data structure dealt with. Then you can get a good idea how things work at a particular layer without straying far in the source.

Of course, if you get too fanatical about grouping functions this way, you'll probably obsess over ways to support it in the language, and end up reimplementing CLOS...
----
Re: "It's easy to write slow code fast, but can be hard to write fast code" - I realize this is a report of experience, but my experience ''in non-Lisp languages'' just doesn't fit this.

Usually, the speed hits are in a couple of places. If you have well-factored code, it's easy to find these places (ProfileBeforeOptimizing), and easy to change them (usually by replacing one data structure with another, better-tuned one).

Is there something about Lisp itself that keeps this approach from working? My knowledge of the language is limited to academic work and hacking around with Emacs (where performance never seems to be much of an issue). -- GeorgePaci

Data structures provide an example. Suppose you want to do a simple mapping, of objects to objects. There are at least three different ways to do that mapping in CommonLisp, each with different trade-offs; property lists and association lists are linear in lookup time, but very easy and can `shadow' an existing mapping without modifying it, whereas hash tables are your normal table. None of these are particularly difficult to use, but because alists and plists are so easy to work with they are typically the first style chosen; they just scale ''horribly''.

While these same trade-offs can occur in other languages - consider the difference between vectors, deques and lists in the C++ STL - few languages are as rich as CommonLisp; if you're doing a mapping in C, say, you'll probably jump straight to the hash table because you don't have alists to be distracted by them.

That said, I don't think that writing fast code in CL is any harder than in other languages; it's just more tempting to leave the program in a 'works but slow' state. -- GrahamHughes

''Well, I agree with that. We wrote our app carefully, and found that the bottleneck is database access, and stopped profiling. i.e. we're doing as well as we could in *any* language. I'd have profiled until we got to that point, and no further. Now it's all optimizing tables, indexes, etc. -- AlainPicard''

We did the same in WyCash. Once our app was spending 50% of its time in the db we figured we were at a breakpoint in the curve of diminishing returns. But that doesn't mean there isn't 100x performance enhancement possible in an environment where the disk controller DMAs data into working storage that is already structured by static declarations. BeatingTheAverages gives the impression that Lisp programmers are at the top of some sort of evolutionary ladder, when in fact COBOL guys have their own secret weapons too.

''In fairness, PaulGraham describes ItaSoftware as doing a similar trick in Lisp: statically structuring giant chunks of RAM into a sort of memory-resident flat-file database, outside the Lisp heap, but with direct and efficient access. Some Lisps (e.g. CmuCl) give you plenty of freedom (aka rope :-)) for this type of thing, including ways to do C-style pointer/structure access - certainly much more so than (say) Java. With the appropriate kernel hack, I bet you could get Lisp accessing DMA'able buffers directly easily enough for those same 100x gains. I acknowledge that this is mostly an implementation issue, but - Lisp implementations seem strong here, and most others above the level of C don't. -- LukeGorrie (who agrees that Paul pushes his marketing a bit far :-))''
----
I hate Lisp too. I also have a doctorate in implementation of functional programming languages, so although I am no hot shot Lisp programmer, I at least understand what is going on. Why I hate Lisp is:
	* there is no syntactic distinction between code and data. I know that Lisp has no semantic distinction between code and data either. I can live with the semantic blurring, but at any point in the program, an object is being used as a function or as a data, and I would like the distinction to be blindingly obvious. So, I really like square brackets, round brackets, curly brackets, any device to tell me what something means. (LispLacksVisualCues)
	* functions have stupid names, car, cdr, setq, and so on. These mean nothing to me. Lisp is not just a language, it is a culture, and it is a foreign culture to me. Emacs is that culture's sacred shrine.
	* It's not even purely functional, so it doesn't have half the theoretical elegance of Miranda or Gofer.
Lisp was certainly revolutionary for its time, but it didn't have all of the pieces that it needed to attract a large audience. What really annoys me is that there are no doubt some SmugLispWeenie''''''s reading this and saying "oh, he just doesn't get it". I claim that SmugLispWeenie''''''s are just ThreeStarProgrammer''''''s. -- JohnFarrell <A Self-Proclaimed Java Programmer>

* Which pieces do you believe were missing, in any era? Folk myth says Lisp didn't have arrays until late, but that's wrong, they were in Lisp 1.5. Very powerful OO was added pretty early (1980s). Some of the first sophisticated IDEs were for Lisp, notably on the Symbolics Lisp Machine. Fast compilers date to the 1970s. I doubt anything was missing, and therefore I doubt that's the reason it didn't catch on.

It's easy to hate anything that negates most of the value of your hard academic work; the higher the degree, the more work is negated. -- SmugLispWeenie''''''s

Could you give an example of a situation in which it's not clear what's code and what's data, and how you'd like to fix it? Are you thinking of esoteric stuff like macros, or of things like quoted lists? My experience is that most of my Lisp objects don't appear as literals within the code, any more than corresponding things do in other languages (Python might be an exception), so the issue seldom arises.

If you don't like ''car'' and ''cdr'', write ''first'' and ''rest''. I do. ''setq'' is pretty nasty and harder to avoid; I tend to use ''setf'' instead, but that's no better. Actually, I'm not sure what notation ''would'' work well in a language that uses prefix notation; maybe ''<-'' . (Any legal symbol name is only a ''defmacro'' away, though being non-standard has drawbacks.)

*How do you compose first and rest? I.e, how do you write, say, ''cadar''? Something like ''frfst''? -- Sunnan

** Ha ha. But seriously, it is widely agreed that compositions of c[ad]*r are stylistically bad because they're hard to understand. So it shouldn't come up. If need be, macro-ize cadddaaaaddr to be "get-innermost-list-of-third-alist" or something, and confine the "(car (cdr (cdr...)))" to that definition.
*** Macro? I'd rather make it an inline function. But still; cadar is five characters and means "first of rest of first" which is five times longer, which would be fine if it were easier to understand, but it isn't. "Get first key from an alist" would be caar, and "get first value from an alist" would be cdar. (Useful when cdr:ing over an alist.) car and cdr isn't something that you need in every project, but they're great primitives when implementing something like Scheme's srfi-1, or a code-walker, or a lot of other things that's hard to do in non-lisp-languages. (Just read a text by GLS where he asks if C should be called CHAP for "character processing".) -- Sunnan
**** It needs to be a Macro if you still want to use it as a place -- Jason

"functions have stupid names, car, cdr, setq, and so on. These mean nothing to me. Lisp is not just a language, it is a culture, and it is a foreign culture to me." But isn't this true of just about every programming language? Are printf, strpbrk, long long, &c. inherently superior to car & cdr? Doesn't every language create its own culture? Too many times have I let minor idiosyncrasies of a language like this keep me from discovering what it has to teach me. I'm getting better, though, & starting to discover some very interesting things... -- RobertFisher

I've never understood why being ''purely'' functional is supposed to be a good thing in a practical programming language, though I can certainly see that it has advantages if you want to use it for teaching, or as a theoretical representation in doing research. Turing machines have plenty of "theoretical elegance", Conway's "Life" (which is Turing-powerful) even more, but they're not exactly practical programming tools.

-- GarethMcCaughan (not among the SmugLispWeenie''''''s as defined on that page, but confessedly a Lisp fan)

AdvantagesOfFunctionalProgramming talks about some nice properties of purely functional code.
----
I am rather amazed at the strong feelings uttered on this page. I can understand, and even sympathize with, all the technical reasons mentioned why somebody might not select Lisp for his next programming project. But where is the "hate" coming from? I don't consider UnLambdaLanguage suitable for my next programming project, but I do not "hate" it. I speculate that there is something else going on. Perhaps the smugness of the SmugLispWeenie''''''s?

-- StephanHouben (who never worked with a LispMachine)

The truth can be a hard thing to bear. Being told that there is a better way to do something, when you're stuck (for political reasons) with an inferior solution can be hard to take. So the truth-bearers often come across as smug. This applies not only to Lispers, but to Smalltalkers as well, I suspect. It certainly applies to unixers.

''This page was created as a reaction to WhyWeLoveLisp. Hence the strong word of "hate". Do not take that too seriously.''

I'm not sure. The comments on top of the page seemed pretty serious to me. Perhaps the original author could comment? -- sh

They are the words of a knowledgeable wannabe trying to raise the level of conversation above punctuation.

''I think they made a valid comment about parts of the Lisp community, particularly those parts found on comp.lang.lisp and especially those who's initials are E. N. On the other hand, I think unification is more interesting than file I/O, and more appropriate for a university to be teaching. The Scheme community doesn't seem to suffer from this snobbery''

Hmm. I'm puzzled by the reference to comp.lang.lisp, and Mr N in particular. He's certainly unpleasant to a lot of people, but not in the particular way complained about at the start of this page. I've never known him to blather about the elegance of lambda and cons and PeanoArithmetic (though I've seen him lacerate Scheme aficionados for their pursuit of elegance), nor have I seen much of that stuff from anyone else in comp.lang.lisp. I'm certain that the problems are real, but I don't think they're concentrated ''there''. -- GarethMcCaughan

''It's been a while since I read comp.lang.lisp. When I first started reading some poor Smalltalker asked about a deep copy in Lisp and was lambasted by all and sundry. I stopped reading shortly afterwards, so maybe my views are distorted. Delete them if you think they're inappropriate.''

No, you will find that many folks who have had a tangential relationship with Lisp have suffered the exact same experience; that is, they find the SmugLispWeenie''''''s filled with the SocialProblemsOfLisp. Therefore, we collectively '''concur'''.

''Who are "we collectively"? And you don't seem to be concurring, since the point at issue is not whether there are SocialProblemsOfLisp but whether there are the '''specific''' problems described at the start of this page in comp.lang.lisp. -- GarethMcCaughan''

Read the first paragraph on this page again. Go ahead, I'll wait. The author says that Lispers refuse to value the experience and training that purveyors of other languages bring to the table. This has been my experience and that of many others. Those are the "we" who '''concur''' with the conclusions drawn in several places on this page; that is, it is a waste of valuable time to attempt an integration of the Lisp community into the rest of the software development world. Kinda like trying to get Mac users to hook up to Windoze networking.

''Oh, right. So, those who concur, concur. Amazing. Am I alone in thinking that to say "we collectively", without any indication of scope, might reasonably be expected to mean something less content-free than "me and anyone else whose experience is the same"? Anyway: you, whoever you may be, might like to read again the material leading up to your intervention beginning "No, you will find"; you will see that what you were replying to was not only about the first paragraph on this page. -- GarethMcCaughan''

The '''whole page''' is about what was stated at the top and repeated throughout - that is, the Lisp community is full of people who make the use of that language unattractive. The "we" I keep referring to is the community of tangential users. These are folks who have had to use Lisp for one reason or another in the past and have come away with the kinds of negative experience you see vocalized all over this page. Therefore, your assumption that the "we" reference is to people who, like me, share a common experience is valid. Okey-dokey? -- MartySchrader

''I know quite a few tangential users of Lisp, and none of them have shared your view of it. I guess in my experience your "we" would be a small minority of the small number of non-Lispers who use Lisp sometimes, no? I guess you can't please all of the people all of the time. I have no data as to whether or not this small group of people is correlated with the small group of people who occasionally turn up in places like comp.lang.lisp making incredibly stupid demands and refusing to even attempt to actually learn something new, then go away in a huff after being roundly (and sometimes harshly, to be fair) flamed for wasting everyone's time. I have to assume that there are many of you who don't fit in both groups, but logic suggests that some, at least, do.''

And in the mean time we have the SmugLispWeenie''''''s driving people away from Lisp in droves. If it weren't for the SocialProblemsOfLisp there would be a lot more participation in the Lisp community, I'm sure. One major reason I stay away is that I know I'd have to ask questions of the Lisp community as a whole (because there isn't a large installed base of shared expertise out there) and I'd be running into the same newbie-bashing that has always been a part of The Joy of Lisp?. Blech.
----
''I don't buy it. I know about twenty people who have learned lisp at one time or another; some use it regularly and others haven't touched it in ages. Due to this page, I have been polling them informally. Out of all the responses I've had, none have had this experience. Obviously some people have had this experience, or at least feel they have. On the other hand, my experience suggests that this is a tiny, if vocal, minority. The claim of "SmugLispWeenie''''''s driving people away in droves" seems baseless, but I'd be interested to see any real support for it.''

''I concur. I've just started learning Lisp, and asked some dumb questions (due to not learning do loops properly) in comp.lang.lisp and not been flamed. I've had some greate help. I can see some warm posts flickering around in there, but that's usenet for you. Suffice to say, I'd consider my experiences in c.l.lisp comparable to my experiences with the Python Tutor list. I've been flamed much more for newbie questions when trying to learn C.
-- Liam Clarke''

I'd put up a poll, but the damnable SmugLispWeenie''''''s would simply contaminate it the way they've screwed up every other language poll I've looked at on this Wiki. Lispers seem kinda like religious acolytes; they are incapable of taking any negative criticism of their programming language choice, their culture, or their personal hygiene. ''<snicker>''
----
Lisp is the canonical functional, dynamically typed language, so it really is important. Every programmer should probably have experience with Lisp, SmalltalkLanguage, MlLanguage and PrologLanguage if they want to discuss high level programming methodologies. In my opinion JavaLanguage, C++, or VisualBasic are just less interesting, even though they are more commonly used - if programmers in these languages knew Smalltalk they could understand all the methodologies on this site and apply them to their own language.

If we want to discuss data formats we should discuss high level ones that maybe don't have all that much industry support. Then XML users could take the ideas and apply them to XML, or point out where XML is introducing new ideas. For example, s-expressions vs ASN.1, where ASN.1 lets you create new data types and has nice mechanisms for validation. Of course ASN.1 is more of a transport format and it has huge industry support. Perhaps not enough work has gone into creating interesting high level data formats.
----
Some stuff moved in from AreLispersTakingOverThisWiki:

''See the paper "WhyFunctionalProgrammingMatters." It is from a long time ago, but it is still good. Also see the article about how Lisp was used in the Yahoo Store.''

Yahoo has since decided to go with PHP for new development. It was not clear to them that LISP was as good for long-term maintenance as it was for RapidApplicationDevelopment. Languages may be subjective. Just because it was good for PaulGraham does not mean it makes everybody else good at RAD also.

''Here is Paul Graham's take on the Y Store rewrite from a recent message on ll1-discuss''
	 :	I should mention that they actually have just done this. A rewritten version (C++ and Perl) just launched in Jan. However,
	 :	(a) The reason they rewrote it was entirely that the current engineers didn't understand Lisp and were too afraid to learn it.
	 :	(b) The resulting program is a new world's record case of GreenspunsTenthRuleOfProgramming. The Yahoo Store Editor called compile at runtime on s-expressions made on the fly. To translate this into C++ they literally had to write a Lisp interpreter.
	 :	(c) Even then, they had to drop some features (involving advanced uses of closures).
----
''I really think functional methodologies should be explained in terms of Lisp and OO methodologies should be explained in terms of Smalltalk. These languages are easy to learn and there are free implementations. If you want to read about ModelViewController you must know Smalltalk. If you want to read about higher order functions you must know Lisp. These are the classics of programming languages. Better things may have come along, but you still need to know them.''

I believe that knowing Lisp makes you a better C++ or Java programmer. Irrespective of the question which language is "better", many features in those languages are either inspired from Lisp or reactions against Lisp. It is, in my experience, indeed true that every large C++ program contains "an informally specified implementation of half of Common Lisp", so knowing Lisp will help you understand more of the structure of your program. In essence, Common Lisp can be considered as a big source of "patterns" to be mined, which can subsequently be applied in any programming language you like.

-- StephanHouben

But super-high-level languages are like street drugs: once you see how great things can be, it is hard to go back to the cubicle mentality where nobody else can comprehend your code and you are thus fired. Perhaps it is best to never taste them. They make it so that you cannot tolerate stupid peers and PHB's anymore.

''"If you want to read about ModelViewController you must know Smalltalk."''

Not so. I have done Model-View-Controller architectures in C/C++ for some time now. It is a pattern which applies to embedded hardware control systems quite well.

''"If you want to read about higher order functions you must know Lisp."''

Absolutely not so. Who comes up with this stuff?
----
Lisp is not a FunctionalProgrammingLanguage, but it supports functional programming very well. It also supports ImperativeProgramming and ObjectOrientedProgramming (in CommonLisp, see also CommonLispObjectSystem). Lisp can easily be changed in order to support any programming style you might think of. It's a true MultiParadigmProgrammingLanguage.

''Strictly speaking, Lisp is a functional programming language; that is, functions are first-class objects in Lisp. However, it is not a pure-functional language such as Haskell, because operations in Lisp can have side-effects.''

In CommonLisp, classes and methods are also first-class objects. Lisp had the concept of object identity from the very beginning. Yes, Lisp had a strong influence in the functional programming community, but it's not primarily a functional programming language. Look at what people do with CommonLisp, and you will notice that they program in a style much closer to, say, SmalltalkLanguage, than to, say, MlLanguage. I guess, things are a little bit different in Scheme. (Another of those LispSchemeDifferences?)
----
People who do 'get' Lisp usually are better programmers. I would never recruit a person who is not able to 'get' Lisp.

Of course the same could be said of the Calculus.

''Which calculus?''

'''The''' Calculus. There Can Be Only One.

That'd be the pi then?

Non sequitur action, eh? Go fer it, doode.

[Sigh. A little explanation: to the layman, there is just one calculus, the one invented by Newton and Leibnitz, that concerns integration and differentiation and infinite series and such. But to mathematicians, there are many kinds of "calculus", and "the pi calculus" is one such. Nor is this all castle-in-the-sky stuff; university intro to database courses cover "the relational calculus" (and note elsewhere on this very page "lambda calculus"). Don't assume something is a non sequitur unnecessarily; in this case he was making a joke/being sarcastic.]

''It's even worse that that... mathematicians don't even look at 'the calculus' the same way as others, either. And an unqualified use of 'the integral' means something quite different to a mathematician and someone who slogged through a couple of calculus courses :)''
----
[NOTE: Someone deleted the following conversation. Try to refrain from DisagreeByDeleting.]

BlackHat: Does Lisp use StaticTyping (yuck!) or DynamicTyping?

YellowHat: Lisp use DynamicTyping; there is nothing about FunctionalProgramming that requires static typing.

WhiteHat: In math, we have the analogue of the typed and untyped LambdaCalculus.

BlueHat: Functional really means that a function's output can be entirely determined by its inputs. So long as we maintain ReferentialTransparency, we can use any tricks (including mutable state) to improve performance or readability or whatever (although the extent that you can do this is up to the language).

BlackHat: However Lisp sucks even more because its not satisfied with just being functional. I'm especially thinking of Common Lisp here, which tries to be all things to all people. The result of this is an extremely large language that is very difficult to learn.

YellowHat: CommonLisp maybe, but not lisp in general. Have you ''looked'' at the ''complete'' (!) SchemeLanguage specification? Not only is it shorter than CommonLisp's, but its shorter than Java's, C++'s, etc. And even CommonLisp''''''s standard, which is quite a bit longer, is mostly documenting a standard ''library''.

WhiteHat: The core of Lisp is 25 special operators, a fairly trivial syntax, a simple and consistent evaluation rule, and a half-dozen or so built-in data types, similar to the data types supported by any other modern language (arrays, hash tables, numbers of various sorts, characters, etc.) The rest of the "language" is library, much the way the bulk of the stuff one has to learn to use Java is the vast library of classes in the JDK.

BlackHat: People on this Wiki keep saying to those who criticize Lisp that "if you only knew more Lisp you would love it." Well that's one of the reasons Lisp sucks. ''I shouldn't have to know more Lisp.'' I should just be able to learn the whole language in a day and understand it completely. I shouldn't have to have a PHD in a programming language to be able to use it. The fact that Lisp is so difficult to learn is a good sign that it is a bad language. The new languages like Python and Ruby take about 1 day to learn. In another day you can start programming useful programs. Lisp is way too complicated.

* ''The above line from BlackHat is confusing two issues: how long it takes to learn a language and how long it takes to grok/love it. I suggest change to just:
BlackHat: It feels like it takes too long time to learn the nuances of Lisp that some of its proponents say make the languages good.

[[This notion that Python takes only one day to learn is a little bit absurd.  First of all, I took to Python quickly because of my C++/Java background in college.  When I first learned about Python's lists and dictionaries, my reaction was "Wow!  I don't have to create my own linked lists and hashes!"  The "for" loop took a little getting used to, as did some of the other aspects, but I learned it so quickly because of my CS background.  How quickly would someone learn Python if they didn't have such a background?  And, having said even this, it didn't take me "just a day" to learn Python:  Python has a philosophy, has libraries (if I remember correctly, I first learned regular expressions via Python), and even has its own quirks and idioms, all of which when taken together, would take longer than a day.  I have been exposed to Ruby, too, and I've learned enough to know it would take me longer than a day to learn it.

I, for one, am attempting to learn Common Lisp, as well as Haskell.  In some ways, it only took me a day or two to learn these languages; in other ways, they have incredibly deep and powerful abstractions that I still haven't wrapped my head around (even as a mathematician).  It doesn't bother me that it takes more than a day to learn these things!  Well, it does, but it's not an issue with the language, it's an issue with me.  (The same can be said of Forth, by the way, and likely Smalltalk; indeed, there are ''many'' languages worth learning, that would take more than a day to learn!)

Now, if we were talking about C++ or Java, where you have to learn a lot of trivial things, and it takes more than a day to do it, I'm a bit more inclined to agree...but the notion that any language of worth can be learned in a day is a little absurd, especially since languages like Common Lisp have an amazing simplicity that can be learned quickly, but can use that simplicity in fundamentally powerful, yet mind-warping ways that are difficult to wrap your mind around!  -- Alpheus ]]

GreenHat: Forget two days to writing useful programs. I was writing useful programs in Lisp in an afternoon, and I ain't no PHD.

BlackHat: There are other reasons Lisp sucks. It uses PrefixNotation which is stupid since prefix notation adds little to the expressiveness of the language but definitely makes the language much more difficult to read. For instance if I want to do something like (+ 4 5 6 2 1) why not just define a function sum and pass it a list argument instead. Was it really necessary to use unintuitive prefix notation for the marginal expressive power it adds? Lisp also uses way too many brackets.

BlueHat: Um, that's what '+' is - an "and" operator that takes a list of numbers to sum. What would (+ 4 5 6 2 1) look like with InfixNotation? (4 + 5 + 6 + 2 + 1). And we have to give up a clear order of evaluation. There's a good case to be made that InfixNotation feels more natural because that's how most people learned math, not because it ''is'' more natural. Oh, and C uses too many semicolons.

WhiteHat: InfixNotation creates an inconsistency in that 2 parameters look completely different from 3 parameters.

RedHat: True, it requires some mental un-training, but perhaps consistent PrefixNotation is worth it in the long run.

BlackHat: That InfixNotation sucks is no reason to preach PrefixNotation. PostfixNotation is less ambiguous and doesn't need parentheses.

* I don't feel I yet understand the SixThinkingHats enough to integrate these points properly...
** Many languages, like CeeLanguage & friends, use PrefixNotation (aka function calls) more than they do InfixNotation. InfixNotation is often a special case reserved for a small set of operators.
** PrefixNotation could be used without parentheses just as much as PostfixNotation. The parentheses make it easier to parse (because you don't need to know the arity of operators) & allow operators to have variable arity. With variable arity, PostfixNotation needs parentheses too.
** Macros in Lisp can enable InfixNotation or PostfixNotation if desired. If you have an infix macro for infix arithmetic, you aren't so far from the CeeLanguage situation of mostly prefix with some limited infix.
* It could be argued that some things are more natural in infix and others more natural as prefix. String concatenation to me seems better suited to infix. Yes, one could make Lisp macros that do such, but by being able to be everything it ends up being nothing. -- top

BlackHat: Lisp has almost no real advantages over other languages. So what if it has higher order functions, C has function pointers and who really needs a function whose argument is another function which takes another function as an argument.

RedHat: I do. Then again, there are assembly programmers who'd say the same about if statements and function pointers in C.

WhiteHat: FunctionPointers are not always a suitable substitute for HigherOrderFunction''''''s. Function pointers cannot contain either bound arguments or a referencing environment. The latter is not a concern in C/C++ (no lexical scoping), and functor objects can be used to fake bound-arguments in C++ programs that need them.

RedHat: But it's a royal pain to do so.

BlackHat: Screw macros, I don't want to redefine a language, its confusing and unnecessary if the language was designed properly in the first place. Of course with no language redefinition the whole brackets thing becomes unnecessary since the brackets are only there to make Lisp easy to parse. But why do I need the brackets anyway? All languages can obviously be parsed in a unique way otherwise there would be no way to compile/interpret them. Thus one can create a parse tree for any language and redefine constructs to your heart's content.

YellowHat: And Lisp gives you a clean way of redefining those constructs, using the same language. Look ma! No compiler hacking!

BlackHat: The advantages Lisp has over other languages are small and useless. The disadvantages Lisp has, like poor readability, unintuitive syntax, poor learnability and language bloat far outweigh its pathetic and crappy advantages. If Lisp is so good why doesn't one of the Lispers show us a code example that is easy to read, understand, explain without have years of experience in Lisp and can be used to do something useful and is difficult/impossible to do in Ruby/Python. Better still why doesn't one of the Lispers point us to a tutorial that will allow us to learn the whole language in one day?

* That's like insisting that Chinese is not a clear language, because no one can provide you with an example that you find clear with only one day of study. What is and is not clear depends on your idiosyncratic background far more than it is an innate trait of a human or computer language. If your first language had been Lisp (and if you'd coped, e.g. gotten an A in the course or something), you'd have no problem. The real problem is that your first language was Basic or something equally foreign, so Lisp is Chinese to you. Anyway, this is very much a HostileStudent kind of response.

YellowHat: If you're interested, and are familiar with Java, I'd recommend JayScheme to begin with. A pretty much complete implementation of Lisp, except for an obscure detail of continuations, which I'm guessing you're not likely to run into for a while. Also, it lets you make use of any of Java's libraries (or any Java code really), thus highlighting your confusion of libraries vs language.

RedHat: I find it beautiful that Lisp is "written in itself" in more than one sense - the way it blurs the line between syntax and semantics.

BlackHat: What a smug geek you are, my beloved RedHat, you are truly an example of the SocialProblemsOfLisp.

BlackHat: Lisp is so wasteful with its conses that it needs a GarbageCollector.

YellowHat: Any language without explicit memory management needs a GarbageCollector. That doesn't mean it's wasteful. Modern GarbageCollector''''s are, for all practical purposes, as fast as explicit memory management, and most Lisp versions use a kind of garbage collector that is very intelligent. It might even be faster for large volumes of memory!

* Caveat: Garbage Collection is '''not''' free, however. To get best case performance (where it can sometimes be even faster than explicit management) requires e.g. for 6/7ths of memory to be free on average, with current best algorithms. Sometimes that's not a problem, but obviously sometimes it might be.
** Question: Does that rule only apply for virtual memory environments (where the GC causing a page fault and pages being swapped to/from disk can ''kill'' performance), or does it apply to EmbeddedSystem''''''s and the like as well?

BlackHat: Lisp is a marginal language with fewer users than <insert popular language>.
----
Maybe I'm misunderstanding the SixThinkingHats, but is BlackHat really supposed to be factually incorrect (or at least using a StrawMan) just so that YellowHat can correct it later? Witness BlackHat'''''''s open statement, "Lisp does suck..."

''In this case you are quite correct; BlackHat ''is'' presenting a Strawman when talking about functional languages and static typing. It's a poor excuse for a rant, eh? Feel free to clean it up a little.''

Changed that part but it needs more. In my eyes, but maybe I'm biased since I love Lisp, BlackHat sometimes comes of as an idiot rather than discussing Lisp's real problems (which I am very curious to hear). I added a RedHat and some more BlackHats.
----
'''Archaic Names'''

LISP seems to have too many useless names in its base library. Example, "progn" instead of "block", "car" and "cdr" instead of "first" and "rest", etc.

''The point about names being archaic is made already above.''
----
Perhaps this topic needs a reorg (RefactoringCandidate). One has to do a long sequential search to see if something is already covered.

''That would be because there is so ''much'' to hate about Lisp, I guess.''

[If so, it doesn't show up on this page. This page is more like: lots of people complain about Lisp without understanding it, and some of them apparently don't understand the point they are trying to make, either.]

''Geez, we '''must''' be looking at different pages, because there are certainly a lot of cogent arguments for Lisp hate outlined on this page.''
----
What it really comes down to is that people here seem to hate a few Lisp users. The technical aspects of the argument are, well, weak at best. It's frustrating when smug-sounding people attack the languages and techniques that you hold near-and-dear, and Lisp users tend to do that a lot (sometimes without even seeming to realize it). You would never see some of these complaints leveled at other older languages. C has tons of archaic and generally over-abbreviated names in its stdlib, but no-one would seriously level that accusation in a language fight.

Lisp seems to draw lots of fire because it unashamedly says, "Programming is Hard. Here are tools to deal with that." Languages such as Java take more of a "We can make programming more Simple with this language." Lots of people want to believe the latter, not the former.

My purely opinionated comment is, "If programming could be made simple, then Java and C# would be solving the problems of software right now. They are not, so I am skeptical of this approach."

-- DaveFayram

It's called failing to learn from history. Java and C# did not bother to borrow several of the most important features of Lisp...yet. If they had, then it would be more a question of which syntax you prefer. -- DougMerritt

[''They did borrow the '''most important''' features of Lisp: imperative features, ''cond'' (-> ''if-then-else''), some garbage collection ideas, some scope ideas, etc. Lisp is simply a ''different way'' of doing ''imperative'' programming. Other languages are different ways of doing functional programming in a less functional way. I don't buy the argument that functional and imperative are ''completely'' separate from each other. Especially since in Haskell, Lisp, and other functional languages,  they've always had to bastardize the functional purity by adding on imperative stuff (such as linking to a DLL or shared object with imperative code in it, or using a (print 'something') in code, using monads, etc).'']

[''It is useful however, to learn how to discipline ourselves (being pure some times, for the sake of limiting ourselves). However I don't buy the argument that there is a functional language out there that isn't imperative in some way. Without some imperative bastardization, the language is useless. This is why we see hacks like Lisp binding dashes to underscore C dll/dso functions, and it is why we see a print procedure in a functional language hello world program, and it is why we see Monads, etc etc. Not that this isn't worthwhile - to identify some purities and practice them until we have to escape them.. but there are still folks out there who believe they aren't doing imperative programming at all (and that is sad, that they are so gullible and naive).'']

[''When we finally make use of a ''database'' or other real world modifiable structure, what can we say for ''functionalism''? Side effects galore - '''bastardized''' functionalism? See also EventualSideEffects.'']

''What "problems of software" are JavaLanguage and CsharpLanguage failing to solve, why are they failing to solve them, and how in particular would Lisp help? Specifically, Lisp in the hands of your average IT-department programmer (given suitable training in the language, of course).''

[They are failing to offer language features that have been proven enormously useful in making code simpler and less verbose. Closures, LexicalScope, FirstClassFunction''''''s, Continuations, and MetaClass''''''es to name a few. Working in these languages is like having one hand and two feet tied behind your back, sure you can get things done, but it's a lot more work to do it. CSharp is at least adding the first two in it's next version and already has FirstClassFunction''''''s(delegates), I'm not sure about Java.]

''When I survey the computing landscape, I see tons of useful production code being written in Java, C#, Python, C/C++, Perl, etc. In other words, problems are being solved. Perhaps not as elegantly as they would be if a team of GrandMasterProgrammer''''''s, armed with their favorite tools, were turned loose on the problem; but they are being solved nonetheless. And given that GrandMasterProgrammer''''''s are in short supply (though quite a number of programmers include themselves in that category), solving problems with programmers of average competence is an important issue to consider.''

''Not to say that Lisp couldn't do the job as good or better; but from where I sit the situation in mainstream programming is nowhere near as bleak as some would put it; nor are things like Lisp or Smalltalk or (insert favorite SilverBullet here) the panacea that their proponents giddily and smugly are fond of claiming.''

[It is as bleak as some are putting it, the mainstream languages we are forced to work with are 15 or more years behind the power curve in features. That's quite pathetic. SmallTalk and Lisp have yet to be topped, or even equalled. Most people like Python or Ruby, just because they're the closest thing to SmallTalk they are allowed to use. I'd take SmallTalk over Lisp, but only because I can't seem to get used to the parens.]

Well, I'm not saying Lisp is somehow a magic panacea to cure the world of software development. However, I can't help but be skeptical of the path that Java and C# are taking. We still see projects fail, get turned in late, miss features, suck, and otherwise fail to meet the expectations people have for them. Sure, the software industry is young, and it may take another 50 years, but we should be seeing at least a little bit of progress by now.

''There seems to be a dearth of evidence to back up the (implied) claim that the reasons projects fail/are late/miss features/suck, etc.... is due to the choice of programming language. It might be; but in my experience many project failures are issues of ''management'' (unrealistic expectations, failure to get the requirements right, failure to herd the cats appropriately, failure to plan appropriately) rather than the tools used. Certainly the tools are important; but any suggestion that "we wouldn't have a software crisis if we all used Lisp" strikes me as patently absurd.''

But no. Things really aren't any better than they were before. More software is being made, but software really isn't getting any better.

''It is, however, getting far more ''complex''; the ability to deliver projects of continually increasing complexity does suggest something is right in the programming world.''

Java, and now C#, didn't really fundamentally change anything, except arguably to enable more people to program. A project isn't any more likely to survive, turn in on time, or meet expectations when made in Java or C#. 

''This claim, however, seems to be implied about Lisp and others. I certainly don't claim that Java/C#/other MainstreamProgrammingLanguage increases productivity over Lisp; instead I claim that in many development situations - the effect of the language choice is a) in the noise, and b) dependent on other factors.''

Further, many talented developers say they don't like the feel of Java or C#. People who get things done have a funny tendency to know what's good for getting things done. 

Is Lisp, or Smalltalk, or an ML derivative solving this problem? I don't know. But, I do know that I tend to hear more talented, accomplished people talking about Lisp, Smalltalk, OCaml, Python and Ruby a lot more than I hear them bubble about how great Java is. This really should count for something. My own experiences, although perhaps limited compared to some of my peers here at the wiki, also suggests this. 

''Depends on where you live and work, I suppose - I know of "ManyTalentedDevelopers" who only use Lisp to configure their editor. (Guess which one?) That, of course, doesn't impeach Lisp in any way - I bring this up only to illustrate the point that Lisp doesn't have a monopoly of talented developers in its camp. Some in the Lisp community have the unfortunate habit of suggesting that one's programming competence is directly proportional to oneýs skill/familiarity/enjoyment of Lisp. While a broad exposure to many different languages and paradigms is a great thing; Lisp certainly included - the suggestion that a strong Lisp background is a prerequisite to becoming a GrandMasterProgrammer is absurd.''

Agreed. But 90% of GrandMasterProgrammer''''''s learn Lisp at some point to see what all the fuss is all about, if nothing else; for such programmers, it's not a big sacrifice to look into the subject enough to get a feel for it (whereas it is apparently a big deal for the great unwashed ArmyOfProgrammers).

Oh... I don't mean to imply anything about the skills of those who have not looked into Lisp, btw, the logic doesn't work backwards. -- DougMerritt

''Without making any claims to be a GrandMasterProgrammer myself; I have dabbled around in Lisp. Some features in Lisp I miss in C++ (which is what I have been using for quite a few years, doing EmbeddedSystem''''''s). GarbageCollection mainly; a decent macro system, mainly. HigherOrderFunction''''''s and the like C++ can do a good enough job of faking; and LexicalClosure''''''s can easily enough be simulated with objects (and vice versa). DynamicTyping I find I seldom miss, but that's just me.''

''Continuations I miss not one whit; but I tend to think that ContinuationsAreGotos.''

* I haven't used them very much, but I get the impression that they are at their best as one of the tools to use when creating Scheme macros, rather than raw.

''One interesting question, though, is the following: Could the "great unwashed ArmyOfProgrammers" benefit from the advanced features of Lisp? Certainly some could; however, I run into code on the project I maintain written by people who clearly don't grok the basis of OO - and have trouble even with simple procedural stuff. I shudder to think of such programmers playing around with HigherOrderFunction''''''s, especially when mixed with LexicalScoping. (Of course, the same can be said about pointers and other C/C++ features)''

''In short, I suspect Lisp wouldn't solve all the world's problems simply because the world's problems aren't caused by a lack of HigherOrderFunction''''''s, or any other given value of "Blub". The world's problems (the software world, at any rate) exist before the first line of code is entered, and are entirely orthogonal to the choice of programming language.''

Yeah, yeah, but since there's nothing to be done about bad programmers (unless you believe the Java claims), and since there is irreducible complexity in many problems, the question still remains, which tools can best help programming in the ideal case? And you have listed some of them that are missing from e.g. C++.

[There's nothing you can do about bad programmers, but you can try not to cripple the good ones by making them use crippled languages that force them to "fake it". You shouldn't have to "fake it", the damn language should have the features. Anyone designing a new language that leaves those features out should damn well be ashamed of themselves, unless of course, they are building a language specifically for bad programmers.]

''Another interesting question to ask: Suppose Java did have HigherOrderFunction''''''s (or a more reasonable approximation than InnerClass''''''es). Throw in a few other features found in Lisp - say, macros. (Keep it statically-typed, just so we don't go too far afield). How much would that improve the productivity of the Java community? Probably by an amount which is noticeable, but I seriously doubt we'd see order-of-magnitude improvements. Were I to have a choice between those things, and the new features in JDK 1.5; I'd probably go with the new features in JDK 1.5 - the current feature in Java that I miss most are proper generics. A moot issue for a dynamically-typed language like Lisp to be sure; but a necessity for a good statically-typed language.''

''All kidding about VisualBasic above aside, Java (and other languages) do seem to lower the bar for programmers, at least a bit. I know lots of people who would get lost programming in Lisp (or C/C++ for that matter) but who can handle CrudScreen''''''s in Java or VB or Delphi. Some of us turn up our noses at these folks (see comment below), but they have their place in the programming community and they ain't going away.''
----
Why does everyone talk about the GrandMasterProgrammer as if they were some elite, unapproachable cadre? Shouldn't we all be trying to become GrandMasterProgrammer"""s? If not, why on earth not? 

''Yes; I want to learn as much as I can. However, for some Lisp appears to be more than a programming language; it borders on religion. While the Lisp community has much to teach, it also has much to learn - and it has shown no inclination to do so; loudly insisting at every opportunity that Lisp is better than this, better than that, better than the other. In particular, the Lisp community - or the segments of which I speak - has little clue about engineering economics, or else disregards them as irrelevant. Which is unfortunate - if a major vendor (i.e. MS, IBM, Sun, not XeroxCorporation - that's the death knell) were to get behind Lisp and support it, I think that the programming community would benefit.''

''I realize that I'm painting with a broad brush here; for which I apologize. Fortunately, the above rant does ''not'' apply to much of the Lisp community; just to a rather noisy subset - but a subset that makes the whole community and culture around the language unpleasant to deal with.''

As is well known, this phenomenon has nothing to do with Lisp in particular, it is a universal that arises with anything that has a loyal following but is a minority interest. These complaints have been leveled, for instance, at the MacIntosh and Amiga communities, amongst zillions of examples.

And in any case, that's a topic for SocialProblemsOfLisp, not WhyWeHateLisp; people may hate Lisp the language because of their perceptions of Lisp the community, but if so, that's irrational.

''I'll repeat a claim I've made elsewhere: The language of the future (for some definition of future) will resemble (in many ways) both Lisp and Smalltalk. But it won't be either.''

Quoth Ed Borasky, September 9, 2005: *Exactly* this statement is being made about Ruby! Except that Ruby also has big chunks of Perl influence and a tad of CLU as well. But -- why do *I* hate Lisp? I don't, really. I learned it, I run it on my Linux boxes (all four main Open Source Lisps). I wish there were more Lisp programmers. Unquoth Ed Borasky.

[So let's invent SmallLisp or LispTalk and be done with it!]

* Lisp's OO facilities basically have long since done the one, while Smalltalk fans (a) love the minimalist design of Smalltalk and (b) do already enjoy several of Lisp's most important features (albeit not macros). The language of the future he refers to would necessarily be much more than just a fusion of the two, but it would be strongly educated by the two.

I agree. In fact, I'm working on it. :-) But in its current absence, we can still diss C# and Java for leaving out key features. It never fails to amaze me how most language designers fail to study existing successful languages. What this reflects about their mindset is terrifying. Lisp macros, for instance, could have their essence added to pretty much any language without detracting from that language's philosophy and goals, since they're a compile-time (read-time) matter. So they should be everywhere by now. That they are not speaks volumes. -- DougMerritt

[I would kill to have macros in C#, but I don't think macros will ever be popular with the masses. Seems to me most people hate the idea of letting the programmer invent his own language, because they want replaceable programmers. I agree on the dissing C# and Java for leaving out those features; I work primarily in those languages and it kills me not to have them. I shouldn't have to keep writing loops all the time, but their lack of certain features forces it on you. You can't really build a decent collection protocol in either language yet. C# will let you build one, but without anonymous functions, you'll rarely use them, that'll change next year at least. As Smalltalk goes, I don't think it needs macros. Lispers seem to use macros to beautify lambdas into simpler forms and dynamically generate code. Smalltalk beautified lambda at the language level with [] and blocks are so common that you don't need to hide them. Macro's seem to be used to invent new control structures, just as [] is in Smalltalk. Both languages make it trivial to implement DomainSpecificLanguage''''''s. Personally, I prefer Smalltalk; better syntax.]

''I think that the piss-poor nature of the CeePreprocessor is partially responsible for the anti-macro bias in many language communities. (But not completely responsible; BertrandMeyer makes a few reasonable arguments against macro systems in ObjectOrientedSoftwareConstruction). Smalltalk likely won't have macros because that goes against the language philosophy of late-binding everywhere. Scripting languages don't really need macros for much the same reason.''

''-- ScottJohnson''

[I totally agree!]

The previous statement about macros and scripting languages isn't really true. Lisp also does late binding, as late as possible. Lisp macros allow code transformation, which really isn't related to the issue. The most common case of macros, in which you provide resources that are set up for you then tore down, are not that impressive because languages like Ruby can do them using blocks. 

However, more advanced examples like the loop macro and the lisp restarts system are examples of where macros can do more. Ultimately, you could just write an interpreter or call eval or something in another language. Lisp gives you a way to do the same thing very naturally, in Lisp, and with essentially no performance cost, and without any extra tools. It's meta-programming without any hassle.

The problem with macros is that it's rather hard to do macros on anything but s-expressions. :)

-- DaveFayram

''Agreed that Lisp is a late-bound language. However, macros are still evaluated at read time, not at runtime. Of course, in Lisp the distinction is blurred as you can feed new code into eval at runtime, which then executes the ReadEvalPrintLoop anew - including evaluating any macros. But even here, eval still has the behavior of first a) performing macro transformations - turning EssExpression''''''s into other EssExpression''''''s, and then b) executing the final EssExpression that you get after the macros all terminate.''

I'm not going to argue semantics with you. In interpreted languages, macros and late-binding are orthogonal. -- DaveFayram

* LispLanguage is frequently compiled as well as interpreted, so the distinction does matter. The distinction between function and macro also matters for polymorphism - functions in Lisp can be polymorphic on their types; macros cannot. If one function calls another; the second called function may be different in successive iterations; depending on the type(s) of the arguments. Once a macro is expanded, though, it stays that way. ''I dunno...that's like saying that once a function has been called, its return value can't be changed. Yeah, but on the next call, or next expansion...'' 

** Indeed it is. That's not part of this little by-play, though. What issue was drawn with was: "Smalltalk likely won't have macros because that goes against the language philosophy of late-binding everywhere." Smalltalk, Ruby, and other languages in that vein could easily support macros without any impact on their status of late binding. Macros are just places where code should be transformed before being eval'd. In a purely interpreted environment like Ruby or Smalltalk, macros wouldn't make much difference.

*** Smalltalk is usually compiled to ByteCode (see SmalltalkVirtualMachine), however; it isn't considered an "interpreted" language in the classic sense. Given the highly-integrated nature of the Smalltalk environment; I'm not sure how important this distinction is.

**** Implement macros as functions that get called on code then. Nothing stops this from being a valid approach (and in pure interpreters, that's what it is). The common implementation of macros is a compile time translation (because it is easy). This whole BugsBunnyArgument is kind of moot, because smalltalk's syntax really wouldn't be a good candidate for macros anyway. -- DaveFayram

**** Disagree. The more syntax variations a language has, the more awkward the macro would be to write, but '''only''' awkward; it doesn't affect the outright feasibility. The main question is how to flag that a macro is being defined and how to quote, the rest of the Smalltalk syntax is simple.
**** ...although maybe there are extreme cases; Paul Graham thinks that Perl's baroque syntax would make macros inappropriate. http://www.paulgraham.com/arcll1.html
***** Surely Perl is a boundary condition for this....
****** But Perl has something very similar to lisp macros already: http://cpan.uwinnipeg.ca/dist/Filter-Simple . It works on text rather sexps, but Perl isn't exactly bad at working with text.
****** No. Lisp macros and text macros are significantly different. In this case, Filter-Simple is actually '''more''' powerful than Lisp macros, but that has both good and bad points. One of the things that is cool about Lisp and Scheme macros is that they are relatively safe to use (e.g. they are hygienic, which took considerably research effort). This relative safety is never true of powerful text macros. People who are strongly against macros are usually talking about text macros. So there's still room for adding Lisp-style macros to Perl, too, in that sense.
****** Go check out the paper ''GrowingLanguagesWithMetamorphicSyntaxMacros'', just a few mouseclicks away. It compares and contrasts several different common macro systems, including EmFour, CeePreprocessor, DefineSyntax, CppTemplates, and a few others. (It also discusses - favorably - the preprocessor for <bigwig> developed by the authors - which is being reportedly adopted for NeedleLanguage as well). It's a well-written, scholarly paper; rather free of grandiose claims, hype, flames, etc.
******* My favourite macro system is Scheme SyntaxCase, which isn't in R5RS (that's SyntaxRules) but AFAIK can be implemented with it. It can be as safe as SyntaxRules or as powerful as CL's DefMacro. It's also IMHO easier to use than DefMacro. I liked the paper, though, and will probably re-read it.
**** You spend so much time writing the macros, you might as well just do it right in the first place
----
'''Name at least 5 useful websites or programs that people actually use, that look and/or work good using Lisp'''

Ok, I'll bite. Off the top of my head and in no particular order: Orbitz (the most powerful airfare search tool, in side ITA), Mirai (powerful, somewhat outdated but still used professionally, high-end modeller), Atraxis AG (airline management), Intel's layout verification tool whose name I forget, American Express uses it for some part of their authorization procedure, Clinisys uses it for clinical trails software, um, I'm past 5 now.

As for your 'websites' part.... If someone is doing their CGI or backend stuff in Lisp (and some do) you won't be able to tell from the pages unless it is advertised....

''A few others...''

* http://alu.cliki.net/Success%20Stories
* http://alu.cliki.net/Industry%20Application
* http://www.franz.com/success/customer_quotes.lhtml
* http://www.franz.com/success/

''Something which applies not only to lispers, but to Smalltalkers, Rubists, etc:''
	 :	http://www.onlamp.com/pub/a/onlamp/2004/06/24/pragmatic_programmers.html
''"Paul Graham makes a big deal out of the way Lisp helped him while building the software that became Yahoo Stores, and he's right. These languages, applied properly, are a strategic advantage. I know some companies are using them with great success. And you know - they're keeping quiet about it."''

* Of course, most companies don't go broadcasting the architectural details of their enterprise software to the world; whether or not they use Lisp or Java or CobolLanguage or SmalltalkLanguage or whatever. :)

I recently had an email conversation with Matthias Radestock of http://www.schemers.org. He claims that
	 :	"It is quite common for companies to downplay or not even mention the role of Scheme in their products."
I assume the same is true of Lisp? Why would companies using Lisp purposely avoid the mention of the language? What strategic value is there in denying the use of a potent tool? Would the inclusion of Lisp in the product literature and web sites not make their products more attractive to the well informed? Or, is it just an implementation detail that they consider too low level to be worthy of mention, as would be C, C++, Java, or assembly?

* PaulGraham explained his point of view about this in his well-known essay "Beating the Averages", http://www.paulgraham.com/avg.html;
		 :	"A startup should give its competitors as little information as possible. If they didn't know what language our software was written in, or didn't care, I wanted to keep it that way."
	 :	That quote is intended to give the flavor of the essay, not to be a replacement for reading it.
* Did you take the same tone with Radestock in regard to Lisp as you have taken here? :-)

''The Yahoo Stores situation is kind of unique in that growing fast versus maintenance may have different issues involved. For "new frontiers", a "write-only" code approach may be the best way to beat competitors (HackerLanguage). However, when things settle, then an organization may need a coding style that's easy for "generic" programmers to pick up easily. HR may not allow them to pay for premium or overly-specialized programmers, for example, because "other companies don't need to pay that much", or the like.''
----
Anybody here remembers the reason behind the use of the damn #' "abbreviation" in front of lambda values? I don't know, but every time I try to do something with LISP, I wish it was Scheme. Whenever I try to do something experimental, test a cool trick, macro, etc, the natural inclination is to start DrScheme, and avoid Lisps at all costs. For people who don't earn their piece of bread from LISP, Scheme imposes a much lighter load on our limited skulls.

''It's a namespace issue. A trade-off is involved; Scheme suffers the disadvantage of you having to remember if there was a function with the same name as your variable. This bites you when you're working for Ford and want to name a variable "car". Plus, you must rename list to lst, which looks like 1st, or be more creative and say lyst.''

''Lisp's disadvantage really only bites when you're using a functional style. As you probably know, you can use imperative or other styles with Lisp. Since Scheme has a strong bias towards functional programming, their set of tradeoffs was probably forced.''

''However, it would be nice for Common Lisp to gain the advantages of both somehow, for the sake of functional programmers. There have been proposals to this effect. Unfortunately, those who feel strongest about this issue tend to just use Scheme, which means there is less force for this change.''
----
'''Strings as Meta Tools'''

I learn toward string processing and string substitution to provide all kinds of "meta abilities" from a language. Lisp does too much internally in my opinion. Plus, string-meta-ing allows multiple languages and tools to feed the meta machine. For example, function names can come from text files and databases. In stringy languages one just substitutes the function name text in place of the place where a regular function call would go, but in Lisp it has to be turned into some kind of internal symbol in Lisp's murky grey box data structure. A stringy language does not have to have a built-in concept of higher-order-functions, it just processes strings. You get meta abilities mostly by tweaking strings to be interpreted. Thus, languages such as TCL look more inviting to me than Lisp at this point. Lisp does not deal with EssExpressions as strings, but wants them converted to it's internal byte-code format instead. This creates an extra layer of communication between the programmer and the interpreter.

Here are some string versions of some favorite "higher concepts":

* Higher-order-functions: String has function or code to be executed with an "eval"-like command or approach.

* Closures: A text block of code with run-time execution with some way to access the variable stack to get variable or caller context, such as TCL's "upVar" command or ColdFusion's "caller" variable referencer.

I realize the byte-code approach probably runs faster, but is the goal here to make the programmer happy or the machine? 

-- top

A few disadvantages that come to mind:
* Higher overhead. ''Much'' higher overhead if you can't cache the result of "compiling" your strings as a reusable object. With Lisp, no lexical analysis involved, and no parsing. Depending on your compiler and program, there still may be a compilation step (translating the tree representation to machine or intermediate code) - the output of which can/will be cached.
* ''I already agreed with the speed issue. No need to restate it a second time.''
* Scoping issues. In what scope is your string evaluated? Do you have any control over this?
* ''What do you mean by "control"? Different languages offer various levels of control.''
* Harder for the code generator to check for run-time errors. Example: That was supposed to be a function name? No way to check. In Lisp, since you would actually work with an object representing the function, you can easily check its type.
* ''Check Shmeck. Itsa scripting language. Want checking using Java instead of Lisp.''

I'm sure more competent Lispers can add to the list above.

Additional comments (consider correcting your text and removing this list):
* ''"one just substitutes the function name text ... but in Lisp it has to be turned into some kind of internal symbol"'' Wrong. If you want to reference a function, you mention its name in your code and precede it with #'. This gives you a reference to the actual function as an object. Couldn't be simpler - two characters in front instead of a double-quotes in front and back. See, it even takes the same number of characters to refer to a function by name when working with Lisp vs with text.
* {Why have 2 different ways to do the same thing? It is not feature-wise OnceAndOnlyOnce.}
** Huh? When working via text, you put quotes around the name while you're treating it as a string. You don't do that in your normal code to call the function, eh? So how is that any less "two ways to do the same thing"???
* ''"...Lisp's murkey [sic] grey box data structure."'' I'm getting quite tired of these kinds of phrases recently on wiki. What's murky about it? A number of introductory Lisp books can show you in excruciating detail how Lisp code-as-data is (at least conceptually) interpreted. Should only take a long evening or two to go through it.
* {I want to *see* the data structure rather than guess what it is inside. There are two ways to do this. Either we have some kind of data-structure-oriented programming with tools to study the structure in action, or we use strings as the data structure. Being that the first is not mature yet, I often opt for strings instead. One can get tired of trying to see or predict Lisp's internal database. Reminds me of the goddam DocumentObjectModel. It is a case of HiddenDatabaseSyndrome.}
** You can't look at a string without a tool either - your debugger, or print statements. These tools are available in every Lisp, also, for all its data structures. (Believe me, ''debuggability'' is the last thing you want to try to criticize about Lisp, you'll only look very, very ignorant.) And what's not mature about Lisp's data structures, or the tools for looking at them? What drivel is that?
** Whoever is writing this drivel, please read the responses. You added the reference to HiddenDatabaseSyndrome ''after'' my reply, and there is nothing, absolutely positively nothing, "hidden" about it. When working in a Lisp environment, all Lisp data is just as transparent as strings.
** ''But the language and the internal structure are not conceptually linked very closely.''
*** I don't know what you mean by that, nor by your immediate 2 comments above, and at this point I'm suspicious that you may not, either; everything you're saying about Lisp sounds, well, just plain wrong. You seem to have picked up misconceptions. At this point I think you should back up and re-examine what you think you know about Lisp. -- DougM
*** The ''internal, implementation'' structure is, of course, opaque in any language. But Lisp has a very well defined representation of source-code-as-data-structure that is quite closely linked to the written text. This representation is not implementation-dependent, it's fundamental to how Lisp works and it's what makes Lisp's macros powerful. Doug's right, you need to do some very basic reading on Lisp before having a justifiable reason to hate Lisp. -- DanM
*** ''(Response moved to HomoiconicLanguageDrawbacks)''

Furthermore, strings are at their best when they are parsed by the language - which '''is''' the case with Tcl strings used for code-as-data, but is '''not''' true for most meta-uses of strings. For instance, the classic "let's put SQL into strings!" is extremely widely used, but is also a horrible last-resort kind of thing to do. SQL, like any language, ideally should be parsed as early as possible, not stuffed into unparsed strings whenever possible.

''There are big battles over this in other topics. It is a classic HolyWar.''
* If you read my phrasing you'll note I didn't say "never put them in strings", just that it is desirable to parse them as early as possible - for some applications "as early as possible" will be "very late indeed". So I reject your accusation that I was repeating a side in the HolyWar; I took a middle of the road position on it.

As for "Lisp does not deal with EssExpressions as strings, but wants them converted to its internal byte-code format instead. This creates an extra layer of communication between the programmer and the interpreter." No, no, and no.

''DynamicStringsVsFunctional''

There's nothing special about strings; one might as well make the opposite complaint of TCL, that it doesn't deal with strings as EssExpressions. S-expressions have several advantages over strings, as a matter of fact.

* Transparency is not one of them.
* ''This is not true, so it's one more reason I think you are misunderstanding Lisp.''

In any case, there is usually no "internal byte-code" in Lisp, and if there is, it's a hidden implementation detail, not a language characteristic. Tcl code, for that matter, is in the same boat - it may well use byte-codes as an implementation detail.

* But the programmer can think in strings regardless of what optimization steps go on.

This is all just confused and suggests a misunderstanding of how languages in general are implement and what byte code is.

* One ideally should not have to worry about how languages are implemented.
** Absolutely, which is yet another reason why "byte codes" should not even have been mentioned; they are irrelevant at best. Top has mentioned implementation issues on this page; Lispers have not. Top appears to think that it's the other way around, which is why I think he's got some confusion on the topic, that's all.
----
Using EssExpressions for everything has some "naturalness" limitations. For example, some Lisp dialects added special syntax for named parameters and/or maps because parenthesized pairs were found to be non-natural to enough people to warrant additions to Lisp syntax. Other short-cuts have popped up over the years. If we truly want to be able to make a "language custom to the task" using our tools, then EssExpressions may get in the way. "String-oriented" languages that provide more tools for custom syntax are thus perhaps better suited for such. Standardization has plusses and minuses. In the end a language is just a user interface for programmers.

''This is non-controversial and quite true. This is why CommonLisp allows one to create new syntax at multiple levels. ("String-oriented" tools are given by customizing Lisp's ''reader'', which is the part of Lisp which slurps in characters to turn into sexps. ''Read-macros'' are one example.) If Lisp has a minimal syntax, it is so programmers have an easier time creating their own. Of course, I'm sure the current system might be improved even further.''

''This is one reason why Lisp and Scheme are increasingly distancing themselves from each other. Not because of flamewars, but because these two languages have evolved into very different mindsets. Some people who learn Scheme might feel dissatisfied with the provided notation, and project that helplessness onto Lisp, which did not make that trade-off.''

Another naturalness complaint is that the "verb" is easier to visually separate from the parameters if it is on the left-side of the parenthesis instead of the right, mixed in with the data or parameters.

''Lispers tend to believe just the opposite, but you are free to disagree and use other languages. The people who prefer sexp notation see the reason for it and find the result not only aesthetic, but also potent. The reason is simply that code is within a manipulable data structure, and the operator is the first element of it. The interesting critique is whether another structure, say an OOP object, is more appropriate. This I believe is a good research project. I suspect that sexps are good representations of code for essentially a 2D interface, and would like to see if that dimensionality assumption can be challenged.''

But that convention could be kept without having it inside. If you have data, then just ignore the first item, or have it be "list" to indicate what kind of info the construct is.

Also, 2D? You mean 1D. Line-feeds don't convey any info in EssExpressions. 2D would be something like TableOrientedProgramming, and/or spreadsheet-oriented programming (described near bottom).

''No, I specifically meant 2D; the visual interface to the programmer is actually in two dimensions. (If you disagree in the same manner, then I will have to let you have the last word, since I don't want to get bogged down in terminology.) With your earlier argument that you'd prefer more conventional syntax with the operator left of the parenthesis, well then DylanLanguage may be your lisp. Or the (admittedly vaporware) ArcLanguage. If you want to turn these two alternatives down, and don't want to use the "string-oriented" facilities in CommonLisp, then I am afraid Lisp is not for you currently. Which is fine; I can't guarantee you that non-custom software will suit every wish of yours. I just think Lisp offers you a great deal of latitude for creating what you need. But accept my support in hating Lisp; I am perhaps spoiling the fun and so I will go do something more interesting now. I agree with PickYourBattles.''
----
It is a CareerLanguage. It is not easy to get in and easy to get out.
----
If I am to learn another language, I want to have OneGoodOfficialImplementation of it, that is portable, and whose libraries are portable. Good examples are JavaLanguage, PerlLanguage, PythonLanguage and RubyLanguage. Maybe LuaLanguage. CeeLanguage and CeePlusPlus are not good examples, but those languages are now a fact of life, not something you can choose.

On the other hand, CommonLisp doesn't has this. They have a lot of interpreters or compilers (or both!), with very different characteristics, and libraries that don't work on every implementation. (if you don't believe me , see this:
http://www.cliki.net/Common%20Lisp%20implementation for a table comparing different Lisp versions)

So you can choose to learn to program in one of those implementations, or learn the core and not be able to do anything useful, because libraries are not part of the core. And we have no interest in learning Lisp, because there are not great things to hack in lisp (exception made of emacs and autocad).

I think PaulGraham has noticed this, because he is developing his ArcLanguage with a small group of hackers, so he has the chance of becoming a LarryWall or GuidoVanRossum. Good luck to him.

-- JuanPabloNunnezRojas

I'll bet you've been programming for less than, let's see, ten years or so? Prior to that, standardized or semi-standardized languages with multiple implementations were the rule rather than the exception. PascalLanguage, FortranLanguage, CobolLanguage, ModulaTwo, BasicLanguage, AdaLanguage, the list goes on and on. Single-implementation OpenSource languages are a much newer phenomenon. Most of these older languages have faded from prominence because better languages became available, not because of problems associated with multiple implementations. By the way, Java is not a single-implementation language, as far as I know.

I agree that having a single implementation has benefits, but I think that you're overrating them. Such languages only develop well if the controlling entity is very energetic and very responsive to users. As for the portability of libraries, well, many libraries are highly portable among standardardized, multi-implementation languages. There are the usual problems with portability between very different platform families, like Windows and Unix, but these problems plague ''all'' languages. Multi-implementation languages benefit from competition. Pressure is put on each supplier to provide a good product, and if an implementation fails and goes away, you have others to turn to. (Granted that the latter point is less of an issue with open-sourced languages.)

I'm not sure what you meant to demonstrate by referencing that table on CLiki. It lists seven different ''open source'' Lisp implementations. (Note that CLiki generally focuses only on open-source Common Lisp implementations running on UNIX-like systems. Participants actively discourage posting much information about Windows-based and proprietary systems. There are a number of other prominent CL implementations omitted from that table.) Four out of the seven are listed as having "Good" standards compliance, for the other three no rating is given. The other information in the table has nothing whatsoever to do with code portability; it's mostly about implementation details that might matter to you for certain applications, but don't affect how you right programs.

It's not true that libraries are necessarily tied to one implementation, as you suggest. Depending on what the library is for, it might be written entirely in standards-compliant code. Many libraries that need language extensions are crafted so as to isolate the platform-specific parts, and those parts are adapted to many different implementations - just like a lot of open-source code for any language. Many libraries make use of other libraries whose ''sole purpose'' is to provide a common interface to commonly-needed, platform-specific functionality. Just like with any open source libraries, you may or may not have difficulties getting something working on your particular platform.

-- DanMuller

You are right; I have only eight years programming, 4 years as professional. And of course, I am spoiled by the newer languages that have portable and standard implementations. However, this only means that today, I have the chance to choose between good languages with a unique good implementation, or a even better (but the question is how much better) language and deal with using different compilers for different platforms or situations. And Lisp doesn't have industry support, or a major application (besides emacs and autocad) to hack in.

I put the table just to point out how many options you have to program in Lisp, and the variables you have to consider.

-- JuanPabloNunnezRojas.

I still don't understand why you categorize a choice of implementations as a problem. Pick one, use it. Several of the open-source ones are quite good, available on the common platforms, pretty good on standards-compliance, etc. If you don't like alternatives, just don't look at them.

* Dan, let's try to be a bit fair, shall we? The "too many implementations" can be a problem, it cannot be discounted so easily. Let's say somebody picks implementation and goes with it. Things that can go wrong. That implementation gets stucked (say the main contributor dies, other people have personal problems etc) - when the community is rallied behind one implementation like Python, PERL, Linux, etc the stuckness point is less likely to happen. Sure LISP is very much unlikely to go away even if 3 open source implementation die (even that is unlikely to happen). The danger is that one developer will get stucked with platform specific idiosyncrasies and then tons of effort may be required to port to the next platform. It is true that there are few and far between major LISP applications that are built from the ground up as portable across platforms. The thing is , though, when somebody programs for PERL, Python and Java, he programs for '''the''' language platform and gets as benefit a wide portability across OSes and machines. Why choice has anything to do with it? Because resources of LISP community are unlimited. Outsiders perception is that the more "choices" LISP community provides (vis-a-vis CLisp, GNU CL, CMUCL, SBCL, etc) the lesser the quality of any individual choice is, and the greater the risk incurred in making any particular choice. And we've also heard of Buridan's donkey, haven't we :)

"Lisp doesn't have industry support" is kind of vague.

* It's not vague, it is quantifiable and obvious. The mindshare that LISP has among the decision makers in software industry is abysmal to non-existent. If I as architect in charge of a project argue that we should use Python for this task, Perl for this other, PHP, etc, (never mind C#, VB, Java, C++), I expect to encounter absolutely no resistance whatsoever. The key decision makers (people in charge of money rather than in charge of technicalities ) will not even pay attention. If I say we need to program this project in LISP, or even this piece of a project in LISP, I can face any number of reactions except encouragement, and even indifference would be considered a good result. People using risk in an "industrial" environment take a serious personal risk, that any hiccups whatsoever the project incurs, it will be swiftly and promptly attributed to their choice of LISP.

The number of commercial implementations available is certainly evidence of one kind of industry support.

* Not convincing.

Some application areas use Lisp quite a bit, as I understand it, for instance advanced financial software.

* What is '''some'''? And what is quite a '''bit'''? Whatever they are in reality the perception is abysmal.

As for open-source code to hack in, it depends what kind of stuff you want to work on. There's actually quite a lot of Lisp code out there. You may be generalizing based on your personal interests.

* True.

And as for "... the variables you have to consider". Well! When you're writing code, there ''are'' variables that you have to consider - performance requirements, licensing, platforms supported, etc. If you want to program in, say, Ruby, and the one-and-only implementation of Ruby doesn't meet your needs, you're out of luck and have to switch languages. In other words, the information in that table describes a '''feature''', not a '''bug'''! Seems pretty obvious to me...

-- DanMuller

* It's not that obvious. Like I said above, an outside observer (read decision maker) can read into it that Lisp community is fractured, that it wastes unnecessary resources in maintaining all these competing platforms, that they weren't been able to rally together for a better standard LISP, etc, etc, etc.

Most of the arguments on this section are about ''perception''. "Decision makers don't think this." I have perceived this complaint before, which is, "Please market to me better." And that's an understandable wish; organizations like Gartner (the real decision makers) don't move unless something has a marketing department. Well, for one thing, this may be a function of the Association of Lisp Users, which has come out of slumber. So, if you want decision makers to be convinced that Lisp is the Right Thing before you start using it, then give the Lisp world some years. It's like the library situation - it just takes time.

* Well, would you bet me that it's strictly about perception of pointy-haired bosses and absolutely nothing else? I mean I can understand that Sun pushed Java with big marketing muscles, nothing can be reproached to LISP about this one. But how in the world relatively crappy (I mean compared feature by feature to LISP) languages like Python, Perl, PHP became very acceptable to pointy-haired bosses, and in a short amount of time nevertheless, while LISP is nowhere at the table? Sure the Python, Perl, PHP community didn't have any big competitive marketing advantage. -- CostinCozianu

** I think you can spot some reasons if you look at the context of 1992 to 1995, when the P* languages took hold.

*** Lisp was in the throes of the AI winter. Investors and the IT community were sour on Lisp.
*** There weren't any good/free implementations that ran well on commodity PCs.
**** This is a point that gets glossed over way too often in these endless discussions of why Lisp and Smalltalk aren't more widely used. Until 1994 or so, ordinary computers didn't have the horsepower to run robust implementations of Lisp and Smalltalk. C, C++, VB, and Pascal were the only viable choices, and we're still living with that legacy.
*** Implementations that did exist had poor integration with Unix and networking, where the P* languages excelled.
*** While its complex, Perl is just a souped-up hybrid of sh,awk, and sed, so it was familiar to a lot of Unix hackers in a way that Lisp wasn't.

To the contrary. They are incredibly effective and organized:
* http://www.python.org/psf/
* http://www.python.org/cgi-bin/moinmoin/PyConDC2004

Perl has O'Reilly's muscle, which strategically holds conventions to grow the Perl world (and others) in order to grow the market of O'Reilly books.

I am currently learning more about the history of Lisp's efforts. Let me note that I don't slam Python/Perl/PHP for being crappy; they're what the market wants, which is increasingly Lispish features, but not all at once. Sounds to me like good software that takes its users into account. I think we will all agree that the distance from the mainstream and Lisp is shrinking - and Lisp isn't the one trying too hard to compromise itself to bridge the gap. So I think things are proceeding as reasonably as one can expect.

* But some of the things above are excuses for real technical issues that no longer have anything to do with the perception of PHBs. If a developer chooses Python or Java or PERL he can write any TCP/IP client/server in no time and run it across major platforms: Linux, Windows, Unixes from HP, Sun, IBM, SGI, even Apple's OS-X. A damn wide range of platforms. If somebody wants to write that in Lisp, he won't even be reasonably portable across common lisp implementations on any particular platform. I mean LISP community surely cannot blame the misunderstanding of outsiders for the fact that they are not able to update a huge but obsolete standard to the point where it can compete with Python and PERL for developer mindshare. If one would bet on the future, it would be more likely that Scheme will fill these holes.

* Why would anyone think that LISP needs to compromise to reach the mainstream ? It is bloody obvious that LISP could use some serious '''improvements''' in order to reach mainstream. Eclipse/Intellij level IDEs, portable abstractions for sockets, threads, processes, and there you go: mainstream.

* ''This point is non-controversial, that Lisp will gain more users as more features are added. I mean, it's like when a manager shouts at you that X needs to be done to gain more revenue. Sure. Repeating an obvious truth won't get things done faster. The controversial point is how many people actually care whether Lisp reaches the mainstream. The Lisp community is anything but monolithic. Some vocal people obviously care, or they wouldn't say anything. But I know for a fact, having been told in person, that others prefer Lisp to be small. Personally, I don't want Lisp to be one more thing your boss or teacher forces down your throat, as Java and XML by necessity are. But if you see reasons why you don't find Lisp as useful as other tools, then do the obvious thing: Use other tools. Until Lisp becomes what you want.''

* ''Also, read this article on niche markets: http://www.wired.com/wired/archive/12.10/tail.html''

Whee-ha, too much to answer it all. Some very good points above, and interesting speculation about history. (I especially like the point about desktop horsepower, which I hadn't heard mentioned before. Sounds good, but I'm not so sure -- I used to run a version of Scheme on a crappy little Cromemco system back in 1984 or so.)

The point about an implementation being dropped is not compelling to me. If you worry about this (which may be appropriate), you use an open-source implementation. If the primary developers drop it, you just keep building it yourself. That will likely keep you going for quite a long time. That's one of the advantages of open source.

* Nice only in theory. In practice you cannot compete with the quality and speed of implementations coming from big vendors like Sun or Microsoft or big communities of developers. Yes, evaling S-Expressions is trivial, generating optimized code is a different issue.

Alternately, you could pay for a commercial version from one of the big players. Franz Inc. has been selling Lisp for a very, very long time. Using their Lisp would be a very low risk in this regard.

* I agree to this claim. Any PHB would not. So it's a very high risk to tell some PHB that the organization needs to pay Franz for supplying the language platform. This notion disappeared from their heads, long time ago. By and large it is either Microsoft or it has to be free.

There may be something to the argument on dissipation of resources -- ''maybe''. You might have trouble finding one implementation that supports all of your target platforms, for instance. But you can't so easily discount the ''benefits'' of competition, either. My current perception, for instance (and it's only a perception), is that CLisp is being driven to better standards compliance pretty hard by competition with the commercial and other open-source Lisps. (That's just a feeling I get about people's motivations from following comp.lang.lisp.)

* Standards compliance means very little in the case of CL as long as standard compliance does not ensure the portability of most common applications. Actually it would be better if LISP implementations had to support only a 50 page standard like Scheme's rather than support a very large standard that consumes development resources but offers exceedingly low value to developers in comparison to its size and to the competition.

Does anyone seriously think that competition among C++ compiler vendors was detrimental? Things progressed much faster there when Borland C++ was a credible threat to Microsoft! Anyway, the argument about dissipation of resources assumes that there are a fixed number of resources allocated to a field of endeavor; but of course there's actually a dynamic between reward (financial and otherwise) and talent attracted. The allegation that multiple implementations is harmful is far too pat, and more likely untrue than true.

* There is a fairly limited amount of core system developer that can support highly optimized implementation of any high level language. LISP is already in competition with Scheme, OCAML, Haskell, Erlang and a number of others. So on one hand you have quality of implementation and difficulty of reaching a standard. On the other hand, say someone wanted to write an open source database connectivity library for LISP, say me for example. Since I'd be depending probably on any combination of sockets,threading, FFI features, the effort to create such a useful library would be N times larger than if I did it for Java or for Python or for Erlang or whatever. That's no small hurdle to overcome.

As to "industry support", that phrase didn't translate to "widely used" in my head. If ''that'' is what the allegation was, then I admit my answers in that department were vague, but that question has been discussed elsewhere on wiki ad nauseam. There's at least enough interest to keep two major vendors going, even competing with a number of open source implementations! As for code available on the net: Frankly, it would be time-consuming to do a quantitative survey of Lisp code available on the net. There seems to be quite a bit, but related to areas that are pretty specialized or not currently fashionable. But there are also numerous interesting new projects in progress.

CommonLisp really ''does'' need some better cross-platform APIs for OS interaction. The standard is lacking in this regard. This is an issue that I'm struggling with myself right now. I didn't mean to dismiss the original author's concerns entirely; there are issues, but they're not debilitating and they can be solved. With the recent resurgence in interest, I suspect they will be over the next few years. The language has so much to offer that it's worth the struggle in the meantime.

* There are issues. That's the key phrase. That they are not debilitating, it's for sure, a brave soul fighting alone in the dark with PHBs can overcome some issues. But the thing is, for most common applications, with Python, PERL, Java , there are largely '''no issues''' whatsoever. One just write code. And that's how you get developer mindshare. Because even for developers willing to cut Lisp some slack, the thing is, Lisp doesn't help them. Sure if you are into automated theorem proving, AI, teach programming to students Lisp more than makes up for its problems. But if you just want to write some network server that connects to the database and dumps some data on a socket, or put up some fancy GUI, Lisp is more of hindrance then a help.

Some links that might of interest to the original poster:
* http://clocc.sourceforge.net/ I'm finding the quality of some parts of PORT a bit, umm, questionable. But it's a start.
**
* http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/lang/lisp/0.html
* http://opensource.franz.com/ Don't know how portable this code is, but it addresses the current "hot topics" in programming.

-- DanMuller

OK, first a personal request, from me to commenters: Please consider answering with a postscript, rather than inserted bullet points. More than one round or two rounds of answers becomes a nightmare to read or edit. Thanks.

Regarding dropped support for open source implementations: You miss my point entirely. Pick a good-quality implementation that works for you ''now''. Keep a copy of the source. If support goes away, continue using it. Make minor adjustments and bug fixes if you really, really need to, then type "make". Really, this is more feasible for Lisp than almost any other language, because the languages is eminently extensible without ever having to add "features" to the language itself.

Regarding Pointy Haired Bosses: Tired old drumbeat, eventually trotted out in its vaguely generalized form in every one of these discussions. When it comes to commercial work for hire, if you don't have enough clout to influence the technology chosen, then you simply don't, and it doesn't matter if we're discussing Lisp, Haskell, Forth, UML, VisualBasic. Use what you have to; many devoted Lispers program in C++ or Java in their day jobs. It's not an issue for these interminable debates. If Lisp ever catches on, hopefully more commercial development will use it. If it doesn't, you still stand to learn a lot from the language by using it yourself. BTW, the original author sounded mainly interested in open-source and personal work.

Regarding lack of core system developers: If you're talking about unpaid open source development, maybe. Otherwise, I reject the notion. There's a lot of talent out there that's underutilized. If someone offers to pay for development, it will come knocking. This assertion stands against yours, neither readily provable. Care to beat on it back and forth some more? Hopefully not.

Regarding the value/size ratio of the CL standard: There's some truth to this -- the pathnames system, for instance, seems unnecessarily complex when looked at ''today'' (although it made sense at the time, when there was a lot more diversity in platforms).

-- DanMuller

Just because you say "Tired old drumbeat, eventually trotted out in its vaguely generalized form in every one of these discussions", does not make it so, unless you want to argue like your good friend top. The same kind of arguments do not apply to Python and Perl and they are ultimately rooted in real technical and commercial issues with Lisp. If you think those are just "tired old drumbeat", that's fine with me, you have the right to your own opinion, but you do look disconnected from reality.

* I "look disconnected from reality"? Care to be a bit more specific in your ad hominem attacks? What did I say that wasn't realistic? Read carefully, now. I made no comments about how hard or easy it would be to convince a manager to use Lisp.

Then you threw some wild assertion claiming it is just as good as mine: "there's a lot of talent out there that's underutilized". There's no "proof" for anything over such non-mathematical issues, but we have more than enough empirical evidence, that you just refuse to see. Lisp has not advanced much as a serious platform ever since the ANSI standard was produced, whereas other languages and platforms have advanced by leaps and bounds. What lacks in the standard was not able to be supplanted by portable libraries, again for reasons which you fail to address. Sure, if somebody pays for the development of some Lisp, talent will be found. The objections are too many to enumerate, and to begin with, people already pay for the development of Lisp. But other language communities managed to: (a) thrive without any big company paying for it (b) find their own sponsors (c) focus their limited development resources into features that really matter.

With regards to the value/size ratio of the LISP standards: in current commercial world languages are divided in quite distinct categories:
* C/C++ -- for obvious reason
* .NET and Java -- also for obvious reasons
* General purpose languages that have the following features: very good implementation, portable, OS interaction, network support, db access, free.
* Niche languages and academic experiments.

With regards to the division above, the lisp standard is not just missing "some features". The problem is that for a large category of application it is missing the "minimal set of features" needed to be considered a player. Therefore it is relegated to the status of niche language for entirely justifiable reasons. Lisp just is lacking very seriously in some respects. Particular commercial Lisps may or may not cover that in a reasonable way, but then they are a commercial platform on their own, and this brings further disadvantages that makes them less competitive vis-a-vis other good programming languages. It looks like a dead end in which the Lisp community has been complacent for quite a while.

I, for one, don't really care other than to say it's a pity. On the other hand the world is full of cool programming languages. But then you have some smug lisp weenies on wiki that look down on the occasional newbie and pretend the reality to be that it is only a problem with Lisp's perception from the outside. This kind of argument simply does not hold much water.

''CrossingTheChasm is really apropos in this discussion: http://software.ericsink.com/Act_Your_Age.html''

''Here you see a common war between an EarlyAdopter and a Pragmatist. The Pragmatist rages against the EarlyAdopter for not "seeing the obvious," despite conceding that it will take time for the Pragmatist to get what he wants. (Standard Unix-like libraries, etc.) The Pragmatist doesn't understand why EarlyAdopter''''''s don't seem to care about their problems. This model predicts at some point, at least if you're a Lisp company (EarlyAdopter''''''s might not like the influx of Pragmatists), you will want to power over the gap between the two camps. Possibly losing some EarlyAdopter''''''s in the process.''

* It's way past time that Lisp be in the position to advocate to EarlyAdopter''''''s.

''To preempt the snide comment that Lisp is too venerable for EarlyAdopter''''''s, note that Microsoft-user attacks on Linux/OpenSource/FreeSoftware had similar arguments. Stallman and Raymond were demonized for smug, superior attitudes. The proliferation of distros and incompatible windowing systems were heavily ridiculed. They claimed Linux hadn't progressed beyond Unix; and Unix itself was too old and obsoleted. Linux wasn't compatible with MSWord. Smug Linux elitists shouted at newbies to RTFM for the hardest tasks. Propaganda and TheManufacturingOfConsent was spread not just by Microsoft, but much more commonly by Windows developers and users who were trained to think a certain way and profited by Microsoft technologies. We are lucky that these arguments have not quite faded away, because these arguments no doubt are very old and apply to previous technologies. Perhaps IBM and Amiga scratched their chins at the clearly inferior MS-DOS eating up marketshare like Pac-Man.''

* The problem with smug Lisp weenies is that they are not credible when they shout at newbies to RTFM, because their FM has actually nothing to say (not with regards to the important subjects mentioned above), and they haven't moved a finger to update that old and dusty manual. In comparison, even the venerable Linux community was finally able to push real multi-threading and real asynchronous I/O. The fundamental problem is about smuginess without much of a substance.

Heh, interesting analysis, and an interesting article. BTW, don't you hate the way the naysayers always ignore it when you make some interesting point and instead start complaining about something else? Now I'm going to paste in the too-lengthy reply that I was working on before the italicized commentary was added. You'll find a few personal notes in there that clearly brand me as an EarlyAdopter. :)

"... Lisp has not advanced much as a serious platform ever since the ANSI standard was produced..." Hmmm. What do you mean by "advanced"? This is what I mean by vague generalizations, which seem to be mostly what you're putting forward. I think a lot of Lisp system and library developers would disagree with some interpretations of that phrase. The categories of languages that you give don't make a lot of sense either; I'm sure you had something specific in mind with them, but I can't figure out what they're supposed to mean. The separation and dismissal of C++ is particularly puzzling.

Really, yes, there are problems with Lisp. Really, no, they're not as bad as you make them out to be. I started out by addressing three things brought up by the original poster:
* He considered having a single official implementation ''essential''. I tried to convince him that it's not. Yes, it has advantages, but so does competition. The "empirical evidence" that it's not an essential feature of a language is voluminous and stretches over years.
* There are no "great things to hack" in Lisp. Not true; but there may not be much in the areas that he cares about.
* You will "not be able to anything useful, because libraries are not part of the core". Also a fallacy, often repeated and refuted in various forms elsewhere on the wiki. The libraries are out there, pick the ones you're interested in, and an implementation that they support. Or adapt an open-source library to an implementation; it's not that much work. This is what's been done with C++, FORTRAN, and other languages.

Note that none of these issues were about popularity of the language, particularly not its popularity in commercial projects. Now, if you want to rehash that topic once again, fine.

Yes, PHBs can be an impediment to the spread of technologies.

Do you know how languages like Perl, Python, and Ruby overcome this? By being script-hacking languages. They infiltrate workplaces by being very good at gluing things together, so they get used by programmers to automate daily internal tasks, things like build and deployment processes. These applications aren't mission-critical at first, so it sneaks in below the boss's radar, or below his threshold of concern. The kinds of bosses we're talking about barely know what a build process is. (I've been there and done the sneaking, with Perl. Sure beats livin' hell out of DOS batch files ... brrrr.) These kinds of tasks are ubiquitous, and these languages excel at them. Lisp will probably never compete seriously for this, just as C++ doesn't. (Although the former is more imaginable than the latter.) Over time, they might get used for more visibly mission-critical stuff. Over time, these languages also accrue more features that might eventually make them suitable for large application development and complex algorithmic work. Maybe.

How did C++ get so widespread? It got to borrow off C's momentum, which was considerable because of its entrenchment in the OS and process control niches, which are healthy, ongoing niches. And C++ was a relatively (only relatively!) easy sell to PHBs as a "better C". (Again, been there, done that. I introduced C++ at a major networking operating system developer -- back when there was more than one of them.)

Lisp didn't have these advantages. It started from the other end of the spectrum -- a high-level language that is excellent at complex algorithmic tasks. Niches for these abilities are smaller and less ubiquitous than those for scripting languages and systems development. Lisp had some momentum from its predecessors, but you can read in various places about how the vagaries of the market place destroyed that. If you can with a straight face blame Lisp for the stumble of interest in AI (a major niche of origin), the failure to market Lisp Machines (which were damn sweet development systems that showed Lisp off as a systems development language), and other circumstances that someone else described earlier, then you can go ahead and blame Lisp without reservation for its own lack of popularity. For myself, I think there were many other factors involved in these things that had nothing to do with Lisp's merits, and if these environmental factors had been different, then there'd have been an excellent chance that you and I would both be programming with Lisp at our day jobs.

Does the standard fail to cover enough territory? Yeah, it'd be nice if it covered more. But the same can be said for C++, so it's obviously not by itself a debilitating problem. ''Empirical evidence'', no? It just so happens that a lot of the hot topics for programming right now are actually pretty low-level stuff that the one-man scripting languages are good for, and their daddies didn't have to deal with standards committees in order to add the necessary support. That is a nice advantage, but not a critical one. C++ isn't going away soon, because people fill the gaps with non-standard libraries. The same can be said for Lisp, it's just taking a bit longer because there are fewer people working on it. (As a matter of fact, there's an amazing similarity of topical scope in the C++ and Lisp standards.) But there's a lot of stuff out there already, and no Lisp naysayer on this wiki ever acknowledges that -- they all just repeat the same stuff over and over again.

-- DanMuller

Any analogy between Lisp and C++ is flawed for fundamental reasons. It is true neither the C++ standard has anything to say about threads, networks, and all the other goodies. But C++, unlike Lisp, is just one C/C++ call away from any of these. That's how you've got '''tons''' of high quality open-source libraries that are portable across C++ compilers and OS platforms. LISP insulates you from the OS, and it makes sure you have no easy access either. And that was, admittedly, a flawed design decisions taken when everybody thought Lisp machine would rule the world and they'd be your OS. In C++ you can interoperate with the OS, vis-a-vis spawning threads, opening sockets, buffering into char*, whatever you feel like it, because you're basically in the same language, with the same semantics. In LISP you just cannot do the same, and that's the fundamental language design problem from where you just do not have the same kind of portable libraries written in LISP. It can't be done without painfully fighting with the undefined semantics in the standard. There's no way somebody stands a chance to write a portable thread library for LISP, because he has to go down to C level, be mindful how he interacts with the /Lisp VM/interpreter/generated code/ with GC and all that jazz.

The only way this gap can be filled is either that a better standard arise and is implemented (nowhere in sight), or one particular LISP implementation becomes the de facto standard. 

Hoping that some independent libraries can fill the gap looks to me like very much wishful thinking, even yes, disconnected from reality. It's against all odds. You claim that a lot of "stuff" is out there already. Maybe I'm misinformed, but please show me how you respond to something as trivial as DiningPhilosophersChallenge, in portable Lisp code with whatever library you choose. Or something as trivial as a multithreaded echo network server (the protocol is you read one line, you send back the same line). You say "just adopt a library" as if there are libraries to adopt. 

-- AnonymousDonor?

Well, you picked a particularly vulnerable example. The DiningPhilosophersChallenge is a problem that requires threading to demonstrate. Even in C++, multithreading is not "just a call away". A solution to this problem would not generally be portable between different systems, so you're just committing the usual fallacy of grossly overstating the portability of code written in other languages. (Possibly through a lack of experience in system level programming?) The only way threads-based code is portable in C++ is if you use one of the very few portable libraries for this -- actually, I only know of one, a template-based system with a pair of of books out, although the name escapes me at the moment. That library is a recent phenomenon (books published w/in the last two years, I think), and by no means universally used. If you look in the guts of libraries like this, you'll find code that is heavily customized for the different platforms that it supports, which is exactly what needs to be done for Lisp.

So ''there's'' your reality.

Yes, it's harder to get at random system services in Lisp, because the language is much farther removed from the low-level technologies of the operating system. As I already mentioned, C and C++ have much closer ties to the system-level software, so this difference between the languages is not a surprise. UFFI is an excellent start at easing this problem in CommonLisp, and is becoming quite heavily used. And every major Lisp provides a means of making these calls.

To say that the standard needs to be changed to fix these problems is absurd. Is there a standard for calling Java from C/C++? No. Do people find ways to do it anyway? Lots of them, and it's done quite often. Is it nice when there's just one standard way to do something? Yes, if the standard's a good one -- emphatically no, if the standard is a bad one, which usually happens when the standardization process is broken or if standardization occurs prematurely, i.e. before existing practice has had a chance to explore the problems and alternative solutions.

-- DanMuller

There's a standard for calling Java from C/C++ and that standard is defined in JNI.h, and is a de facto standard. As for portable threads library in C++, spawning a thread is just one call away. If you are concerned with my experience in systems programming you may wonder how funny it sounds coming from somebody who thinks ACE (http://www.cs.wustl.edu/~schmidt/ACE-overview.html) is a recent phenomenon directed to somebody who used it 6 years ago, not to mention its history has more than 10 years. Not only that but the fact that that's the only think you can think of about portable systems programming library just show how disconnected you are from the world of C/C++ programming.

You can handwave all you want about your imaginary Lisp libraries. The fact is that they do not exist (which makes your previous advice "just use a library" ridiculous), and we are talking about an otherwise very mature language -- there shouldn't be any foreseeable reason that such libraries should not exist. The fact is, that if I gave you two simple function to implement:
	(defun create_thread (procedure) ...)
	(defun start_thread	(thread) ...)
You'd have absolutely no clue on how many platforms they are implementable. On most they are not, or they do not map on real threads, suffer from other problems, etc. You wouldn't begin to contemplate writing such a library (plus a minimum set of synchronization primitives) as a project. -- CostinCozianu

If you want to have a pissing match about levels of experience, give your name and we'll take it to your home page, or you take it to mine. -- DanMuller

I'd be happy if you just responded to the points, which you repeatedly failed to. On how many LISP platforms are the above two functions implementable using real threads, and even on how many you'd be able to provide some kind of multi-processing at all ? What major Lisp implementation provide no multi-processing support whatsoever ? What other implementations do not even run on Windows ? Talking about the abundance of development resources for the core platforms and the benefits of competition, yeah, right.

As with regards to experience I don't deny you may have some impressive resume (including C++) which doesn't make you qualified to speak about portable programming in C/C++. As I told you ACE goes back a long history, and if today you couldn't even think of such obvious other choices like APR, NPR, gnu threads, and a few others, you do not know a whole lot about writing portable C/C++ code.

The fact is that C/C++ code '''is''' portable. Lisp code '''is not''' portable (unless one is restricted to CL). It is rather '''ported''' (just google for some open source packages) with individual and very expensive efforts. And no matter how much you want to handwave around the issue this is a deficiency of the platform itself. The fact of the matter is, that should you have to write a non-trivial project that needs network and multi-processing, the only sane option for LISP is to choose one commercial implementation and hope for the best. Portability is currently out of the question altogether. -- CostinCozianu

* ''(The C spec does '''not''' have a thread specification, and neither did C++ at the time of this discussion. So where's your portability argument now?)''

* {Actually, C added a thread model in C11. It was done at about the same time as C++'s. I suspect that Costin was thinking about POSIX threads when he made his comment. It is, after all, widely implemented. I don't know what LISP's multithreading situation was then or is now, so I don't know if there was anything comparable to POSIX. The state of his portability argument would rest on that.}

I set out to correct some overgeneralizations. I generated some myself. You corrected them. Thanks. But I never said that CommonLisp code was portable for an application that depends on networking and multiprocessing -- you've chosen your specifics to suit your thesis. Maybe someone who knows more than I do about Lisp for these application areas will take this up. I'm tempted to say a lot more, but it wouldn't be relevant to the topic. -- DanMuller

The conclusion that should have been obvious from the beginning is that concurrency is either designed into a high level language (for example Java, Erlang. Mozart/Oz) or supplied by a particular implementation (Scheme, Python, Ocaml), but there's no way a library writer can supplant the lack of concurrency in a high level language like LISP, and a portable library is out of the question altogether. C/C++ is the only exception and it gets away with it because they are essentially in the same language runtime with the same semantics with the OS, whereas Common LISP was carefully isolated from any OS abstraction -- a design decision that turned out to be a serious mistake (probably comparable with a similar decision for Algol). These are very serious technical issues about LISP.

And to quote another lisp aficionado around here: "For many application areas, threads are essential regardless of OS -- Unix, Mac, embedded systems...I don't think I've ever worked on a really huge system that was not multithreaded, although smaller ones don't always need it.".

''Here, we see the Microsoftie attack the Linux developer for not being able to write a program which 100% portably runs on the vast majority of computers because of the distro fragmentation, Windows incompatibility, as well as various system fragmentations like the windowing systems. The fact that Unix has been around far longer than Windows leads him to argue that it is no longer possible for Unix to change or improve -- Linux is completely stuck in the mud with no way out. The Microsoft advocate is viciously angry that despite this unchangeable state of affairs, the growth of Linux is still proceeding unhindered. And despite his clear mathematical proofs that change is impossible and that Linux is not Turing-Complete, arrogant Linux advocates shrug and say, "Yup, I guess we'll have to take care of that. Nice thing about software is that things have a reasonable chance to be fixed."''

''When pointed out to the Microsoft developer that the Windows platform itself has various detailed disadvantages, he replied, "".''

''In related news, Java advocates are being admitted to hospitals in record numbers for eye damage, because on the "C2 Wiki," someone claimed that C/C++ was entirely portable, causing a condition where the victim rolls her eyes a full 360 degrees.''

''Finally, Alan Kay gave the keynote at the C/C++ User Advocacy Convention. He stated, "Neither C nor C++ support OOP, functional programming or really anything else; and you can't even change the syntax to do it. But despite those disadvantages, they remain high productivity languages where the speed of development causes people to power through these barriers. And we see the elite programmers quietly choosing C/C++ over herd languages like Ruby, Smalltalk, Python, Java, C# and Lisp.''
* C and C++ supports imperative and procedural programming along with structured programming. The fact that Alan Kay thinks C and C++ don't support much of anything, shows what little credibility the man has. He is a crank/quack/crackpot.

OK, I can't help but one more reply: Costin, you're painting a grossly exaggerated rosy picture of how easy it was to get threading available in C++. You don't get usable threading in *any* high level language "essentially for free". Significant portions of the standard library and runtime have to be adapted to deal with concurrency issues, including in particular heap management and I/O primitive synchronization. (And no, you don't get this for free by virtue of C's or C++'s use in implementing OS kernels; kernel code usually explicitly avoids these parts of the standard library and runtime, or at least that was the case for many years.) There is nothing inherent about the language that prevents similar issues from being solved in Lisp, in fact they have been solved on several individual implementations, which you keep ignoring. Stop blowing smoke, Costin, you're much too smart to be making these kind of misrepresentations. -- DanMuller

* However, virtually every platform vendor (who supplies implementations of the C/C++ standard libraries) have already done this work, and the portions of the standard libraries that cannot be made threadsafe (like strtok) without major surgery have been called out. If your using any modern Windows or Unix (including Linux and Macs), you have a threadsafe C/C++ standard library already or have one available; many platforms such as Solaris provide two different versions of the library--one for multithreaded programs and one for single-threaded programs; the latter is faster due to not needing to deal with mutual exclusion issues. (Here, threadsafe means "system calls not using the same explicit resource need not be externally synchronized").

* ''Right. You have to be mindful to link with the thread-safe runtime library. That's tough, really tough job. In other words the The reason why you get multi-threading essentially for free (inspite not being defined in the language standard) is that create_thread, CreateThread are essentially C functions to begin with. They want a pointer to a function. A pointer value in your C/C++ environment is also a pointer value to the kernel. That's why creating a new thread is just one call away. The fact of the matter is that any of the above exercises I mentioned are trivial for C/C++ beginners using either platform specific APIs, or using APR, NPR, while using ACE requires just a little bit more sophistication.''

* The areas in C/C++ which aren't standardized are thread ''management'' (creation, deletion, scheduler control, etc.) However, pthreads has become a standard throughout the Unix world, and the duopoloy of pthreads and Win32 take care of most platforms you will care about. I don't doubt that similar work can't be done in Lisp - and if any Lisp implementor ''isn't'' providing some threading mechanism, shame on them. The big issue with Lisp from where I sit is standardizing this stuff, so that movement of multithreaded applications from one implementation to another doesn't require a massive porting effort.

To respond to Dan, I never claimed there's something about LISP that makes it impossible to have real multi-threading in LISP, but he keeps distorting the real claim: there's something about LISP (or any other high level language) that makes solving this problem '''essentially inaccessible to the library writer'''. On the other hand, if you have a C++ compiler that has a thread-unsafe malloc, that's just perfectly fine, you can write your thread-safe malloc any time, or you can download an open-source malloc library. The solution to the lack of threads in Lisp is, unlike in C, accessible only to the language implementor - the same thing as in Java, OCAML, Scheme or any other high level language, except that with Lisp it just doesn't happen. Most of the Lisp implementations on most of the platforms do not have real threads, most of the LISP platforms do not have asynchronous I/O either. If concurrency was an easy thing to add to LISP we wouldn't have Erlang, Mozart/Oz and many other languages, but we have those because concurrency has to be designed in from the ground up (or at least that's the current conjecture of experienced language designers). -- cc?

"I never claimed ..." You're right, you said '''library'' writers couldn't, which I missed. This claim is correct, and as you point out, it's also correct for most languages. However, it's also true for ''standard'' C++. Staying strictly within the language standard, you'd find it impossible to reimplement malloc or many other standard library functions, and even if you could, I don't believe that the standard gives you any guarantees that you'd be able to insert your implementations as replacements -- standard library headers are given quite a bit of latitude for how they're implemented. As a practical matter, for most implementations of C++, you're correct -- although it's not terribly practical to postulate that a library writer would himself reimplement large parts of the standard library. There are also possible complications with dependencies between the standard library implementations and even less accessible language runtime support. So there's still some hand-waving here about the amount of effort that the C++ implementors had to put into the task before threading became practical and ubiquitous. But we're not as far apart as where we started, so let's not beat that dead horse.

* Actually , contrary to your new claim, it is perfectly feasible to implement malloc using strictly standard C (and maybe one platform specific call to ask the OS for more memory), and it is also easy to use that malloc as a drop-in for the allocation process in the '''new''' construct for C++ objects. Furthermore the implementation will be fairly portable. Not only it is feasible but many people have done it. It may not be practical for your average C writing dude, but even those guys can do a google and use a malloc more suitable for their needs -- ifthey feel like it. In any case, the point is moot since I am aware of no major C/C++ compiler without a thread safe library that can be just linked into the user programs.

Tight integration of memory management into the runtime definitely puts this task out of the reach of library writers, unless the runtime is accessible for modification. (This is the case, of course, for all open source implementations, and also for CormanCommonLisp.)

* Unless the complexity of runtime is so exceedingly great as to make this enterprise impractical for any conceivable library writer. I mean why call him library writer anymore ? Yeah, you can do it in theory, in practice it's just not getting done. 

I have to admit that I ''am'' surprised at the apparent state of threading support in Lisp. I started researching it in response to this thread, and immediately ran into some surprises. This is worth looking at in more detail: CommonLispThreads.

Note that we're harping on thread support in particular here. I readily concede that this is a problematic area, but despite some comments made earlier, I don't think that threads are essential for many end-user applications. People write more application code than server code, and I expect that the bulk of application code, even stuff that interacts with the network, doesn't use threads. Dismissing Lisp's portability unequivocally (quoting: "... fact is that C/C++ code '''is''' portable. Lisp code '''is not''' portable ...") seems misleading. However, these are my impressions based on my own experience. Others' perceptions may differ.

-- DanMuller

* If you write app code that interact with a network and doesn't use either threads or async I/O (neither of which is standard or available at all in LISP), you are doing something very wrong. There's great LISP code out there, even in open source masterpieces. But it's just code that deals with understood algorithmic problems. All the other code is not portable. We're harping on thread support, but you'll have problems with fork/exec as well. Maybe I need to qualify my assertion. The fact is with minimal care (google for a good library) your C/C++ code '''is''' portable (even with network, multithreading and even GUIs thrown in), while with LISP, no matter how careful you are your code will not be portable by default. Well, we can conceive that you can write portable LISP code puting an extraordinary amount of effort, but nobody did it so far. Tons of people from tiny to absolutely major projects have already done it with C/C++. What else do you need?

* Now the fact that a beginner can write all kinds of other advanced computational tricks, without being able to approach something as basic as a telnet server, will definitely put people off that otherwise might consider LISP. Lisp is not competing only with C/C++, but with Ocaml, Erlang and other cool languages as well. The guys who like C/C++, Python, PERL, Java, etc. (which together make the vast majority of the open-source movement), those are very task-oriented guys. They do not pick a language because it's cool, they pick a language because they have to get something done. And if the current state of affairs about Lisp standard and Lisp implementations will actually stand in the way of their getting that little something done, they'll pick C/C++ or Java any time over LISP. No matter how much the language design sucks. And amazingly, in spite of C/C++ or Java language suckage factor, open-source gets tons of things done in these languages.

* The Lisp communities have yet to get some things done, which puts in question your assertion that there's no problem with lack of resources devoted to oepn-source implementations. Maybe there are plenty of resources just a lack of results. Very unlikely. Given the competence of very good or even brilliant hackers working on those, the most reasonable explanation is that there's just not enough bandwidth to bring LISP open-source implementations up to par with competing platforms. 

And to put a finality to this discussion, these are not reason to hate Lisp. I love Lisp -- actually I love Scheme, of course, (SiCp and all that) and would not have considered Lisp itself for the life of me, but I was forced to grudgingly accept the LispSchemeDifferences because there's great software written in LISP. But the reality is that Lisp is not so great for lots of tasks. It's not just that outsiders have gratuitous prejudices with LISP. -- Costin

Since participating in this discussion, I've tried to do more work in Lisp involving interaction with an outside library. Based on this experience, I have soften some of my positions above. The FFIs in different implementations are frustratingly different and often incomplete in some important details. UFFI makes a point of not providing any feature that isn't available in all of its supported implementations. In particular, callbacks from C to Lisp and function calls to C through function pointers are not commonly available. This situation is quite frustrating if you wish to support multiple implementations, or if you're at a stage of a project where you wish to avoid committing to a particular implementation.

Given the basic C data type handling and the ability to call a named function in a dynamically loaded library, which seem to be widely available, it's possible to work around these problems with API-specific glue code, like that produce by SWIG for other languages. To interface with C++ you'd almost certainly want such code (to avoid delving into details of the specific C++ implementation, such as vtable structure), but for C this seems unnecessarily heavy-weight. (And sadly, SWIG doesn't really support CommonLisp yet. There's a newish module specifically for AllegroC, but it's very limited.)

The particular problem I ran into occurs while trying to interact with a COM interface on Windows. Although COM can be accessed strictly via a C interface that emulates vtables, doing so requires the ability to make calls through function pointers. As far as I can tell, AllegroCL's FFI doesn't support this directly. Another problem, which I was able to work around with a little bit of generic C glue, involved callbacks. (In AllegroCL, a C-callable Lisp function's address is subject to change due to GC, which is unacceptable for some uses of callback functions.) I am still considering my options; likely I will end up writing a bunch of glue code in C/C++.

-- DanMuller

''SWIG (SimplifiedWrapperAndInterfaceGenerator) does now have more support for LISP - see http://www.swig.org/compat.html'' 

-- JohnFletcher

----

Re Threading and IP:
I believe it is generally accepted that real threading is a hard problem better left to people who know what they're doing. Given that, it isn't such a loss to see that real threading isn't standardised. Green threads, however, should be standardised. In the meantime, libraries exist to help alleviate the problem. For example, flez (http://lisp-p.org/flez/) basically offers cooperative task switching. For many applications (such as simulating agents or serving multiple clients), it is often enough and very easy to use. AFAIK, it has only been tested it in clisp (the most portable CommonLisp implementation), but it should be rather easy to port. CLOCC-PORT has already been mentioned. With these two libraries, it should be possible to write implementation- and platform- portable networking code.

It is also interesting to see that it has been argued that Erlang, Oz, etc. had to be created because ''concurrency has to be designed from the ground up'' [rather than provided by a library]. Was it the case for C++ (obviously, it wasn't for C)?

-- AnonymousDonor

''Ergh, flez looks rather reminiscent of perl's POE. Requiring all my code to be structured into some state machine is not what I call a particularly elegant solution. If it's not as simple as coroutines in stackless python or lua, it's really not worth the effort. Oddly, while scheme requires call/cc and could therefore easily have elegant and simple coroutines, it still doesn't have any sort of standard implementation of them (but it has SRFI18, a bloat-tastic full-blown threads library).''
-- 
And I hate Lisp too, because the standard does not state how the backquote and unquote macros (functions?) should be named. Different implementations have different ways of representing the backquotes, and it's almost impossible to write a portable macros processing them. I know about set-macro-character - it won't help a lot with portability... -- Anonymous
----
@Costin: Assume a C compiler that decides to buffer intermediate values of complex calculations in static storage. Afaict such behaviour would be entirely legal, but evidently ''thread-unsafe.'' How do you portably implement a replacement for ''that?''
* You went wrong on the first word, "assume...". That assumption is flatly incorrect, so this is a strawman. Essentially you're accusing C of being an inherently thread-unsafe language in its definition, which common sense should tell you is completely absurd. It was invented for systems programming, implementing operating systems, etc. As another point of plain common sense, why would a compiler want to use static storage for intermediate values??? That's what the stack is for.
** Surprise, not all processors that support C are amenable to stuffing things on the stack without incurring HUGE performance hits.  6502 comes immediately to mind, where zero-page is used as a set of virtual CPU registers, and which is still very widely used (and is in fact growing) in the embedded device space. This isn't such a hypothetical question after all. '''OTOH''', it should be pointed out that the fact that it ''isn't'' specified in the standard enables the compiler vendor to include a command-line switch to control this precise behavior.
** ''That misses the point. For one thing, it's pretty much always a performance hit to use the stack when it's not necessary, even on e.g. a Sparc or Pentium. For another, in the general case functions are recursive, and obviously there are cases where it is plain and simply incorrect to save intermediate results to a static area. The original point was a straw man, assuming something that is in fact illegal (and unworkable) in the general case. Your comments about processors that are not C-friendly are basically a side conversation about implementing something like C that is not C for such processors. And note that when C was getting popular, say 1975 through 1985, C-unfriendly processors were extremely common. The DEC 10, for instance (and yes, the 6502, 8080, etc etc).''  However, C was never ported to these processors until the latter half of the 1980s.  Prior to that point, C was the domain of PDP-11, 680x0, and similar HLL-friendly systems. For the C-unfriendly processors, you had Forth, BASIC, or PL/* (usually PL/M).
** You said the assumption was flatly incorrect.  It's not; on a 6502 microprocessor system, zero-page is both a static area of RAM and the CPU's answer to lack of registers. A C compiler for that architecture simply ''must'' store to a static memory location if it is to cache intermediate function results. The argument isn't strawman. It's very real.
** ''So on a 6502, C can't support threads nor recursive functions, but it's still standard C, is that the conclusion?!?! The technical issues are completely obvious; the "argument" appears to be purely nitpicking phrasings.''
** You can try to change the argument, but you won't succeed with me.  The original assumption was that it stored intermediate values in static storage, thus rendering the implementation to be non-thread-safe. Any sophomore would know that recursion is still supported by just stacking the static memory prior to the recursive call. Treat the locations like you do CPU registers -- you must push them onto the stack if you want to preserve them. Unlike registers, however, static memory locations are preserved between thread switches, which gives the person who asked the question a ''valid'' question. Instead of dismissing the question out of hand on the basis of "invalid assumptions," which I've demonstrated was anything but, then you should have just answered the doggone question: The thread scheduler must take it upon itself to be aware of these static memory locations, and therefore has the opportunity to swap the values contained therein accordingly. The issue is not relevant to the C compiler itself, but rather, to the ''interface'' between the C compiler and the host OS environment.  It's as simple as that; it not only supports your position, but provides a meaningful, non-dismissive response that serves to educate, rather than insult, the reader.  I hope I was able to also answer the original poster's question too.

* (That was a rhetorical question. The answer is, compilers do not want to use static storage for intermediate values.)

On the other hand, if threading is completely inaccessible in Lisp, you can implement lightweight threads portably as a bunch of continuations call/cc'ing each other. This is entirely impossible in C. (I know it's possible. I did it in HaskellLanguage just for kicks, thereby neatly wrapping select(), the existence of which causes me to consider threading highly overrated.)
* Not "entirely impossible in C", which is another absurd idea, but rather "non-standard and non-portable in C", a very different matter. Both threads and continuations of one sort or another have been done in C. Having such things defined in a language's standard is obviously nicer by far, but that's a different issue than "impossible".
* If you think '''select''' allows one to avoid using threads altogether, then I've got a bridge to sell you. For one thing, although asynchronous behavior and threading are interrelated, and although the one can sometimes be used to replace or implement the other (Cygwin uses threads to emulate '''select''' on Windows), they are nonetheless separate topics/tools, each with their own Patterns of use.
* For another thing, '''select''' can only check file descriptors (and a small fixed maximum number of such, at that), not general events, so it is quite impossible for '''select''' to replace all uses of threads. Classic example of that: GUI event loops. The X11 events do not necessarily involve a file descriptor, it's implementation-dependent. On the systems where X11 instead uses shared memory to dispatch events, '''select''' cannot see X11 events. There are an arbitrarily large number of similar scenarios. -- DougMerritt

----

Food for thought. Is the "everything is based on a single simple concept" argument for Lisp in any way related to ReducedInstructionSetComputer versus ComplexInstructionSetComputer?

----
There is only one downside to Lisp that it spoils the programmer with its power and in ugliness it is ~= perl.
I mean if you grew up on Dynamic typing and Macros, how would you like programming in, let's say, Java or D flat?
* "D flat" = "C sharp" - I like that.
----
Moved text to LispLacksVisualCues because this topic is growing long.

''W(h(a)(t))?''
----
''For a deeper treatment, see http://www.dreamsongs.com/Separation.html.''
----
Unfortunately a Russian spy stole the last meg of a LISP program for controlling our nuclear defense systems. Fortunately, it was all right-parenthesis.

''Now you just need to write a script like this to fix it:''

 curProgram = readFile("nukeDS.lisp");
 while (! run(curProgram)) {
	curProgram = "(" + curProgram;
 }
 saveFile(curProgram, "nukeDS_fixed.lisp");
----

This entire page is a hovel of smug weenies calling other people smug weenies.

Way not to disappoint, guys.

----
See: LispSucks, SmugLispWeenie, SocialProblemsOfLisp

CategoryRant, CategoryLisp