Why We Hate Lisp
Why We Hate LispFor 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 bodyand 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.
+/ι10In 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 ...
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:
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.)
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 SmugLispWeenies 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 SmugLispWeenies?
-- 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 SmugLispWeenies 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 SmugLispWeenies 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 "SmugLispWeenies 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 SmugLispWeenies 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 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.
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 CommonLisps 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.
[[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.
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 HigherOrderFunctions. 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?
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 GarbageCollectors 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!
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, FirstClassFunctions, Continuations, and MetaClasses 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 FirstClassFunctions(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 GrandMasterProgrammers, armed with their favorite tools, were turned loose on the problem; but they are being solved nonetheless. And given that GrandMasterProgrammers 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 GrandMasterProgrammers 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 EmbeddedSystems). GarbageCollection mainly; a decent macro system, mainly. HigherOrderFunctions and the like C++ can do a good enough job of faking; and LexicalClosures 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.
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 HigherOrderFunctions, 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 HigherOrderFunctions (or a more reasonable approximation than InnerClasses). 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 CrudScreens 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!]
[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 DomainSpecificLanguages. 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 EssExpressions into other EssExpressions, 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
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...
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":
-- top
A few disadvantages that come to mind:
Additional comments (consider correcting your text and removing this list):
There are big battles over this in other topics. It is a classic HolyWar.
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.
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.
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.
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.
-- DanMuller
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.
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.
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.
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.
With regards to the value/size ratio of the LISP standards: in current commercial world languages are divided in quite distinct categories:
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 EarlyAdopters don't seem to care about their problems. This model predicts at some point, at least if you're a Lisp company (EarlyAdopters might not like the influx of Pragmatists), you will want to power over the gap between the two camps. Possibly losing some EarlyAdopters in the process.
"... 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:
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 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.
"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.
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
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)?
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?
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?
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.
EditText of this page
(last edited October 25, 2014)
or FindPage with title or text search