7 ms·

Lisp's reputation is so bad that many people don't even take a look at Lisp

52 points by iamelgringo 18y ago

catch23 18y ago
Hopefully some of the cooler Lisp dialects like Clojure & Nu will help out a bit. The "crazy parentheses" is usually the core reason people hate lisp, but until they realize its power, it's stupid stuff that prevents them from learning it. For example, Nu is one of the coolest languages out there that allows one to do quick and dirty "scripting language" hacks in Objective-C. Due to Lisp's simple structure, Nu was able to directly map Objective-C method call signatures into something that clearly looks like basic Lisp. It allows one to code in 2 languages, but the Objective-C part of the language actually looks very similar to normal ObjC. One of the biggest benefits of Nu is that writing unit tests in ObjC is no longer painful... the whole testing structure is as simple as typical ruby unit test cases. Clojure is another one of those wonderful libraries that is a must-have for anyone doing normal java. Even basic string manipulation is extremely verbose and annoying in Java, but is probably too heavy to load a JRuby/Jython interpreter... I think that's where clojure helps fill the gap. I recently implemented an "equivalent" of a google-analytics tracker in Clojure and the final result was only around 200 lines of code (with a little bit of java here and there). It's quite nice to use clojure as a glue-language to make all your java libraries work together with little clutter as possible.
- SwellJoe 18y ago
  The "crazy parentheses" is usually the core reason people hate lisp I very strongly suspect that the "crazy parentheses" is not actually why most people who hate Lisp hate Lisp. Crazy parentheses are nowhere near the top of my list of reasons, anyway. And, blaming parentheses is the same as complaining about the sigils in Perl or the significant white space in Python; it's just not a very intelligent argument, and can probably safely be dismissed as merely uninformed. Sure, you like what you're accustomed to, but you can become accustomed to different syntax quite easily...one or two weeks is all it took for me to switch from Perl to Python, and then back again a few years later. A syntactic difference is just a very simple concept to latch on to; both for those who hate Lisp (for whatever reason) and those who want to explain away the people who hate Lisp (without having to address the real, but complicated, problems). There are a lot of very good reasons to hate Lisp, but they take more than one or two sentences to explain, and most folks just aren't going to invest that much effort in talking about something they just don't have that much interest in. The linked article does mention a few of the very good reasons to hate lisp, and leaves out a couple that I think are possibly even more important: - Lisp has a community that is generally hostile to newbies and outsiders (mentioning other languages, in particular, seems to be a big source of trouble). Contrast this with just about any other modern dynamic language community. Friendliness is practically religion in the Perl, Python, and Ruby communities (though I think only Perl has a formal religious institution for the purpose at perlmonks.org ). - A community that has a deeply ingrained culture of NIH. There are dozens of incompatible Lisps, with dozens of incompatible libraries for all sorts of tasks. I've found Lisp to be the most difficult language with which to produce useful software as a beginner of any dynamic language I've tried. Not because Lisp is inferior to Perl, Python, Ruby, etc. but because I found it impossible to find any combination of components that made it possible for me to produce useful software without running into bugs or incompatibilities that my weak knowledge couldn't overcome. Even if Lisp allows for code that's half or a quarter the size of any other dynamic language (which seems an unlikely compression), the sheer volume of excellent libraries in Perl/Python/Ruby means I can write a tenth the code, making those languages a win even if the total line count, including libraries, is higher. I've been told (grouchily, in keeping with the smug Lisp weenie tradition) that tons of great libraries exist for Lisp. Despite this assertion, I've never been able to build even a toy (but useful) project in Lisp.
  - davidw 18y ago
    A few additions: * The parenthesis do require that you have at least a moderately capable editor to navigate them effectively. You can start coding things like PHP, Perl, Ruby, Python, etc... with a pretty crappy editor and do ok. * NIH - bingo! Lisp has always struck me as being very insular, with a very strong 'turtles all the way down' mentality. "It would really be best if the OS were written in Lisp too...", whereas the "scripting" languages are very promiscuous in terms of what they will interact with and run on. This has led them to focus on doing what they are good at, and calling out to C or other languages for what they are not so good at, which is ultimately more productive than rewriting existing systems just so that they'll be 100% in your language of choice. (Yes, sure, not everyone in the Lisp world is like that, but I get that general feeling).
    - chandler 18y ago
      >> The parenthesis do require that you have at least a moderately capable editor to navigate them effectively. I disagree, with a caveat--writing code using a terrible editor requires knowledge of the indentation rules for the language, regardless of whether that language is a lisp, Perl, Ruby, etc. However (the caveat), although the indentation rules for Perl, C, Python are relatively simple (indent after a '{' or ':', line up arguments), each function/macro in a lisp can have different indenting rules (e.g. in CL compare `let' to `multiple-value-bind' to functions, to lists, to the various `with-*' macros, etc). Once you know the library for a specific implementation, the indentation rules become more obvious; at this point, using (e.g.) Notepad isn't particularly terrible (until that knowledge is acquired, though, yikes).
      - davidw 18y ago
        Notepad is exactly what I'm talking about. With Perl, C, and Ruby, at least, there really aren't any indentation rules - your program will work fine even if you don't put any in at all, or do a hacky job of it. With Lisp, especially when modifying someone else's code you're stuck counting parens. Oh, also a weird (maybe crackpot?:-) theory of mine: parenthesis, graphically, don't form a nice, rigid vertical line, but sort of point diagonally, possibly making it just that much harder to see how they line up. In any case, 4 or 8 space indented C/Tcl/Ruby/whatever code is certainly more obvious to the eye.
patio11 18y ago
The problem is, someone with these preconceptions often doesn't even look for our replies! How's about conceptualizing the problem less as "People don't come to the light about how Lisp is not as problematic as they think it is" and more as "We need to explain better how people's lives are going to improve if they learn and use Lisp". (I know, I know, I may have just committed the sin of marketing. Please forgive me.) I do not have a Lisp-sized hole in my life right now.
- silentbicycle 18y ago
  I think ensuring first that peoples' lives would be helped if they learn and use Lisp is important, too. Some people take this for granted (and can come off as incredibly condescending, PS), but I'm not so sure anymore. I know (and really like) Scheme, but the balkanized Scheme ecosystem can be very confusing to curious onlookers, and can make finding one implementation with all the libraries relevant to a project difficult. There's the tiny core language, then there's a bunch of SRFIs that implementations choose whether to support, and implementations are all over the place as far as quality, libraries, and portability. (I eventually settled on Chicken.) I learned some Common Lisp, but ran into so many portability and library problems, for stuff that would be trivial in Python, that I ultimately gave up on it. In retrospect, Scheme is a much better fit for my taste, anyway. For a while, Python was my default language for real work. (Lately, I've switched to Lua. They're quite similar, though Lua has incorporated more of Scheme's good ideas, has more of its own, and has a much cleaner design, IMHO.) While neither has macros, they have a collection of libraries, an active community, an obvious standard implementation, great support for interactive development, a decent syntax, etc. Macros aren't everything, and SwellJoe's comment about NIH (http://news.ycombinator.com/item?id=550634 http://news.ycombinator.com/item?id=550634) is absolutely correct. (Lua's design, in particular, assumes from the start that it will be embedded in something else. It's very simple to use it with other languages and their libraries.) While I don't know Ruby (Python & Lua already fill that niche for me), I'd expect Ruby programmers find similar productivity there.
  - anonymousDan 18y ago
    I wonder how much this balkanization is a result of the syntactic extension capabilities of lispish languages? The fact that you can implement changes to the language in the language makes it easier to improve it in terms of coming up with new features/patterns etc. However this can be a double edged sword when you need to then train large numbers of programmers in order to create libraries etc. for the new language. Or maybe its not that the splintering occurs directly because of the language. Instead it might occur indirectly due to lisp programmers, having been exposed to the idea of language extension through lisp, become more prone to creating a whole new language when the one they have doesn't suit their needs precisely?
pc 18y ago
This reads like a Chinese government strategy document: "the world thinks we suck. How do we convince everyone we're vibrant and fun-loving?" I've been a Lisp hacker for years -- Symbolics Lisp Machine in my bedroom, coded in at least a half dozen different Lisp dialects -- but I ended up using Smalltalk for my startup. Treating Lisp's "rehabilitation" as a mere branding exercise shows just how screwed the Lisp community still is, and is symptomatic of the underlying issue. (By "Lisp", I mostly refer to Common Lisp.) Lisp's problem is a meta-problem. The community is actively resistant to advancement, change, and evolution in the language. Attempts to modify (or even clarify) aspects of the Common Lisp standard are tedious exercises in futility, but the standardisation straitjacket is still seen as a good thing. A bit strangely, this resistance to change existing standards is accompanied by a slowness to standardise (even informally) anything that isn't already. The end result is that there's still no reliably portable way to write networking code in CL. And this is why Lisp is unpopular. The stasis is sad and ironic, given Lisp's hackerdom beginnings. Rather than wonder why, in 2009, so few are using Lisp, we should be amazed that the language is still pretty cool two decades after the innovation stopped. I hope the Clojure guys change things. They seem to have the right approach. Footnote: I was going to be a member of the CLRFI group (roughly equivalent to PEP or SRFI) that got some interest at ILC 2005, and which was going to try to create some sort of forward momentum in the community. It frizzled out, of course, and now http://clrfi.alu.org/ http://clrfi.alu.org/ appears to redirect to the ALU homepage.
- miked 18y ago
  >> I ended up using Smalltalk for my startup. I'm getting ready to start a new project with a significant GUI forms component. I wanted to go with Clojure, but it still seems a little rough around the edges. So I'm leaning towards Visualworks Smalltalk, in part because it seems like a great language to prototype in and partly because the OOP aspect fits so well with GUIs. I'm curious: did you consider Clojure? Would you mind elaborating on why you went with Smalltalk? given the number of Lispers on this site, the answer might be of broad interest.
  - plinkplonk 18y ago
    "Visualworks Smalltalk," Doesn't VW have a "pay us x % of your revenue forever" license (http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=var http://www.cincomsmalltalk.com/userblogs/cincom/blogView?con...)? I am curious as to why any startup would want to accept these terms.
lsb 18y ago
I went to see if there was anything like ActiveRecord for Lisp, because, well, that's a pretty metaprogramming-heavy domain. What do I get as the first google hit? A forum post asking about that, http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006-04/msg00735.html http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006... --- never a good sign. Two people answered, one with a link to his rant on comp.lang.lisp, and one talking about the virtues of CLSQL. The code snippet from CLSQL looks horrendous: ;; select the user with ID 1 and set his username column to joe (let ((user (first (select 'user :where [= [id] 1] :flatp t :refresh t)))) (setf (username user) "joe") (update-records-from-instance user)) Compare this to User.find(1).update_attribute(:username, "joe") 16 tokens vs 45. I don't know CLOS, but (update-attribute (find *User* 1) 'username "joe") is a great start.
- antiismist 18y ago
  I've been using leftparen (a framework written in PLT Scheme) for a project, this would be something like: (rec-set-prop! userid 'username "joe") (store-rec! userid)
- pivo 18y ago
  I found Elephant really nice to use with Lisp. It can use a SQL db as a data store, but uses it just for key/value mappings, so you can't use normal SQL commands as you might expect. I found the code to be very concise. http://common-lisp.net/project/elephant/ http://common-lisp.net/project/elephant/
jobeirne 18y ago
In response to the parting question from the article, here's an idea: make cool things with Lisp. Make cool things for Lisp.
- jcl 18y ago
  That seems to be how Erlang has achieved its recent popularity... some big successes in telecommunications systems and ejabberd.
tetha 18y ago
I belong to those people who tried to get into lisp and gave up, because the confusion to navigate per potential advantage over my major language (python) was too large. My background is a knowledge in C, Python and Java, using Python mostly. I mostly looked into lisp, because I kept encountering something I call the syntactic barrier when I tried to remove duplication from my code, and I knew: lisp had macros. Macros could break this barrier. So looking into lisp looked promising. I didn't care too much about the syntax, a good editor fixes this without a problem and it was a good opportunity to look into emacs a bit (usually, I use vim). Surfing through the chapters of practical common lisp when pretty well and understanding was not exactly hard. However after that, I was faced with confusion. There is a boatload of lisp dialects, each with a boatload of implementations and each implementation as another boatload of libraries that do something looking similar to what other implementations libraries do without being the same or compatible. How am I supposed to select any of these without having a clue? After a few days of back and forth, I decided to close the book lisp for me, because I could not find a way through this wall of selections -- at least not without investing a lot of time. Too much time for too little benefit over python. HTH, Tetha
- 10ren 18y ago
  Some people (like esr) say the main benefit of lisp is not to use it, but to use the insights it gives into how to think about code. It may be that you already have that.
  - silentbicycle 18y ago
    I agree, but if a language doesn't teach you things you can use outside of it, that's a really bad sign. This is in no way unique to Lisp. (I've been meaning to write about things I've learned from the dozen or so languages I've at least dabbled in, but haven't had the time.)
sbt 18y ago
I've been programming in Common Lisp for about a year and I consider myself an intermediate beginner. Someone made a terrific comment in response to Ron Garret's post earlier: the way you get productive in today's environment is primarily through libraries. Thus the situation is inescapable. You need tons of libraries to be productive. You need tons of programmers to write these libraries. You need an easy learning curve and appealing features to get these programmers. The bottom line is that you need the bad coders as well. As a beginner, I can safely say that it took a while before I finally got reasonably productive in Lisp. I still consider it 'the best' programming language. But the learning curve is much steeper than Python. Lisp will get nowhere without all the bad programmers. This may sound cynical, but the reason is that academically minded programmers won't spend time writing things like a download library for youtube videos, which many people find useful. These programmers are now all over Python. So why is Lisp difficult to learn? The most severe in my opinion is assignment. People find it intuitive to make temporary variables and store intermediate results in these. This is done by 'let' in CL, but if the previous style of programming is assumed, 'let' is clumsy and inconvenient to use. Another achilles heal I would like to mention is the lack of an editor with propper auto-completion. Yes, slime does this, but using emacs is too geeky for many programmers (remember you need these people) and this creates an additional stumbling block. Yet another problem is the CL websites. Remember that many people are in a hurry. The Python website is ripe with snippets that lets you do stuff fast without understanding much. In contrst, CL gives you some of the most monotone autogenerated documentation sites I've ever seen. Again, fine for people who already know Lisp, tedious for people that want to try stuff out as beginners. Faced with these realities I don't blame anyone who just want to get things done and run with Python. Unfortunately.
- jimbokun 18y ago
  "The most severe in my opinion is assignment." Clojure solves this problem by going all the way to the opposite extreme. "No assignment for you." Clojure data structures are immutable, and if you really want to do assignment, you need to explicitly use a ref/var/atom, which means you are going to figure out a way to write your program without assignment if at all possible. Clojure, of course, is designed around functional programming that has many idioms to make assignment-less programming the natural way to do things. I guess what this means is that Clojure can appeal to Python/Ruby/Perl hackers wanting to learn a different way to think about programming.
praptak 18y ago
My suggestion for anyone wanting to make Lisp popular: make a Lisp analogue of Mark Pilgrim's "Dive Into Python". Or at least consider whether it is possible to write such a book for Lisp in its current state.
- halo 18y ago
  Isn't that Peter Seibel's "Practical Common Lisp"?
  - sbt 18y ago
    Pretty much. PCL is a great book that did much to bring the O'Reilly flavor to the community. Another good contribution is the Common Lisp Cookbook website, that contains snippets for common tasks. Sadly, this doesn't seem to have struck the heart of the problem (although Lisp-in-a-box that came with PCL seems to have done it for some people). Think about why Java is so widely used. I would argue that it's because of one thing: portable packages.
- access_denied 18y ago
  The elisp tutorial that comes with Emacs is pretty well written - fluid style, usage of real language features.
jcromartie 18y ago
Can someone explain the "it's only for AI" objection that people bring up? I have heard it from a few people first-hand and they couldn't say much else about it. Is it like "Macs are just good for graphics?"
- silentbicycle 18y ago
  Some people (apparently) assume Ruby is only for the web; they're confusing it and Rails. Lisp was closely associated with AI a few decades ago.
pavelludiq 18y ago
Before i learned scheme(I don't know CL), i didn't know how to write python. I knew how to write python syntax, but had no idea how to write code that doesn't suck. I still write bad code, but at least i know when its bad and i need to change it. Scheme thought me how to spot ugly code. I still use for and while loops(recursion is expensive in python, and you shouldn't write scheme in python) but i learned to write small and simple functions and combine them in smart ways(list comprehensions, maps, filters, decorators...). I guess i knew that from reading about the unix philosophy, but it took me to see it in code to understand it. So learning scheme might help you to be a better programmer, or it might screw you up and you end up writing stuff like this http://www.pick.ucam.org/~ptc24/yvfc.html http://www.pick.ucam.org/~ptc24/yvfc.html p.s. I've never written anything longer than a textbook exercise in scheme, so i don't know if you can actually write real stuff in this(or how hard it is) but playing with it is really fun, you should to it just for that.
blue1 18y ago
I absolutely love Common Lisp, but it has some problematic areas, which are not the classical stupid ones you sometimes still hear from clueless people (such as "lots of parentheses", "lisp is slow", "lisp is for AI only" etc.). I won't even say that libraries are a real problem. Sure there is no CPAN, but still there are a lot of very good CL libraries around, and they are not really hard to install. But: 1. The language is sophisticated. This is a "problem", in the sense that such a language takes time to study. It will never be popular. The Condition system and CLOS, for example, are way more complex and versatile than, say, the equivalent areas of Java. And then there are macros. Common Lisp has not been designed as a mainstream language for mainstream programmers. It is, I fear, an elite tool. 2. Certain kind of operations are inconvenient. Maybe when CL was designed, sockets, multithreading, text processing etc were not so popular. But now, it feels like CL has not really adapted well to the modern world. Having to install a compatibility library for using sockets is reminiscent of things like "trumpet winsock". Does not feel very cutting edge. 3. The literature is lacking. "Practical Common Lisp" is very good, but one book is not enough. For example, what are the best practices to organize large CL programs? No book tells it (maybe some obscure out-of-print text that I have not yet tracked?). What about programming idioms, or patterns as you prefer? Apart from an ancient presentation by peter norvig, nothing exist. And so on. 4. The ANSI standard is a big blessing and a big curse. It is a well-written and smart opus. But nowadays no one has the resources for a new standard; both in terms of money and focus. This means that ANSI CL seems an ancient pinnacle of beauty which will never be equalled and certainly can not be improved. (the perfection of ancient architecture, as seen by renaissance architects, comes to mind). This makes CL a splendid but dying civilization. 5. I have a feeling that the community is slowly dying as well. While in recent years many CL sites and blogs have appeared, comp.lang.lisp has lost many important contributors. Nor I can really blame them: while still a wonderful language, CL is nonetheless petrified, and I suppose one may became slightly bored after a decade or two of discussing the finer points of the Standard.
- sandGorgon 18y ago
  You're dead-on about the lack of literature. I am no lisp expert (python stole me away), but something like the PythonChallenge for lisp could go a long way towards building a working knowledge. I really wish we could have books like Norvig's PAIP in the public domain - it is really one of the best books on lisp ever, however very expensive - more so in third world countries. Oh and I really wish that brackets were used rather than parantheses - there is RSI you know!

52 points by iamelgringo 18y ago

Hopefully some of the cooler Lisp dialects like Clojure & Nu will help out a bit. The "crazy parentheses" is usually the core reason people hate lisp, but until they realize its power, it's stupid stuff that prevents them from learning it. For example, Nu is one of the coolest languages out there that allows one to do quick and dirty "scripting language" hacks in Objective-C. Due to Lisp's simple structure, Nu was able to directly map Objective-C method call signatures into something that clearly looks like basic Lisp. It allows one to code in 2 languages, but the Objective-C part of the language actually looks very similar to normal ObjC. One of the biggest benefits of Nu is that writing unit tests in ObjC is no longer painful... the whole testing structure is as simple as typical ruby unit test cases. Clojure is another one of those wonderful libraries that is a must-have for anyone doing normal java. Even basic string manipulation is extremely verbose and annoying in Java, but is probably too heavy to load a JRuby/Jython interpreter... I think that's where clojure helps fill the gap. I recently implemented an "equivalent" of a google-analytics tracker in Clojure and the final result was only around 200 lines of code (with a little bit of java here and there). It's quite nice to use clojure as a glue-language to make all your java libraries work together with little clutter as possible.

SwellJoe 18y ago
The "crazy parentheses" is usually the core reason people hate lisp I very strongly suspect that the "crazy parentheses" is not actually why most people who hate Lisp hate Lisp. Crazy parentheses are nowhere near the top of my list of reasons, anyway. And, blaming parentheses is the same as complaining about the sigils in Perl or the significant white space in Python; it's just not a very intelligent argument, and can probably safely be dismissed as merely uninformed. Sure, you like what you're accustomed to, but you can become accustomed to different syntax quite easily...one or two weeks is all it took for me to switch from Perl to Python, and then back again a few years later. A syntactic difference is just a very simple concept to latch on to; both for those who hate Lisp (for whatever reason) and those who want to explain away the people who hate Lisp (without having to address the real, but complicated, problems). There are a lot of very good reasons to hate Lisp, but they take more than one or two sentences to explain, and most folks just aren't going to invest that much effort in talking about something they just don't have that much interest in. The linked article does mention a few of the very good reasons to hate lisp, and leaves out a couple that I think are possibly even more important: - Lisp has a community that is generally hostile to newbies and outsiders (mentioning other languages, in particular, seems to be a big source of trouble). Contrast this with just about any other modern dynamic language community. Friendliness is practically religion in the Perl, Python, and Ruby communities (though I think only Perl has a formal religious institution for the purpose at perlmonks.org ). - A community that has a deeply ingrained culture of NIH. There are dozens of incompatible Lisps, with dozens of incompatible libraries for all sorts of tasks. I've found Lisp to be the most difficult language with which to produce useful software as a beginner of any dynamic language I've tried. Not because Lisp is inferior to Perl, Python, Ruby, etc. but because I found it impossible to find any combination of components that made it possible for me to produce useful software without running into bugs or incompatibilities that my weak knowledge couldn't overcome. Even if Lisp allows for code that's half or a quarter the size of any other dynamic language (which seems an unlikely compression), the sheer volume of excellent libraries in Perl/Python/Ruby means I can write a tenth the code, making those languages a win even if the total line count, including libraries, is higher. I've been told (grouchily, in keeping with the smug Lisp weenie tradition) that tons of great libraries exist for Lisp. Despite this assertion, I've never been able to build even a toy (but useful) project in Lisp.
- davidw 18y ago
  A few additions: * The parenthesis do require that you have at least a moderately capable editor to navigate them effectively. You can start coding things like PHP, Perl, Ruby, Python, etc... with a pretty crappy editor and do ok. * NIH - bingo! Lisp has always struck me as being very insular, with a very strong 'turtles all the way down' mentality. "It would really be best if the OS were written in Lisp too...", whereas the "scripting" languages are very promiscuous in terms of what they will interact with and run on. This has led them to focus on doing what they are good at, and calling out to C or other languages for what they are not so good at, which is ultimately more productive than rewriting existing systems just so that they'll be 100% in your language of choice. (Yes, sure, not everyone in the Lisp world is like that, but I get that general feeling).
  - chandler 18y ago
    >> The parenthesis do require that you have at least a moderately capable editor to navigate them effectively. I disagree, with a caveat--writing code using a terrible editor requires knowledge of the indentation rules for the language, regardless of whether that language is a lisp, Perl, Ruby, etc. However (the caveat), although the indentation rules for Perl, C, Python are relatively simple (indent after a '{' or ':', line up arguments), each function/macro in a lisp can have different indenting rules (e.g. in CL compare `let' to `multiple-value-bind' to functions, to lists, to the various `with-*' macros, etc). Once you know the library for a specific implementation, the indentation rules become more obvious; at this point, using (e.g.) Notepad isn't particularly terrible (until that knowledge is acquired, though, yikes).
    - davidw 18y ago
      Notepad is exactly what I'm talking about. With Perl, C, and Ruby, at least, there really aren't any indentation rules - your program will work fine even if you don't put any in at all, or do a hacky job of it. With Lisp, especially when modifying someone else's code you're stuck counting parens. Oh, also a weird (maybe crackpot?:-) theory of mine: parenthesis, graphically, don't form a nice, rigid vertical line, but sort of point diagonally, possibly making it just that much harder to see how they line up. In any case, 4 or 8 space indented C/Tcl/Ruby/whatever code is certainly more obvious to the eye.

patio11 18y ago

The problem is, someone with these preconceptions often doesn't even look for our replies! How's about conceptualizing the problem less as "People don't come to the light about how Lisp is not as problematic as they think it is" and more as "We need to explain better how people's lives are going to improve if they learn and use Lisp". (I know, I know, I may have just committed the sin of marketing. Please forgive me.) I do not have a Lisp-sized hole in my life right now.

silentbicycle 18y ago
I think ensuring first that peoples' lives would be helped if they learn and use Lisp is important, too. Some people take this for granted (and can come off as incredibly condescending, PS), but I'm not so sure anymore. I know (and really like) Scheme, but the balkanized Scheme ecosystem can be very confusing to curious onlookers, and can make finding one implementation with all the libraries relevant to a project difficult. There's the tiny core language, then there's a bunch of SRFIs that implementations choose whether to support, and implementations are all over the place as far as quality, libraries, and portability. (I eventually settled on Chicken.) I learned some Common Lisp, but ran into so many portability and library problems, for stuff that would be trivial in Python, that I ultimately gave up on it. In retrospect, Scheme is a much better fit for my taste, anyway. For a while, Python was my default language for real work. (Lately, I've switched to Lua. They're quite similar, though Lua has incorporated more of Scheme's good ideas, has more of its own, and has a much cleaner design, IMHO.) While neither has macros, they have a collection of libraries, an active community, an obvious standard implementation, great support for interactive development, a decent syntax, etc. Macros aren't everything, and SwellJoe's comment about NIH (http://news.ycombinator.com/item?id=550634 http://news.ycombinator.com/item?id=550634) is absolutely correct. (Lua's design, in particular, assumes from the start that it will be embedded in something else. It's very simple to use it with other languages and their libraries.) While I don't know Ruby (Python & Lua already fill that niche for me), I'd expect Ruby programmers find similar productivity there.
- anonymousDan 18y ago
  I wonder how much this balkanization is a result of the syntactic extension capabilities of lispish languages? The fact that you can implement changes to the language in the language makes it easier to improve it in terms of coming up with new features/patterns etc. However this can be a double edged sword when you need to then train large numbers of programmers in order to create libraries etc. for the new language. Or maybe its not that the splintering occurs directly because of the language. Instead it might occur indirectly due to lisp programmers, having been exposed to the idea of language extension through lisp, become more prone to creating a whole new language when the one they have doesn't suit their needs precisely?

pc 18y ago

This reads like a Chinese government strategy document: "the world thinks we suck. How do we convince everyone we're vibrant and fun-loving?" I've been a Lisp hacker for years -- Symbolics Lisp Machine in my bedroom, coded in at least a half dozen different Lisp dialects -- but I ended up using Smalltalk for my startup. Treating Lisp's "rehabilitation" as a mere branding exercise shows just how screwed the Lisp community still is, and is symptomatic of the underlying issue. (By "Lisp", I mostly refer to Common Lisp.) Lisp's problem is a meta-problem. The community is actively resistant to advancement, change, and evolution in the language. Attempts to modify (or even clarify) aspects of the Common Lisp standard are tedious exercises in futility, but the standardisation straitjacket is still seen as a good thing. A bit strangely, this resistance to change existing standards is accompanied by a slowness to standardise (even informally) anything that isn't already. The end result is that there's still no reliably portable way to write networking code in CL. And this is why Lisp is unpopular. The stasis is sad and ironic, given Lisp's hackerdom beginnings. Rather than wonder why, in 2009, so few are using Lisp, we should be amazed that the language is still pretty cool two decades after the innovation stopped. I hope the Clojure guys change things. They seem to have the right approach. Footnote: I was going to be a member of the CLRFI group (roughly equivalent to PEP or SRFI) that got some interest at ILC 2005, and which was going to try to create some sort of forward momentum in the community. It frizzled out, of course, and now http://clrfi.alu.org/ http://clrfi.alu.org/ appears to redirect to the ALU homepage.

miked 18y ago
>> I ended up using Smalltalk for my startup. I'm getting ready to start a new project with a significant GUI forms component. I wanted to go with Clojure, but it still seems a little rough around the edges. So I'm leaning towards Visualworks Smalltalk, in part because it seems like a great language to prototype in and partly because the OOP aspect fits so well with GUIs. I'm curious: did you consider Clojure? Would you mind elaborating on why you went with Smalltalk? given the number of Lispers on this site, the answer might be of broad interest.
- plinkplonk 18y ago
  "Visualworks Smalltalk," Doesn't VW have a "pay us x % of your revenue forever" license (http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=var http://www.cincomsmalltalk.com/userblogs/cincom/blogView?con...)? I am curious as to why any startup would want to accept these terms.

lsb 18y ago

I went to see if there was anything like ActiveRecord for Lisp, because, well, that's a pretty metaprogramming-heavy domain. What do I get as the first google hit? A forum post asking about that, http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006-04/msg00735.html http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006... --- never a good sign. Two people answered, one with a link to his rant on comp.lang.lisp, and one talking about the virtues of CLSQL. The code snippet from CLSQL looks horrendous: ;; select the user with ID 1 and set his username column to joe (let ((user (first (select 'user :where [= [id] 1] :flatp t :refresh t)))) (setf (username user) "joe") (update-records-from-instance user)) Compare this to User.find(1).update_attribute(:username, "joe") 16 tokens vs 45. I don't know CLOS, but (update-attribute (find *User* 1) 'username "joe") is a great start.

antiismist 18y ago
I've been using leftparen (a framework written in PLT Scheme) for a project, this would be something like: (rec-set-prop! userid 'username "joe") (store-rec! userid)
pivo 18y ago
I found Elephant really nice to use with Lisp. It can use a SQL db as a data store, but uses it just for key/value mappings, so you can't use normal SQL commands as you might expect. I found the code to be very concise. http://common-lisp.net/project/elephant/ http://common-lisp.net/project/elephant/

jobeirne 18y ago

In response to the parting question from the article, here's an idea: make cool things with Lisp. Make cool things for Lisp.

jcl 18y ago
That seems to be how Erlang has achieved its recent popularity... some big successes in telecommunications systems and ejabberd.

tetha 18y ago

I belong to those people who tried to get into lisp and gave up, because the confusion to navigate per potential advantage over my major language (python) was too large. My background is a knowledge in C, Python and Java, using Python mostly. I mostly looked into lisp, because I kept encountering something I call the syntactic barrier when I tried to remove duplication from my code, and I knew: lisp had macros. Macros could break this barrier. So looking into lisp looked promising. I didn't care too much about the syntax, a good editor fixes this without a problem and it was a good opportunity to look into emacs a bit (usually, I use vim). Surfing through the chapters of practical common lisp when pretty well and understanding was not exactly hard. However after that, I was faced with confusion. There is a boatload of lisp dialects, each with a boatload of implementations and each implementation as another boatload of libraries that do something looking similar to what other implementations libraries do without being the same or compatible. How am I supposed to select any of these without having a clue? After a few days of back and forth, I decided to close the book lisp for me, because I could not find a way through this wall of selections -- at least not without investing a lot of time. Too much time for too little benefit over python. HTH, Tetha

10ren 18y ago
Some people (like esr) say the main benefit of lisp is not to use it, but to use the insights it gives into how to think about code. It may be that you already have that.
- silentbicycle 18y ago
  I agree, but if a language doesn't teach you things you can use outside of it, that's a really bad sign. This is in no way unique to Lisp. (I've been meaning to write about things I've learned from the dozen or so languages I've at least dabbled in, but haven't had the time.)

sbt 18y ago

I've been programming in Common Lisp for about a year and I consider myself an intermediate beginner. Someone made a terrific comment in response to Ron Garret's post earlier: the way you get productive in today's environment is primarily through libraries. Thus the situation is inescapable. You need tons of libraries to be productive. You need tons of programmers to write these libraries. You need an easy learning curve and appealing features to get these programmers. The bottom line is that you need the bad coders as well. As a beginner, I can safely say that it took a while before I finally got reasonably productive in Lisp. I still consider it 'the best' programming language. But the learning curve is much steeper than Python. Lisp will get nowhere without all the bad programmers. This may sound cynical, but the reason is that academically minded programmers won't spend time writing things like a download library for youtube videos, which many people find useful. These programmers are now all over Python. So why is Lisp difficult to learn? The most severe in my opinion is assignment. People find it intuitive to make temporary variables and store intermediate results in these. This is done by 'let' in CL, but if the previous style of programming is assumed, 'let' is clumsy and inconvenient to use. Another achilles heal I would like to mention is the lack of an editor with propper auto-completion. Yes, slime does this, but using emacs is too geeky for many programmers (remember you need these people) and this creates an additional stumbling block. Yet another problem is the CL websites. Remember that many people are in a hurry. The Python website is ripe with snippets that lets you do stuff fast without understanding much. In contrst, CL gives you some of the most monotone autogenerated documentation sites I've ever seen. Again, fine for people who already know Lisp, tedious for people that want to try stuff out as beginners. Faced with these realities I don't blame anyone who just want to get things done and run with Python. Unfortunately.

jimbokun 18y ago
"The most severe in my opinion is assignment." Clojure solves this problem by going all the way to the opposite extreme. "No assignment for you." Clojure data structures are immutable, and if you really want to do assignment, you need to explicitly use a ref/var/atom, which means you are going to figure out a way to write your program without assignment if at all possible. Clojure, of course, is designed around functional programming that has many idioms to make assignment-less programming the natural way to do things. I guess what this means is that Clojure can appeal to Python/Ruby/Perl hackers wanting to learn a different way to think about programming.

praptak 18y ago

My suggestion for anyone wanting to make Lisp popular: make a Lisp analogue of Mark Pilgrim's "Dive Into Python". Or at least consider whether it is possible to write such a book for Lisp in its current state.

halo 18y ago
Isn't that Peter Seibel's "Practical Common Lisp"?
- sbt 18y ago
  Pretty much. PCL is a great book that did much to bring the O'Reilly flavor to the community. Another good contribution is the Common Lisp Cookbook website, that contains snippets for common tasks. Sadly, this doesn't seem to have struck the heart of the problem (although Lisp-in-a-box that came with PCL seems to have done it for some people). Think about why Java is so widely used. I would argue that it's because of one thing: portable packages.
access_denied 18y ago
The elisp tutorial that comes with Emacs is pretty well written - fluid style, usage of real language features.

jcromartie 18y ago

Can someone explain the "it's only for AI" objection that people bring up? I have heard it from a few people first-hand and they couldn't say much else about it. Is it like "Macs are just good for graphics?"

silentbicycle 18y ago
Some people (apparently) assume Ruby is only for the web; they're confusing it and Rails. Lisp was closely associated with AI a few decades ago.

pavelludiq 18y ago

Before i learned scheme(I don't know CL), i didn't know how to write python. I knew how to write python syntax, but had no idea how to write code that doesn't suck. I still write bad code, but at least i know when its bad and i need to change it. Scheme thought me how to spot ugly code. I still use for and while loops(recursion is expensive in python, and you shouldn't write scheme in python) but i learned to write small and simple functions and combine them in smart ways(list comprehensions, maps, filters, decorators...). I guess i knew that from reading about the unix philosophy, but it took me to see it in code to understand it. So learning scheme might help you to be a better programmer, or it might screw you up and you end up writing stuff like this http://www.pick.ucam.org/~ptc24/yvfc.html http://www.pick.ucam.org/~ptc24/yvfc.html p.s. I've never written anything longer than a textbook exercise in scheme, so i don't know if you can actually write real stuff in this(or how hard it is) but playing with it is really fun, you should to it just for that.

blue1 18y ago

I absolutely love Common Lisp, but it has some problematic areas, which are not the classical stupid ones you sometimes still hear from clueless people (such as "lots of parentheses", "lisp is slow", "lisp is for AI only" etc.). I won't even say that libraries are a real problem. Sure there is no CPAN, but still there are a lot of very good CL libraries around, and they are not really hard to install. But: 1. The language is sophisticated. This is a "problem", in the sense that such a language takes time to study. It will never be popular. The Condition system and CLOS, for example, are way more complex and versatile than, say, the equivalent areas of Java. And then there are macros. Common Lisp has not been designed as a mainstream language for mainstream programmers. It is, I fear, an elite tool. 2. Certain kind of operations are inconvenient. Maybe when CL was designed, sockets, multithreading, text processing etc were not so popular. But now, it feels like CL has not really adapted well to the modern world. Having to install a compatibility library for using sockets is reminiscent of things like "trumpet winsock". Does not feel very cutting edge. 3. The literature is lacking. "Practical Common Lisp" is very good, but one book is not enough. For example, what are the best practices to organize large CL programs? No book tells it (maybe some obscure out-of-print text that I have not yet tracked?). What about programming idioms, or patterns as you prefer? Apart from an ancient presentation by peter norvig, nothing exist. And so on. 4. The ANSI standard is a big blessing and a big curse. It is a well-written and smart opus. But nowadays no one has the resources for a new standard; both in terms of money and focus. This means that ANSI CL seems an ancient pinnacle of beauty which will never be equalled and certainly can not be improved. (the perfection of ancient architecture, as seen by renaissance architects, comes to mind). This makes CL a splendid but dying civilization. 5. I have a feeling that the community is slowly dying as well. While in recent years many CL sites and blogs have appeared, comp.lang.lisp has lost many important contributors. Nor I can really blame them: while still a wonderful language, CL is nonetheless petrified, and I suppose one may became slightly bored after a decade or two of discussing the finer points of the Standard.

sandGorgon 18y ago
You're dead-on about the lack of literature. I am no lisp expert (python stole me away), but something like the PythonChallenge for lisp could go a long way towards building a working knowledge. I really wish we could have books like Norvig's PAIP in the public domain - it is really one of the best books on lisp ever, however very expensive - more so in third world countries. Oh and I really wish that brackets were used rather than parantheses - there is RSI you know!