12 ms·

The Lisp Curse

268 points by winestock 16y ago

Come on, everyone! Let's beat the dead horse one more time!

randrews 16y ago
I see his point about how everyone rolling their own thing is bad for the Lisp community, but he's got a kind of ridiculous view of C: "Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup." It really doesn't. You can have a system that uses structs with function pointers, which is how things like Glib work. You can have a compiler that adds special syntax for doing this, which all gets translated into normal C calls; this is how Objective C works. OO is just Not That Hard To Do in any language. Anyway, Lua is another great example of this curse because there's no module system or standard library to speak of, everyone rolls not only their own object system but their own list functions. The reasons are different though; Lua's design goals are to be a tiny language for embedding, so they sacrifice completeness for being really easy to customize.
- silentbicycle 16y ago
  Yeah, if you can't implement a basic object system in C, you don't really understand how OOP works anyway. Also, I definitely agree w/ you about Lua. Great language, but it's so focused on being shape-able into whatever its embedding project needs that the community refuses to settle on conventions for some things. OTOH, it's small & clean enough that running your own fork of it is actually a decent trade-off, whereas doing so with (say) Python would be pretty harsh.
  - randrews 16y ago
    I've been thinking about things I could build that would fix that, but that's sort of how we got into this in the first place. :-)
    - silentbicycle 16y ago
      Yeah. The people who are using Lua primarily in an embedded context (and thus have a lot of dependencies, such as threading & graphic libs, already chosen for them) have VERY different priorities than the people using Lua standalone. It pulls the community in two different (and occasionally opposed) directions, and the Lua team doesn't want to alienate either camp. (On the balance, though, it's still one of my favorites.)
      - randrews 16y ago
        Yes, definitely. The problem I'm running into is that the people writing the module systems are thinking in terms of running it standalone. I want a way to get a bunch of Lua libraries and cram them into one thing I can easily embed and make available to my embedded Lua interpreter. I can't really visualize how that would work though, so I can't write it yet.
        silentbicycle 16y ago
        You can compile a set of (Lua) libraries with luac, then insert the bytecode as a string literal in a C program. loadstring works on bytecode, too. With C libraries, link as usual. There are utilities floating around to reformat the luac.out file (compiler output), but all you really need to do is put static const char *lua_code = "..."; /* with the body escaped */ If you don't end a line with ;, it will be concatenated to a subsequent string literal at compile time. Oh, and multiple lua files can be compiled into one luac.out. Does that help? If you have further questions, contact info is in my profile.
        randrews 16y ago
        That's the core of what I was going to do, but I want to put on top of it something like Bundler, where I can specify which libraries I want (and which ones depend on other ones) and it will build it for me. Although I think the only one I want is Penlight, so that is probably overkill. :)
- metageek 16y ago
  >You can have a compiler that adds special syntax for doing this To be fair, C's base syntax is obtuse enough to make any extended C compiler gratuitously difficult. It wouldn't take a genius, but it would take an unreasonable amount of time and pain.
- haberman 16y ago
  I agree that basic OO is easy, but inheritance (particularly multiple inheritance), virtual functions, RTII, etc. add significant complication.
  - deleted 16y ago
    [deleted]
  - randrews 16y ago
    It's more complication in design than implementation though, and doing it in Lisp instead of C won't help that any. Once you decide what you actually want to write, it's not a whole lot harder to write it in C than Lisp. It's harder, but it's still something that anyone who can do it in Lisp would be comfortable doing in C.
- bergie 16y ago
  Lua is another great example of this curse because there's no module system or standard library to speak of I think this, instead of syntax, is the main cause of fragmentation. The more strongly a language community recommends and bundles a module system and a package manager for it, the easier it is to build an ecosystem
luu 16y ago
I’m always wary of arguments along the lines of “we weren’t successful because we were too awesome”, when there are alternative explanations. Could there possibly be any other reason? I’ve found Ruby to be very easy to extend, and one complaint I’ve heard is that it’s so easy to write DSLs that everyone has their own incompatible languages. And yet, Ruby is successful. So, how come Ruby is more marketshare than, say, SML? Could it possibly be that most people just find it easier? It implements most of the unique features of Haskell and OCaml. In some respects, Qi surpasses them. For instance, Qi's type inferencing engine is Turing complete. In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome. Seriously? Qi is nice, and “better” than Haskell and Ocaml in some respects, but it’s also inferior in many other respects. To port all of Haskell's experimental features to Qi would require teams of people. There's nothing particular to Lisp that would make that orders of magnitude easier. Haskell just has a lot of features.
- silentbicycle 16y ago
  > So, how come Ruby is more marketshare than, say, SML? How much of that still applies if you take away Rails (and all the marketshare that came from it, and all the resulting tools, etc.)? Having a killer application makes a big difference. The killer application of SML seems to be teaching, and awesome compiler research. With all due respect to SMLers, that's much less likely to interest hordes of average web developers.
  - protomyth 16y ago
    Separating a language from the things you build in it kinda misses the point of the language. Ruby inspired / allowed Rails. Sadly, Lisp and SML haven't have powered anything of similar popularity.
    - dwc 16y ago
      And I think this is what the author was saying. In Lispland you don't get something like Rails, you get a bunch of 80% solutions, all different.
gphil 16y ago
This idea kind of reminds me of the notion that ideas are cheap, and that execution and hard work are what it really takes to create a valuable company. It seems to me that the hard part of developing language features is developing the documentation and the tools, and it's this work that will drive language popularity much more than the features themselves.
systems 16y ago
lisp needs a cpan
- ohyes 16y ago
  http://www.quicklisp.org/ http://www.quicklisp.org/
  - edw 16y ago
    By Lisp, perhaps he was referring also to Scheme and Clojure. Not everyone is aware that they're Lisps, too. (Detailed rationale and citation needed.) For Scheme, nothing's ever really gotten off the ground. Little more needs to be said on the subject than "R6RS module system debacle." There are meta-module systems for Scheme. I'm waiting for the meta meta-module system. Clojure, however, has http://clojars.org/ http://clojars.org/ and lein (and cake). I've found that Clojure programmers are way more prone to look for something that exists and (perhaps mostly) fits the bill before rolling their own. I attribute this not to Clojure programmers being smarter or better human beings but to the relative ease of creating, searching, and resolving package dependencies.
    - silentbicycle 16y ago
      The Scheme community is too fragmented for a meta meta-module system to work. Racket and Chicken both have decent module repositories, at least. (Probably some others do, too.) No meaningful experience with Clojure, but it probably inherits some library culture from running on the JVM as well.
      - jshen 16y ago
        clojure has leiningen and clojars.org which are awesome
      - nickik 16y ago
        Clojure sure does. Look at something like maven. It has lots of features but alot of people don't like it. All we needed in Clojure were some people to creat good abstraction over maven and boom! we have a great package system. If you want to live on something like the JVM you have to use all its powers to the max because if you don't its weaknesses will be bigger then the its benefits you get.
TY 16y ago
Most of the essay can summarized by this quote from it: Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. While this is not a bad essay I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today. Instead, I'd love to see that mental energy spent on advocacy/defence/adulation/hatred of various Lisp dialects on actually writing great software. Let's stop looking at Lisp as a religion and instead use it as a great tool to create beautiful things. Disclaimer: I've used CL, Scheme and Clojure on my various (mostly personal) projects. For the current one, I use Python as it fits better for what I'm doing today. My next project will use whatever it needs to work.
- winestock 16y ago
  "I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today." So am I. I wrote the essay because this idea has been banging in my head for some time and I had to let it out. The urgency shows in places. Elsewhere in this thread, others are pointing out that I don't know that much C. Guilty. Another commenter's suspicion about the "we lost because we're so awesome" theme also has merit. I suppose that Lisp must have some intrinsic problems, but reading about the Lisp Machine period makes the language so enchanting.
  - lkesteloot 16y ago
    I've always suspected that Lisp is write-only. For example, it fails the squint test, which I wrote about here: http://www.teamten.com/lawrence/writings/the_language_squint_test.html http://www.teamten.com/lawrence/writings/the_language_squint... Being write-only would explain why there are so few collaborative Lisp projects. And I don't particularly buy the thesis of this essay that there are few collaborative Lisp projects because it's possible to do anything with a single person. You can always find sufficiently difficult problems that would require a team. Projects in Lisp should be putting projects in other languages to shame. I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself.
sedachv 16y ago
The Lisp Curse is all the people writing opinionated articles about the Lisp inferiority complex, instead of contributing to existing Lisp software. There are tons of incompatible, undocumented libraries for Perl, Python and C. This is no correlation to anything. The people who want to use existing libraries use them. Those who want to reinvent the wheel will do that and there is nothing you can do to stop them. Lisp Machines aren't magic. If you think GNU Emacs is "obsolete," you can work on http://common-lisp.net/project/climacs/ http://common-lisp.net/project/climacs/ or http://common-lisp.net/project/phemlock/ http://common-lisp.net/project/phemlock/ or http://mclide.in-progress.com/ http://mclide.in-progress.com/ , but don't expect anyone else to share your opinion. GNU Emacs is the best multi-language, multi-platform programming environment available today. Most people somehow manage to avoid the "Lisp Curse" and just work on improving Emacs extensions.
- agentultra 16y ago
  I wish I could up-vote you twice. Even his remarks about object orientation are just a straw man. Perl5 still doesn't have a definitive object model (well, beyond blessed hashes). Library authors have written many competing solutions over the years. Arguably this is a good thing. If someone finds a better way to do something, everyone can benefit without waiting for the Perl core developers to implement it. Contrast to Python where we have to wait for the core team to implement everything including the core libraries. I don't know why this idea of writing "Why Lisp Sucks" articles persists. Maybe it makes the authors feel smart and authoritative. I honestly don't know. Can someone fill me in please?
  - winestock 16y ago
    As I wrote in another comment, I wrote the essay because the idea had been bouncing in my mind for some time and I needed to get it down. The disconnect between Lisp's power and its lack of mind share is downright odd given what it can do and how influential it has been. I wouldn't be surprised if some old-timer on comp.lang.lisp were to relate a heart-rending tale of an inner-city high-school dropout thalidomide baby who was a pity hire at LMI in 1987 and blah blah s-expression this and blah blah Lisp macros that and blah blah his flippers could barely reach the Hyper key and blah blah he did things you people wouldn't believe but blah blah Worse is Better so blah blah... Okay, okay; I believe you. Then I would read Lisp sites that were still debunking old myths like "Lisp is an interpreted language and its only data structure is lists and it caused the AI Winter." After a while, people are going to wonder about the disconnect. There's a line in Tim Wilson's song "100 Things Every Man Needs to Know" "You been married nine time? Hell, maybe it's you."
pg 16y ago
Occam's Razor suggests that the reason there is no dialect of Lisp as popular as less expressive languages is that no one happens to have created one yet. What languages are has changed. Languages used to be specs. Now they're open source projects. Open source projects seem to succeed based more on the energy of their initial organizers than anything else. There are only a few big language-project organizers, and none of them happens to have chosen to implement a language that is a dialect of Lisp. That's the sort of thing that's true until it's false. E.g. Clojure could be the counterexample. Maybe there's more to it than a small sample size, but that seems the likeliest explanation. The second most likely explanation is almost as mundane: that the reason new dialects of Lisp have trouble attracting adherents is that mainstream programmers are put off by s-expressions.
- abstractbill 16y ago
  What languages are has changed. In fact, when it comes to choosing languages, I think things have changed even more. At justin.tv, we've chosen nearly all of the languages we use because of a particularly good library that each one has (Python, because of Twisted; Ruby because of Rails, etc). The actual features of the languages have been almost irrelevant. We would definitely jump on a Lisp dialect if it happened to have a great library we wanted to use.
  - tom_b 16y ago
    I think this is particularly insightful. What you've stated is a raw and pragmatic consideration - what is it that I want to do and what library lets me get that done the fastest? Coming from justin.tv, this insight may be more start-up perspective oriented than historical reasons for programming language choice. But I also believe that programming language choice is driven by market or behavioral forces that don't necessarily act in a rational way or lend itself to overly rational analysis.
- swannodette 16y ago
  I agree with Peter Van Roy on this - mainstream programmers tend to have an unclear picture of the relationship between syntax and semantics. This goes for both C-style and whitespace based mainstream languages. Every syntax brings along hard-wired semantics like a ball and chain. But the ball is not particularly heavy, in fact sometimes it's light enough to not be much of a bother. This actually explains quite a few things - people tend to be satisfied with whatever language they've become comfortable with (in fact they get angry if somebody actually points out the ball and chain). The few people that actually take the time to learn several dramatically different languages discover that ball and chains come in all different kinds of shapes and sizes. But I believe there is a sea change going on and Lisp will only benefit from it. That sea change is Functional Programming. Functional Programming is very much concerned with optimal semantics. The more people understand that semantics and syntax are inextricably intertwined the sooner they'll see that Lisp has been and continues to be one of the best ways to rapidly prototype and build optimal semantics. But this also means Lispers need to constantly look at other languages - the optimal semantics are constantly evolving and changing (Racket and Clojure are doing a good job of adopting better semantics). On that note, I'd like to say that you've done an incredible job at pointing out that the ball and chain is there to far more mainstream programmers than anyone else I know. Thanks for that.
coliveira 16y ago
The reason Lisp programmers don't have a fancy IDE is that they don't feel the need for it. Everyone that really understands what he's doing is using Emacs or their own thing. In a way it is similar for other languages. Why Ruby doesn't have something like Eclipse? Because it doesn't need one. Even for C/C++, the only reason why there is a Visual Studio is that there are so many entry level programmers that will buy it. Experienced C programmers feel much more comfortable using UNIX/gdb. On the other hand Smalltalk programmers have an IDE because they need it: it is just the way it works for Smalltalk.
- eropple 16y ago
  > Even for C/C++, the only reason why there is a Visual Studio is that there are so many entry level programmers that will buy it. Experienced C programmers feel much more comfortable using UNIX/gdb. That comment is insulting, impossibly overgeneralized, and counterfactual, all in one. Heck, I'd be hard-pressed not to put a gun in my mouth and pull the trigger before trying to work with gdb and anything multithreaded, and for anything more than doing an autopsy on a core dump gdb is still user-hostile and obnoxious. Visual Studio is _so_ much less of a hassle than trying to pore over obfuscatory gdb backtraces. I pay for a personal license for Visual Studio because it lets me get my work done without wasting my time. And I'm a pretty experienced developer, both on Unix and Windows (though I've moved away from C because it is a poor choice for the development I most enjoy doing).
- Peaker 16y ago
  I disagree wholeheartedly. Ruby uses runtime name resolution. When you use a name "x", it is impossible (in the general case) to figure out what the name refers to statically. Thus, in Ruby and other dynamic languages, there's much less an IDE can do. Even renaming a variable is an undecidable problem in these languages. I know plenty of experienced/talented C/C++ programmers, and most of them prefer to use IDE's despite recognizing some of the weaknesses of contemporary IDE's. I've been programming C for 15 years (of these, 10 were professionally) and I would love to use a good IDE. Unfortunately, I haven't found a good IDE yet and so I make do with emacs. But the moment I find a good IDE with usable refactoring tools while still retaining emacs-level keyboard macros and other useful features of emacs, I'll switch.
plinkplonk 16y ago
It is past midnight where I live and it has been a long day, and I am sure it is my fault, but I am having some trouble identifying the central point of the essay. Is it something like "The curse of lisp is that it is too expressive"? Genuine question. Please help.
- winestock 16y ago
  Close. The Lisp Curse is "Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp." Lisp is so powerful that an individual programmer can do a lot more than he could if he were using another programming language. This seems to encourage fragmentation and provide less encouragement for cooperation.
  - plinkplonk 16y ago
    Thank You. Now I understand what you are trying to say but am having trouble seeing the logic supporting that assertion. How is lisp so much "more powerful" than (say) Haskell (or Erlang ) to such an extent that problems which are technical issues in Haskell or Erlang are "social issues" in lisp? It seems to be that without some serious convolutions wrt "power" to fit a pre existing bias, lisp is hardly "more powerful" than Haskell ,or SML (or erlang or smalltalk or J or even Lua). Most of these lisp "power" comparisons seem to focus on easy to beat up languages like PHP or Java and not so much the better designed ones like Erlang or Haskell, which have vibrant communities and plenty of interesting software written in them. Is lisp really "more powerful" than Erlang? or Mozart/Oz? or Haskell? I suspect pg's ideas of language success depending on the energy of the main Open Source contributor + mainstream programmers aversion to S-expressions may be more accurate. Maybe all we have to do is wait a year or two and see which of Scala or Clojure dominate on the JVM. The founders of both are very talented and energetic. If you are right, Clojure should end up "more powerful" than Scala but having (relative to Scala) this "problems which are technical issues in Scala are social issues in Clojure" dynamic. I somehow don't see that happening though.
    - technomancy 16y ago
mtraven 16y ago
As someone who has programmed Lisp commercially for a long time, I have to agree with this essay. I've had much the same thoughts over the years. At one point I was one of five Lisp engineers in a 10-person company. I think we had no fewer than five hairy macros for creating complex UI layouts, because everybody wanted to do it their own way, and you could hack something like that out in an afternoon. You'd never get the same kind of phenomenon in a Java-based project, because creating something like that in Java is a major undertaking, so you'd have people settle on one that probably came from outside, and a whole ecosystem of sponsors, books and whatnot. Just very different worlds. But Lisp programmers can't reinvent the wheel all the time, so I'm very glad of things like Cliki, asdf, and Quicklisp that are promoting sharing and standardized libraries.
- winestock 16y ago
  Thank you. It's stories like this that inspired my essay. I wish that I had saved links to all of those other instances. Whenever I've read of people complaining about the dearth of code libraries for Lisp, sooner or later, some commenter points out that they would rather roll their own functionality into whatever project they're currently doing. It happens too often to be a coincidence.
  - technomancy 16y ago
    > sooner or later, some commenter points out that they would rather roll their own functionality into whatever project they're currently doing. It happens too often to be a coincidence. I suspect a lot of this has to do with the fact that it took the CL community over two decades to create QuickLisp. It boggles my mind why this wasn't created sooner--perhaps sharing libraries wasn't a high priority because the libraries tended to be spotty to begin with? So you may have had a chicken/egg problem.
- dwc 16y ago
  I would like to ask you about this: I think we had no fewer than five hairy macros for creating complex UI layouts, because everybody wanted to do it their own way, and you could hack something like that out in an afternoon. Even though I have worked in commercial environment other than Lisp (never Lisp so far), there are lots of things that can be hacked out in an afternoon. Yet having five hairy sets of duplicated functionality is something I'd never let stand for long. It seems to be a culture thing rather than a language thing. Is that right?
magice 16y ago
I think this essay is bull. As someone points out, it is yet another I-am-so-good-that-no-one-wants-me things that LISP people love to throw out. Maybe THIS attitude ("Lisp is Olympia and I, the proud user, is Zeus") is why. Let's be frank, there are many many excellent languages that do not even attract enough people to have a "community." Icon always comes to mind as example: brilliant language, excellent libraries, but the only believers are myself and a professor. Other than that, Haskell, SML, OCaml have never attracted a significant number of users. They all are brilliant, right? BASH may have more serious products than those great things. Let's face it, the true Lisp curse has not been discovered, and Lispers' attitude has helped it hide even better. I have my theories; you have yours. And mine are always more correct than yours. It's Lisp land, man. You can't argue against that.
- ebiester 16y ago
  You, a professor... and about 15-20% of anyone who came out of the University of Arizona over a decade or two. :) I remember writing a java library to do SNOBOL/Icon-style pattern matching in college because I hated the java way so much... every once in a while, I think about doing it again.
schickm 16y ago
Oh lordy...this essay effectively summarizes the entire codebase of the lisp application that I work on with a team of 6 or so other developers. I think what can work though is having an awareness of the power of the language you are working with, and then balancing the usage of that power with readability of code. You can write macros all day that save you precious typing time, but when someone else has to figure out those macros all that saved time is lost. Any language that allows the developer to define the syntax will always be troubled with this concept.
ChuckMcM 16y ago
An alternative explanation is that Lisp doesn't have a person with a strong vision, program management skills, a thick skin, a diplomatic way to saying no, and a big ass repository. The same argument is repeated throughout the essay, "Its not that Lisp doesn't have X, it has {X0,X1,..Xn)!" and that is the problem. Using lisp I get no or very low re-use for any code out there. Ergo I must write a lot of it myself. He recognizes it and laments: "Look more closely: Large numbers of the kind of people who become Lisp hackers would have to cooperate with each other." At the solution. But here is the rub, the qualities of the lisp user today are, in part, derived from how difficult it is to re-use code. People who could write anything they wanted enjoy the expressive power of lisp and tolerate the requirement to create from whole cloth basic things that should exist already. Now posit a world where there was the Lisp equivalent of CPAN, and an aggressive authoritarian requirement on documentation, coding standards, and unit testing. Once sufficient mass had built up in this repository, even dweebs who don't know the difference between arrows and monads could use Lisp to make something useful, and they would take on the false mantle of 'lisp hacker' and the population of lisp users would swell and there would be still more things checked in and poof a thriving 'lisp' community, except it wouldn't look at all like the current community.
- jleader 16y ago
  You make it sound like CPAN has "an aggressive authoritarian requirement on documentation, coding standards, and unit testing" (or at least that Lisp would need that to make a hypothetical LPAN successful). CPAN definitely does not have that. What it does have are fairly strong social pressures in favor of those things, and extensive frameworks making it easier to provide those things (I'm thinking in particular of cpantesters.org providing free cross-platform unit testing support for all of CPAN).
kleiba 16y ago
Not all professional programmers are college kids with degrees in C.S. Imperative languages are much easier to get your head around than OO-languages if you don't have a formal training. And lispy abstractions like map and first order functions are even trickier. So I thought it's natural that the more abstract a language, the more difficult it is for it to make it into the corporate world.
- stray 16y ago
  There's nothing preventing you from writing imperative code in Lisp.
  - Bootvis 16y ago
    That's true but if you want to learn Lisp (anything) well you will have to see examples, talk with peers etc. Everyone discourages too much imperative code in Lisp so this will be very hard to pick up on your own. So to be an effective Lisp-learner you will have to grok map, first order functions and what not.
- ramchip 16y ago
  Common Lisp is both imperative and object-oriented, with one of the most powerful OO systems out there (CLOS). It's a lot less oriented towards functional programming than things like Scala, Haskell, or even Clojure, which is probably more used than CL in the modern "corporate world".
shasta 16y ago
Or the explanation could be that Lisp just isn't that great. First of all, it doesn't even make much sense to talk about "Lisp" as if it's a language. The difference between the toy lisp you can write an interpreter for in a page of code and Clojure is night and day. And the other features are actually much more important than just being a Lisp. I'd be afraid to work with the "Haskell" that the smug Lisper of the article slaps out with macros. Not only would it probably not be as well designed as Haskell, unless they copied Haskell's hard work wholesale, but it wouldn't interop well with any other Lisp code. Secondly, if you actually look at the defining feature of Lisp, S-Exprs and macros, it's not a good idea. Code generating S-exprssions may be more sane than generating C code through string manipulation, but it's still a bad idea and for the same reasons. Code is a human readable format (even if you force it to be S-expressions and pretend it isn't). Code shouldn't be generating other code, it should be generating more structured values. There are composability advantages to doing so and as an added benefit, you don't get stuck with S-expressions as syntax. I predict that in the not too distant future, languages will provide a better alternative to almost every current use of macros (we're already over half way there).
- winestock 16y ago
  I think that you're the only person in this thread who openly questions the cheer-leading of Lisp. I respect that. For that, I gave you an upvote. Heretic. Sure, the pile of Lisp macros that recapitulates most of Haskell would be gnarly and nasty. But would that be due to the intrinsic bogosity of doing it through macros, or would it be due to it coming from a lone hacker who's following the scratch-an-itch school of design? Code is a human readable format (even if you force it to be S-expressions and pretend it isn't). Here's something for which there's no accounting, as the Romans used to say. Plenty of smart people love S-expressions. Plenty of smart people can't stand them. John McCarthy thought that S-expressions would go away, but no one got around to that in more than half a century. Someone must find them readable. Code shouldn't be generating other code, it should be generating more structured values. You must know more than me. Something more structured than code?
  - shasta 16y ago
ww520 16y ago
Large cooperative programs are usually written once but read many times. For large projects to succeed, the reading part needs to be optimized. Lisp being too expressive encourages the optimization in the writing part - I can write my own macros/DSL to make writing MY program easier. The readers needing to learn and understand those are their problem. This encourages people to write their own libraries instead of understand and reuse the existing ones since it's always easier to build a mental model of your own writing than the others. As noted by the others, Scala is starting to have the same problem in regarding in its ease of proliferating DSL.
- deleted 16y ago
  [deleted]
jhuni 16y ago
The beauty of Lisp is in its simplicity. Lisp has the simplest syntax in the world, and the entire language is based upon five simple primitives. All other mainstream languages complicate matters with operator precedence tables, multiple operator notations (prefix, infix, postfix, postcircumfix, etc), and many other syntactic weirdities. The simplicity of the language makes it the best language there is for collaboration. Lisp is not to blame here - the community is. A properly organized community can create standards for the use of macros to prevent their abuse and standardize on libraries to prevent fragmentation. Unfortunately, the Lisp community isn't well organized.
- winestock 16y ago
  Lisp is not to blame here - the community is. A properly organized community can create standards for the use of macros to prevent their abuse and standardize on libraries to prevent fragmentation. Unfortunately, the Lisp community isn't well organized. In other words, it's not a technical issue, it's a social issue.
- Peaker 16y ago
  Simplicity of languages can and does (in many cases) translate to complexity of programs. There are features that complicate the language and simplify programs and vice versa.
- kacper 15y ago
  Btw, how popular is Lips? Learning languages is fun, but can you get a job knowing only Lisp ?
gord 16y ago
I suspect there are similarities to : Why aren't the smartest people the richest, why dont they get laid the most? The lisp language 'microkernel' is clearly a fundamentally important construct - the essential core of all computer language. But lisp needs to interact with the surrounding ecosystem - less than genius level programmers, ugly APIs, non-mathematically perfect OO abstractions, old fashioned data stores. Its actually a lot of work to wrap that... given the impedance mismatch. Perhaps this is the same reason microkernel operating systems have won in theory but not in practice - interfacing to 'the real world'. Comparing Arc and Scheme [both of which I really enjoy] to the Javascript / node.js 'environment' ... it seems Node.js is more amenable to real work. Its a less expressive / powerful / elegant language - but via Node, Javascript melds beautifully with the async IO model of the OS and gives superb primitives for developing TCP/http services. Maybe its not the breadth of the libraries available, but the smoothness of the bridge between the language and the real world. Geeks who apply their smarts and learn something about social interaction do get laid [ to abuse my analogy ].
kaffiene 16y ago
I have another theory: look at some recent very successful and popular languages - Javascript, Ruby, Java, Visual Basic. Now, these all vary in expressiveness and 'power' but they all have something in common - they're all very simple. Simple to use, simple to use, easy to read. Could you seriously imagine the users of those languages just picking up Lisp and using it instead of those other languages? I can't. Lisp is harder to read and harder to get your head around (I've programmed in CL and Clojure, I even wrote a simple 'Lisp-lite-script' for log processing at one work place, so I LIKE the language, ok?) Being an individually more 'powerful' language is not the same as being a good language for teams of people to collaborate with. When dealing with other people, simplicity, readability are important - Java and Ruby are excellent in this regard. I also think many many people underestimate how hard it is to make a language that is simple, yet powerful. I think it's relatively easy to throw every feature under the sun into a language and get something which is 'powerful' but a nightmare to maintain or integrate with (think C++). Again, in this regard, I think both Ruby and Java did an excellent job. Of course, most of HN seems to pray at the Church of Lisp, so I'm sure your mileage might vary :o)
Tycho 16y ago
The problem with this argument that I see is that Lisp can't make everything easy - there will still be more advanced problems that take collaboration to solve. Thus while other programmers band together to make simple web servers, Lispers should in theory band together to tackle deeper problems. Which would make it more competitive than other languages, not less.

268 points by winestock 16y ago

Come on, everyone! Let's beat the dead horse one more time!

I see his point about how everyone rolling their own thing is bad for the Lisp community, but he's got a kind of ridiculous view of C: "Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup." It really doesn't. You can have a system that uses structs with function pointers, which is how things like Glib work. You can have a compiler that adds special syntax for doing this, which all gets translated into normal C calls; this is how Objective C works. OO is just Not That Hard To Do in any language. Anyway, Lua is another great example of this curse because there's no module system or standard library to speak of, everyone rolls not only their own object system but their own list functions. The reasons are different though; Lua's design goals are to be a tiny language for embedding, so they sacrifice completeness for being really easy to customize.

silentbicycle 16y ago
Yeah, if you can't implement a basic object system in C, you don't really understand how OOP works anyway. Also, I definitely agree w/ you about Lua. Great language, but it's so focused on being shape-able into whatever its embedding project needs that the community refuses to settle on conventions for some things. OTOH, it's small & clean enough that running your own fork of it is actually a decent trade-off, whereas doing so with (say) Python would be pretty harsh.
- randrews 16y ago
  I've been thinking about things I could build that would fix that, but that's sort of how we got into this in the first place. :-)
  - silentbicycle 16y ago
    Yeah. The people who are using Lua primarily in an embedded context (and thus have a lot of dependencies, such as threading & graphic libs, already chosen for them) have VERY different priorities than the people using Lua standalone. It pulls the community in two different (and occasionally opposed) directions, and the Lua team doesn't want to alienate either camp. (On the balance, though, it's still one of my favorites.)
    - randrews 16y ago
      Yes, definitely. The problem I'm running into is that the people writing the module systems are thinking in terms of running it standalone. I want a way to get a bunch of Lua libraries and cram them into one thing I can easily embed and make available to my embedded Lua interpreter. I can't really visualize how that would work though, so I can't write it yet.
      - silentbicycle 16y ago
        You can compile a set of (Lua) libraries with luac, then insert the bytecode as a string literal in a C program. loadstring works on bytecode, too. With C libraries, link as usual. There are utilities floating around to reformat the luac.out file (compiler output), but all you really need to do is put static const char *lua_code = "..."; /* with the body escaped */ If you don't end a line with ;, it will be concatenated to a subsequent string literal at compile time. Oh, and multiple lua files can be compiled into one luac.out. Does that help? If you have further questions, contact info is in my profile.
        randrews 16y ago
        That's the core of what I was going to do, but I want to put on top of it something like Bundler, where I can specify which libraries I want (and which ones depend on other ones) and it will build it for me. Although I think the only one I want is Penlight, so that is probably overkill. :)
metageek 16y ago
>You can have a compiler that adds special syntax for doing this To be fair, C's base syntax is obtuse enough to make any extended C compiler gratuitously difficult. It wouldn't take a genius, but it would take an unreasonable amount of time and pain.
haberman 16y ago
I agree that basic OO is easy, but inheritance (particularly multiple inheritance), virtual functions, RTII, etc. add significant complication.
- deleted 16y ago
  [deleted]
- randrews 16y ago
  It's more complication in design than implementation though, and doing it in Lisp instead of C won't help that any. Once you decide what you actually want to write, it's not a whole lot harder to write it in C than Lisp. It's harder, but it's still something that anyone who can do it in Lisp would be comfortable doing in C.
bergie 16y ago
Lua is another great example of this curse because there's no module system or standard library to speak of I think this, instead of syntax, is the main cause of fragmentation. The more strongly a language community recommends and bundles a module system and a package manager for it, the easier it is to build an ecosystem

luu 16y ago

I’m always wary of arguments along the lines of “we weren’t successful because we were too awesome”, when there are alternative explanations. Could there possibly be any other reason? I’ve found Ruby to be very easy to extend, and one complaint I’ve heard is that it’s so easy to write DSLs that everyone has their own incompatible languages. And yet, Ruby is successful. So, how come Ruby is more marketshare than, say, SML? Could it possibly be that most people just find it easier? It implements most of the unique features of Haskell and OCaml. In some respects, Qi surpasses them. For instance, Qi's type inferencing engine is Turing complete. In a world where teams of talented academics were needed to write Haskell, one man, Dr. Tarver wrote Qi all by his lonesome. Seriously? Qi is nice, and “better” than Haskell and Ocaml in some respects, but it’s also inferior in many other respects. To port all of Haskell's experimental features to Qi would require teams of people. There's nothing particular to Lisp that would make that orders of magnitude easier. Haskell just has a lot of features.

silentbicycle 16y ago
> So, how come Ruby is more marketshare than, say, SML? How much of that still applies if you take away Rails (and all the marketshare that came from it, and all the resulting tools, etc.)? Having a killer application makes a big difference. The killer application of SML seems to be teaching, and awesome compiler research. With all due respect to SMLers, that's much less likely to interest hordes of average web developers.
- protomyth 16y ago
  Separating a language from the things you build in it kinda misses the point of the language. Ruby inspired / allowed Rails. Sadly, Lisp and SML haven't have powered anything of similar popularity.
  - dwc 16y ago
    And I think this is what the author was saying. In Lispland you don't get something like Rails, you get a bunch of 80% solutions, all different.

gphil 16y ago

This idea kind of reminds me of the notion that ideas are cheap, and that execution and hard work are what it really takes to create a valuable company. It seems to me that the hard part of developing language features is developing the documentation and the tools, and it's this work that will drive language popularity much more than the features themselves.

systems 16y ago

lisp needs a cpan

ohyes 16y ago
http://www.quicklisp.org/ http://www.quicklisp.org/
- edw 16y ago
  By Lisp, perhaps he was referring also to Scheme and Clojure. Not everyone is aware that they're Lisps, too. (Detailed rationale and citation needed.) For Scheme, nothing's ever really gotten off the ground. Little more needs to be said on the subject than "R6RS module system debacle." There are meta-module systems for Scheme. I'm waiting for the meta meta-module system. Clojure, however, has http://clojars.org/ http://clojars.org/ and lein (and cake). I've found that Clojure programmers are way more prone to look for something that exists and (perhaps mostly) fits the bill before rolling their own. I attribute this not to Clojure programmers being smarter or better human beings but to the relative ease of creating, searching, and resolving package dependencies.
  - silentbicycle 16y ago
    The Scheme community is too fragmented for a meta meta-module system to work. Racket and Chicken both have decent module repositories, at least. (Probably some others do, too.) No meaningful experience with Clojure, but it probably inherits some library culture from running on the JVM as well.
    - jshen 16y ago
      clojure has leiningen and clojars.org which are awesome
    - nickik 16y ago
      Clojure sure does. Look at something like maven. It has lots of features but alot of people don't like it. All we needed in Clojure were some people to creat good abstraction over maven and boom! we have a great package system. If you want to live on something like the JVM you have to use all its powers to the max because if you don't its weaknesses will be bigger then the its benefits you get.

TY 16y ago

Most of the essay can summarized by this quote from it: Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. While this is not a bad essay I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today. Instead, I'd love to see that mental energy spent on advocacy/defence/adulation/hatred of various Lisp dialects on actually writing great software. Let's stop looking at Lisp as a religion and instead use it as a great tool to create beautiful things. Disclaimer: I've used CL, Scheme and Clojure on my various (mostly personal) projects. For the current one, I use Python as it fits better for what I'm doing today. My next project will use whatever it needs to work.

winestock 16y ago
"I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today." So am I. I wrote the essay because this idea has been banging in my head for some time and I had to let it out. The urgency shows in places. Elsewhere in this thread, others are pointing out that I don't know that much C. Guilty. Another commenter's suspicion about the "we lost because we're so awesome" theme also has merit. I suppose that Lisp must have some intrinsic problems, but reading about the Lisp Machine period makes the language so enchanting.
- lkesteloot 16y ago
  I've always suspected that Lisp is write-only. For example, it fails the squint test, which I wrote about here: http://www.teamten.com/lawrence/writings/the_language_squint_test.html http://www.teamten.com/lawrence/writings/the_language_squint... Being write-only would explain why there are so few collaborative Lisp projects. And I don't particularly buy the thesis of this essay that there are few collaborative Lisp projects because it's possible to do anything with a single person. You can always find sufficiently difficult problems that would require a team. Projects in Lisp should be putting projects in other languages to shame. I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself.

sedachv 16y ago

The Lisp Curse is all the people writing opinionated articles about the Lisp inferiority complex, instead of contributing to existing Lisp software. There are tons of incompatible, undocumented libraries for Perl, Python and C. This is no correlation to anything. The people who want to use existing libraries use them. Those who want to reinvent the wheel will do that and there is nothing you can do to stop them. Lisp Machines aren't magic. If you think GNU Emacs is "obsolete," you can work on http://common-lisp.net/project/climacs/ http://common-lisp.net/project/climacs/ or http://common-lisp.net/project/phemlock/ http://common-lisp.net/project/phemlock/ or http://mclide.in-progress.com/ http://mclide.in-progress.com/ , but don't expect anyone else to share your opinion. GNU Emacs is the best multi-language, multi-platform programming environment available today. Most people somehow manage to avoid the "Lisp Curse" and just work on improving Emacs extensions.

agentultra 16y ago
I wish I could up-vote you twice. Even his remarks about object orientation are just a straw man. Perl5 still doesn't have a definitive object model (well, beyond blessed hashes). Library authors have written many competing solutions over the years. Arguably this is a good thing. If someone finds a better way to do something, everyone can benefit without waiting for the Perl core developers to implement it. Contrast to Python where we have to wait for the core team to implement everything including the core libraries. I don't know why this idea of writing "Why Lisp Sucks" articles persists. Maybe it makes the authors feel smart and authoritative. I honestly don't know. Can someone fill me in please?
- winestock 16y ago
  As I wrote in another comment, I wrote the essay because the idea had been bouncing in my mind for some time and I needed to get it down. The disconnect between Lisp's power and its lack of mind share is downright odd given what it can do and how influential it has been. I wouldn't be surprised if some old-timer on comp.lang.lisp were to relate a heart-rending tale of an inner-city high-school dropout thalidomide baby who was a pity hire at LMI in 1987 and blah blah s-expression this and blah blah Lisp macros that and blah blah his flippers could barely reach the Hyper key and blah blah he did things you people wouldn't believe but blah blah Worse is Better so blah blah... Okay, okay; I believe you. Then I would read Lisp sites that were still debunking old myths like "Lisp is an interpreted language and its only data structure is lists and it caused the AI Winter." After a while, people are going to wonder about the disconnect. There's a line in Tim Wilson's song "100 Things Every Man Needs to Know" "You been married nine time? Hell, maybe it's you."

pg 16y ago

Occam's Razor suggests that the reason there is no dialect of Lisp as popular as less expressive languages is that no one happens to have created one yet. What languages are has changed. Languages used to be specs. Now they're open source projects. Open source projects seem to succeed based more on the energy of their initial organizers than anything else. There are only a few big language-project organizers, and none of them happens to have chosen to implement a language that is a dialect of Lisp. That's the sort of thing that's true until it's false. E.g. Clojure could be the counterexample. Maybe there's more to it than a small sample size, but that seems the likeliest explanation. The second most likely explanation is almost as mundane: that the reason new dialects of Lisp have trouble attracting adherents is that mainstream programmers are put off by s-expressions.

abstractbill 16y ago
What languages are has changed. In fact, when it comes to choosing languages, I think things have changed even more. At justin.tv, we've chosen nearly all of the languages we use because of a particularly good library that each one has (Python, because of Twisted; Ruby because of Rails, etc). The actual features of the languages have been almost irrelevant. We would definitely jump on a Lisp dialect if it happened to have a great library we wanted to use.
- tom_b 16y ago
  I think this is particularly insightful. What you've stated is a raw and pragmatic consideration - what is it that I want to do and what library lets me get that done the fastest? Coming from justin.tv, this insight may be more start-up perspective oriented than historical reasons for programming language choice. But I also believe that programming language choice is driven by market or behavioral forces that don't necessarily act in a rational way or lend itself to overly rational analysis.
swannodette 16y ago
I agree with Peter Van Roy on this - mainstream programmers tend to have an unclear picture of the relationship between syntax and semantics. This goes for both C-style and whitespace based mainstream languages. Every syntax brings along hard-wired semantics like a ball and chain. But the ball is not particularly heavy, in fact sometimes it's light enough to not be much of a bother. This actually explains quite a few things - people tend to be satisfied with whatever language they've become comfortable with (in fact they get angry if somebody actually points out the ball and chain). The few people that actually take the time to learn several dramatically different languages discover that ball and chains come in all different kinds of shapes and sizes. But I believe there is a sea change going on and Lisp will only benefit from it. That sea change is Functional Programming. Functional Programming is very much concerned with optimal semantics. The more people understand that semantics and syntax are inextricably intertwined the sooner they'll see that Lisp has been and continues to be one of the best ways to rapidly prototype and build optimal semantics. But this also means Lispers need to constantly look at other languages - the optimal semantics are constantly evolving and changing (Racket and Clojure are doing a good job of adopting better semantics). On that note, I'd like to say that you've done an incredible job at pointing out that the ball and chain is there to far more mainstream programmers than anyone else I know. Thanks for that.

coliveira 16y ago

The reason Lisp programmers don't have a fancy IDE is that they don't feel the need for it. Everyone that really understands what he's doing is using Emacs or their own thing. In a way it is similar for other languages. Why Ruby doesn't have something like Eclipse? Because it doesn't need one. Even for C/C++, the only reason why there is a Visual Studio is that there are so many entry level programmers that will buy it. Experienced C programmers feel much more comfortable using UNIX/gdb. On the other hand Smalltalk programmers have an IDE because they need it: it is just the way it works for Smalltalk.

eropple 16y ago
> Even for C/C++, the only reason why there is a Visual Studio is that there are so many entry level programmers that will buy it. Experienced C programmers feel much more comfortable using UNIX/gdb. That comment is insulting, impossibly overgeneralized, and counterfactual, all in one. Heck, I'd be hard-pressed not to put a gun in my mouth and pull the trigger before trying to work with gdb and anything multithreaded, and for anything more than doing an autopsy on a core dump gdb is still user-hostile and obnoxious. Visual Studio is _so_ much less of a hassle than trying to pore over obfuscatory gdb backtraces. I pay for a personal license for Visual Studio because it lets me get my work done without wasting my time. And I'm a pretty experienced developer, both on Unix and Windows (though I've moved away from C because it is a poor choice for the development I most enjoy doing).
Peaker 16y ago
I disagree wholeheartedly. Ruby uses runtime name resolution. When you use a name "x", it is impossible (in the general case) to figure out what the name refers to statically. Thus, in Ruby and other dynamic languages, there's much less an IDE can do. Even renaming a variable is an undecidable problem in these languages. I know plenty of experienced/talented C/C++ programmers, and most of them prefer to use IDE's despite recognizing some of the weaknesses of contemporary IDE's. I've been programming C for 15 years (of these, 10 were professionally) and I would love to use a good IDE. Unfortunately, I haven't found a good IDE yet and so I make do with emacs. But the moment I find a good IDE with usable refactoring tools while still retaining emacs-level keyboard macros and other useful features of emacs, I'll switch.

plinkplonk 16y ago

It is past midnight where I live and it has been a long day, and I am sure it is my fault, but I am having some trouble identifying the central point of the essay. Is it something like "The curse of lisp is that it is too expressive"? Genuine question. Please help.

winestock 16y ago
Close. The Lisp Curse is "Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp." Lisp is so powerful that an individual programmer can do a lot more than he could if he were using another programming language. This seems to encourage fragmentation and provide less encouragement for cooperation.
- plinkplonk 16y ago
  Thank You. Now I understand what you are trying to say but am having trouble seeing the logic supporting that assertion. How is lisp so much "more powerful" than (say) Haskell (or Erlang ) to such an extent that problems which are technical issues in Haskell or Erlang are "social issues" in lisp? It seems to be that without some serious convolutions wrt "power" to fit a pre existing bias, lisp is hardly "more powerful" than Haskell ,or SML (or erlang or smalltalk or J or even Lua). Most of these lisp "power" comparisons seem to focus on easy to beat up languages like PHP or Java and not so much the better designed ones like Erlang or Haskell, which have vibrant communities and plenty of interesting software written in them. Is lisp really "more powerful" than Erlang? or Mozart/Oz? or Haskell? I suspect pg's ideas of language success depending on the energy of the main Open Source contributor + mainstream programmers aversion to S-expressions may be more accurate. Maybe all we have to do is wait a year or two and see which of Scala or Clojure dominate on the JVM. The founders of both are very talented and energetic. If you are right, Clojure should end up "more powerful" than Scala but having (relative to Scala) this "problems which are technical issues in Scala are social issues in Clojure" dynamic. I somehow don't see that happening though.
  - technomancy 16y ago

mtraven 16y ago

As someone who has programmed Lisp commercially for a long time, I have to agree with this essay. I've had much the same thoughts over the years. At one point I was one of five Lisp engineers in a 10-person company. I think we had no fewer than five hairy macros for creating complex UI layouts, because everybody wanted to do it their own way, and you could hack something like that out in an afternoon. You'd never get the same kind of phenomenon in a Java-based project, because creating something like that in Java is a major undertaking, so you'd have people settle on one that probably came from outside, and a whole ecosystem of sponsors, books and whatnot. Just very different worlds. But Lisp programmers can't reinvent the wheel all the time, so I'm very glad of things like Cliki, asdf, and Quicklisp that are promoting sharing and standardized libraries.

winestock 16y ago
Thank you. It's stories like this that inspired my essay. I wish that I had saved links to all of those other instances. Whenever I've read of people complaining about the dearth of code libraries for Lisp, sooner or later, some commenter points out that they would rather roll their own functionality into whatever project they're currently doing. It happens too often to be a coincidence.
- technomancy 16y ago
  > sooner or later, some commenter points out that they would rather roll their own functionality into whatever project they're currently doing. It happens too often to be a coincidence. I suspect a lot of this has to do with the fact that it took the CL community over two decades to create QuickLisp. It boggles my mind why this wasn't created sooner--perhaps sharing libraries wasn't a high priority because the libraries tended to be spotty to begin with? So you may have had a chicken/egg problem.
dwc 16y ago
I would like to ask you about this: I think we had no fewer than five hairy macros for creating complex UI layouts, because everybody wanted to do it their own way, and you could hack something like that out in an afternoon. Even though I have worked in commercial environment other than Lisp (never Lisp so far), there are lots of things that can be hacked out in an afternoon. Yet having five hairy sets of duplicated functionality is something I'd never let stand for long. It seems to be a culture thing rather than a language thing. Is that right?

magice 16y ago

I think this essay is bull. As someone points out, it is yet another I-am-so-good-that-no-one-wants-me things that LISP people love to throw out. Maybe THIS attitude ("Lisp is Olympia and I, the proud user, is Zeus") is why. Let's be frank, there are many many excellent languages that do not even attract enough people to have a "community." Icon always comes to mind as example: brilliant language, excellent libraries, but the only believers are myself and a professor. Other than that, Haskell, SML, OCaml have never attracted a significant number of users. They all are brilliant, right? BASH may have more serious products than those great things. Let's face it, the true Lisp curse has not been discovered, and Lispers' attitude has helped it hide even better. I have my theories; you have yours. And mine are always more correct than yours. It's Lisp land, man. You can't argue against that.

ebiester 16y ago
You, a professor... and about 15-20% of anyone who came out of the University of Arizona over a decade or two. :) I remember writing a java library to do SNOBOL/Icon-style pattern matching in college because I hated the java way so much... every once in a while, I think about doing it again.

schickm 16y ago

Oh lordy...this essay effectively summarizes the entire codebase of the lisp application that I work on with a team of 6 or so other developers. I think what can work though is having an awareness of the power of the language you are working with, and then balancing the usage of that power with readability of code. You can write macros all day that save you precious typing time, but when someone else has to figure out those macros all that saved time is lost. Any language that allows the developer to define the syntax will always be troubled with this concept.

ChuckMcM 16y ago

An alternative explanation is that Lisp doesn't have a person with a strong vision, program management skills, a thick skin, a diplomatic way to saying no, and a big ass repository. The same argument is repeated throughout the essay, "Its not that Lisp doesn't have X, it has {X0,X1,..Xn)!" and that is the problem. Using lisp I get no or very low re-use for any code out there. Ergo I must write a lot of it myself. He recognizes it and laments: "Look more closely: Large numbers of the kind of people who become Lisp hackers would have to cooperate with each other." At the solution. But here is the rub, the qualities of the lisp user today are, in part, derived from how difficult it is to re-use code. People who could write anything they wanted enjoy the expressive power of lisp and tolerate the requirement to create from whole cloth basic things that should exist already. Now posit a world where there was the Lisp equivalent of CPAN, and an aggressive authoritarian requirement on documentation, coding standards, and unit testing. Once sufficient mass had built up in this repository, even dweebs who don't know the difference between arrows and monads could use Lisp to make something useful, and they would take on the false mantle of 'lisp hacker' and the population of lisp users would swell and there would be still more things checked in and poof a thriving 'lisp' community, except it wouldn't look at all like the current community.

jleader 16y ago
You make it sound like CPAN has "an aggressive authoritarian requirement on documentation, coding standards, and unit testing" (or at least that Lisp would need that to make a hypothetical LPAN successful). CPAN definitely does not have that. What it does have are fairly strong social pressures in favor of those things, and extensive frameworks making it easier to provide those things (I'm thinking in particular of cpantesters.org providing free cross-platform unit testing support for all of CPAN).

kleiba 16y ago

Not all professional programmers are college kids with degrees in C.S. Imperative languages are much easier to get your head around than OO-languages if you don't have a formal training. And lispy abstractions like map and first order functions are even trickier. So I thought it's natural that the more abstract a language, the more difficult it is for it to make it into the corporate world.

stray 16y ago
There's nothing preventing you from writing imperative code in Lisp.
- Bootvis 16y ago
  That's true but if you want to learn Lisp (anything) well you will have to see examples, talk with peers etc. Everyone discourages too much imperative code in Lisp so this will be very hard to pick up on your own. So to be an effective Lisp-learner you will have to grok map, first order functions and what not.
ramchip 16y ago
Common Lisp is both imperative and object-oriented, with one of the most powerful OO systems out there (CLOS). It's a lot less oriented towards functional programming than things like Scala, Haskell, or even Clojure, which is probably more used than CL in the modern "corporate world".

shasta 16y ago

Or the explanation could be that Lisp just isn't that great. First of all, it doesn't even make much sense to talk about "Lisp" as if it's a language. The difference between the toy lisp you can write an interpreter for in a page of code and Clojure is night and day. And the other features are actually much more important than just being a Lisp. I'd be afraid to work with the "Haskell" that the smug Lisper of the article slaps out with macros. Not only would it probably not be as well designed as Haskell, unless they copied Haskell's hard work wholesale, but it wouldn't interop well with any other Lisp code. Secondly, if you actually look at the defining feature of Lisp, S-Exprs and macros, it's not a good idea. Code generating S-exprssions may be more sane than generating C code through string manipulation, but it's still a bad idea and for the same reasons. Code is a human readable format (even if you force it to be S-expressions and pretend it isn't). Code shouldn't be generating other code, it should be generating more structured values. There are composability advantages to doing so and as an added benefit, you don't get stuck with S-expressions as syntax. I predict that in the not too distant future, languages will provide a better alternative to almost every current use of macros (we're already over half way there).

winestock 16y ago
I think that you're the only person in this thread who openly questions the cheer-leading of Lisp. I respect that. For that, I gave you an upvote. Heretic. Sure, the pile of Lisp macros that recapitulates most of Haskell would be gnarly and nasty. But would that be due to the intrinsic bogosity of doing it through macros, or would it be due to it coming from a lone hacker who's following the scratch-an-itch school of design? Code is a human readable format (even if you force it to be S-expressions and pretend it isn't). Here's something for which there's no accounting, as the Romans used to say. Plenty of smart people love S-expressions. Plenty of smart people can't stand them. John McCarthy thought that S-expressions would go away, but no one got around to that in more than half a century. Someone must find them readable. Code shouldn't be generating other code, it should be generating more structured values. You must know more than me. Something more structured than code?
- shasta 16y ago

ww520 16y ago

Large cooperative programs are usually written once but read many times. For large projects to succeed, the reading part needs to be optimized. Lisp being too expressive encourages the optimization in the writing part - I can write my own macros/DSL to make writing MY program easier. The readers needing to learn and understand those are their problem. This encourages people to write their own libraries instead of understand and reuse the existing ones since it's always easier to build a mental model of your own writing than the others. As noted by the others, Scala is starting to have the same problem in regarding in its ease of proliferating DSL.

deleted 16y ago
[deleted]

jhuni 16y ago

The beauty of Lisp is in its simplicity. Lisp has the simplest syntax in the world, and the entire language is based upon five simple primitives. All other mainstream languages complicate matters with operator precedence tables, multiple operator notations (prefix, infix, postfix, postcircumfix, etc), and many other syntactic weirdities. The simplicity of the language makes it the best language there is for collaboration. Lisp is not to blame here - the community is. A properly organized community can create standards for the use of macros to prevent their abuse and standardize on libraries to prevent fragmentation. Unfortunately, the Lisp community isn't well organized.

winestock 16y ago
Lisp is not to blame here - the community is. A properly organized community can create standards for the use of macros to prevent their abuse and standardize on libraries to prevent fragmentation. Unfortunately, the Lisp community isn't well organized. In other words, it's not a technical issue, it's a social issue.
Peaker 16y ago
Simplicity of languages can and does (in many cases) translate to complexity of programs. There are features that complicate the language and simplify programs and vice versa.
kacper 15y ago
Btw, how popular is Lips? Learning languages is fun, but can you get a job knowing only Lisp ?

gord 16y ago

I suspect there are similarities to : Why aren't the smartest people the richest, why dont they get laid the most? The lisp language 'microkernel' is clearly a fundamentally important construct - the essential core of all computer language. But lisp needs to interact with the surrounding ecosystem - less than genius level programmers, ugly APIs, non-mathematically perfect OO abstractions, old fashioned data stores. Its actually a lot of work to wrap that... given the impedance mismatch. Perhaps this is the same reason microkernel operating systems have won in theory but not in practice - interfacing to 'the real world'. Comparing Arc and Scheme [both of which I really enjoy] to the Javascript / node.js 'environment' ... it seems Node.js is more amenable to real work. Its a less expressive / powerful / elegant language - but via Node, Javascript melds beautifully with the async IO model of the OS and gives superb primitives for developing TCP/http services. Maybe its not the breadth of the libraries available, but the smoothness of the bridge between the language and the real world. Geeks who apply their smarts and learn something about social interaction do get laid [ to abuse my analogy ].

kaffiene 16y ago

I have another theory: look at some recent very successful and popular languages - Javascript, Ruby, Java, Visual Basic. Now, these all vary in expressiveness and 'power' but they all have something in common - they're all very simple. Simple to use, simple to use, easy to read. Could you seriously imagine the users of those languages just picking up Lisp and using it instead of those other languages? I can't. Lisp is harder to read and harder to get your head around (I've programmed in CL and Clojure, I even wrote a simple 'Lisp-lite-script' for log processing at one work place, so I LIKE the language, ok?) Being an individually more 'powerful' language is not the same as being a good language for teams of people to collaborate with. When dealing with other people, simplicity, readability are important - Java and Ruby are excellent in this regard. I also think many many people underestimate how hard it is to make a language that is simple, yet powerful. I think it's relatively easy to throw every feature under the sun into a language and get something which is 'powerful' but a nightmare to maintain or integrate with (think C++). Again, in this regard, I think both Ruby and Java did an excellent job. Of course, most of HN seems to pray at the Church of Lisp, so I'm sure your mileage might vary :o)

Tycho 16y ago

The problem with this argument that I see is that Lisp can't make everything easy - there will still be more advanced problems that take collaboration to solve. Thus while other programmers band together to make simple web servers, Lispers should in theory band together to tackle deeper problems. Which would make it more competitive than other languages, not less.