6 ms·

Why I'm not using Lisp

24 points by parenthesis 18y ago

daniel-cussen 18y ago
The good news is all the problems mentioned were had to do with Lisp's lack of popularity.
- pmjordan 18y ago
  Well, I don't know. Popularity definitely gets you libraries, but to a large extent, the runtimes are VERY daunting even to interested people. The author raises some valid issues with CL implementations. I'd also add concurrency/threading, for example. Part of the problem is that the standard (in my opinion) standardises some of the "wrong" things. In part, that's just down to its age, but also just the whole "design by committee" problem. So if there are important omissions in the standard, you get a load of implementations that technically comply, but in effect are incompatible with one another for any real work. Most of the popular newer languages have a "benevolent dictator" (or not so benevolent in some cases), which means there's a reference implementation which almost everyone uses. Okay, maybe you lose out a bit on runtime quality, but I think the current trend towards building on top of the JVM, etc. will continue and alleviate that particular problem. I also tried to use Common Lisp, I really did. I liked the core, but in the end it was the sheer volume of little problems that drove me away. Luckily, I've found a lovely compromise in Clojure.
- cstejerean 18y ago
  Why is that good news? Are you still waiting for Lisp to get popular and to make all these problems go away?
  - pg 18y ago
    I think the point is that the problem isn't in the language core, but in more superficial things like libraries.
    - gaius 18y ago
      Well, libraries may be superficial, but I few times now I've started in LISP, needed something that I just can't find, can't build myself (I'm not that good) and switched to Python because I needed to get stuff done. I am slowly but surely assembling all the LISP pieces I need (CLSQL being the latest piece of the puzzle). But the truth is you can install Python, be doing something useful within a day and writing production code within a week. LISP requires much more upfront investment before you (well, me) can be productive in it. That's not a criticism of LISP itself, but the lack of a "batteries included" distribution. If only ActiveState made an ActiveLISP...
      - gruseom 18y ago
        What have you needed that you couldn't find?
        gaius 18y ago
        OK, here's one example. I have an app that receives email, processes it, and sends it back. I need to get all its attachments, do work on them and build a new message. In Python parsing an email is: import email msg = email.message_from_string(sys.stdin.read()) How easy is that? The subject is msg["Subject"]. Iterating over the MIME parts is 2 lines of code. I could build all the scaffolding very quickly, and concentrate on the problems I needed to solve. Maybe this is just as easy in LISP - if you already know where to get all the bits, and I don't, and I'm not good enough to write a production-grade RFC822 handler in a day. I like LISP a lot and am trying to use it where I can, but at the end of the day, I have to get stuff out the door as quickly as I can...
        icey 18y ago
        I think more than anything else, this is probably the largest problem with Lisp adoption. Maybe Clojure will have better luck in this space because of its ability to drop into the JVM to get libraries.
        18y ago
xlnt 18y ago
So, it would take W hours to get Lisp working well. He will spend X hours writing and maintaining his python over the next Y years. And if he used Lisp instead, after the initial W hour investment, he would save Z hours on less maintenance and coding time thanks to Lisp's power. Is Z greater than W, or less than W? That's the critical question for him. How can he decide which approach is best without estimating the hour values of each variable? Edit: of course there's some other issues. maybe he'd spend 80 hours on python maintenance vs 100 writing lisp unicode support. the numbers are made up, but the point is that maintenance probably isn't much fun, so one might choose the lisp path even if it takes a bit more time. besides fun, one might learn more that way.
- cstejerean 18y ago
  Why are you automatically assuming that the maintenance costs of a Lisp app are lower than of a Python app? Lisp as a concept is very powerful. The current dialects, their implementations, respective libraries and package management systems on the other hand have often gotten in my way. For example take a look at http://article.gmane.org/gmane.lisp.cclan.general/807 http://article.gmane.org/gmane.lisp.cclan.general/807
  - xlnt 18y ago
    More powerful language -> shorter, DRYer code -> less maintenance. (Plus a few other reasons. See PG's essays, PG's Lisp books, and SICP if you don't know the other reasons.) If you don't believe this, don't use Lisp. The guy writing the article does seem to believe it. He likes and respects Lisp. So he ought to analyze in the way I said.
    - sunkencity 18y ago
      So it's lack of faith that is his problem? But yeah I agree with you, the more powerful the language, the shorter code you can write. Though python is a pretty powerful language in it's own right, it's got a repl console and sweet little list comprehensions and more, so is the difference really that great between python and lisp? Python is not assembler after all. To know that I suppose I should have to learn lisp myself, which I haven't had the time to do yet. Surrounded by java zealots at work as I am though, and that clojure seems to be the best working non-statically typed language on the JVM I just might. The issue with utf-8 seems to be solved by now from reading the comments around here. But there are always problems working with utf-8 with libraries written by people that have never needed to work on non-ascii text, the code has simply not been tested thoroughly on the problem of working with utf-8 text so while it might be production quality regarding to ASCII there are weird bugs that pop out of the woodwork when working with musical notes. On a related note: I've written a few programs in ruby where I've really run into trouble not having decent unicode support in the language. With iconv you can easily make it work if you are working with characters that map to an 8-bit character set. But if you are working with characters that map to several european languages at once, and need the euro symbol, you're in the cold. You can have utf-8 strings in ruby yes, but if you pry them apart, or make changes to them, they loose their utf-8:ness and look like shit. This is an issue that should really be solved at language level, if you don't want to have roughly similar the same abstraction level dealing with strings as you have in C. I love ruby, but I hate working with utf-8 strings in it just now.
jimbokun 18y ago
Clojure might be a good choice. Implemented out of the box, it should get Java's Unicode support for free.
- brlewis 18y ago
  Kawa Scheme was already mature at the time this article was written. He definitely could have used it.
- sage_joch 18y ago
  I actually just decided to start learning Closure. I was really impressed by this introduction: http://clojure.blip.tv/file/982823 http://clojure.blip.tv/file/982823 and http://clojure.blip.tv/file/982957 http://clojure.blip.tv/file/982957. I've tried to get into Lisp a number of times (largely because of the arguments/enthusiasm expressed for it in Hackers & Painters), but have not found an implementation that seemed worth pouring large amounts of time and energy into. My first impression with Clojure is that it could become the first "mainstream" Lisp.
astrec 18y ago
Older article by the looks. Could be powerPC thing. I'm using SBCL and Slime (aquamacs) on my Macbook right now - or more accurately I would be if I wasn't procrastinating on HN ;)
- omouse 18y ago
  I think OpenMCL works fine on the PPC architecture. Not sure about SBCL.
jrockway 18y ago
Uh, what? SBCL + SLIME works fine on OS X. In fact, the canonical SLIME video uses that exact combination. I haven't use CLISP on a Mac... but I'm sure it works fine. I also think it's interesting that he describes Python as having "outstanding" Unicode support. There's an article on the front page right now about how poor Python's Unicode support is. (There's some support, but it's not outstanding. Merely acceptable.)
- cstejerean 18y ago
  Might be considered outstanding when compared to no support at all. You're right though, Unicode in Python could be much better, but on the other hand I've never had Python's Unicode support get in my way.
  - jrockway 18y ago
    I will be sure to apply that logic to other situations ;) "You know, I'm outstandingly attractive when you compare me to nobody at all!"
sellout 18y ago
The article is over two years old at this point. SBCL works fine on Macs now, and OpenMCL (now called Clozure CL) supports Unicode. (NB: I am employed by Clozure)
- jshen 18y ago
  does OpenMCL run on 32bit intel chips yet?
  - marijn 18y ago
    Nope. (Runs like a charm on 64-bit Intels though.)
    - jshen 18y ago
      if you buy me one I'll give it a try ;) Barring a gift I'm stuck with my 32bit macbook pro for a while.
ken 18y ago
I know it's 2 years old, but it's fun to look back and see where we were, not too long ago. His #1 need is "Outstanding Unicode support", and he's switching to Python for this. Just today there was a blog post that made the rounds, "The Truth About Unicode In Python" (http://www.cmlenz.net/archives/2008/07/the-truth-about-unicode-in-python http://www.cmlenz.net/archives/2008/07/the-truth-about-unico...) that gripes about Unicode in Python! One of the gripes about Python was that its internal representation is UCS-2 by default. In comparison, SBCL uses 21 bits internally, and his Python example works fine in SBCL (on the Mac, no less): * (characterp #\MUSICAL_SYMBOL_G_CLEF) T * (char-name #\MUSICAL_SYMBOL_G_CLEF) "MUSICAL_SYMBOL_G_CLEF" I wonder if he had to make the choice again on a fresh project today which he would choose. Things change fast.
- marijn 18y ago
  (But note that CL implementations also don't provide clever sorting or any kind of regexps at all. SBCL and Allegro do get case conversions right -- at least for Latin characters with accents. I'm too ignorant to test more exotic characters.)
tx 18y ago
He could have just said "I only use stuff well-supported on OSX". This isn't about Lisp, really. He'll face this dilemma "X vs OSX" over and over and over again, where X can be anything, from latest vim goodies to some arbitrary libraries. I was in the same situation and I simply ditched OSX: it just can't rival Linux as an ultimate programmers' world exploration vehicle. Ironically, it was Python and some Python libraries that drove me to Linux. I have a Mac too, of course, as an ultimate Safari+Photoshop machine.
- 0x44 18y ago
  Wait, vim doesn't work on OSX?!
  - tx 18y ago
    Vim works allright, but getting the latest version with all your favorite plugins won't be as easy as "apt-get and fly". When Leopard came out I was left without gvim for some time.
- icey 18y ago
  Picture, thousand words, etc etc.. http://lh4.ggpht.com/_gGwo1YUVIQg/RpYpNTwgJUI/AAAAAAAAApM/myMNYEX_6lI/IMG_2740.JPG http://lh4.ggpht.com/_gGwo1YUVIQg/RpYpNTwgJUI/AAAAAAAAApM/my...
  - d0mine 18y ago
    On the picture: Guido van Rossum (the author of Python) uses MacBook. Therefore the above comment implies that Python should work on Mac OS X.
    - icey 18y ago
      Well, I'm glad someone saw it, because google seems to have killed it :(
    - bayareaguy 18y ago
      He could be running linux or freebsd on it.

24 points by parenthesis 18y ago

daniel-cussen 18y ago

The good news is all the problems mentioned were had to do with Lisp's lack of popularity.

pmjordan 18y ago
Well, I don't know. Popularity definitely gets you libraries, but to a large extent, the runtimes are VERY daunting even to interested people. The author raises some valid issues with CL implementations. I'd also add concurrency/threading, for example. Part of the problem is that the standard (in my opinion) standardises some of the "wrong" things. In part, that's just down to its age, but also just the whole "design by committee" problem. So if there are important omissions in the standard, you get a load of implementations that technically comply, but in effect are incompatible with one another for any real work. Most of the popular newer languages have a "benevolent dictator" (or not so benevolent in some cases), which means there's a reference implementation which almost everyone uses. Okay, maybe you lose out a bit on runtime quality, but I think the current trend towards building on top of the JVM, etc. will continue and alleviate that particular problem. I also tried to use Common Lisp, I really did. I liked the core, but in the end it was the sheer volume of little problems that drove me away. Luckily, I've found a lovely compromise in Clojure.
cstejerean 18y ago
Why is that good news? Are you still waiting for Lisp to get popular and to make all these problems go away?
- pg 18y ago
  I think the point is that the problem isn't in the language core, but in more superficial things like libraries.
  - gaius 18y ago
    Well, libraries may be superficial, but I few times now I've started in LISP, needed something that I just can't find, can't build myself (I'm not that good) and switched to Python because I needed to get stuff done. I am slowly but surely assembling all the LISP pieces I need (CLSQL being the latest piece of the puzzle). But the truth is you can install Python, be doing something useful within a day and writing production code within a week. LISP requires much more upfront investment before you (well, me) can be productive in it. That's not a criticism of LISP itself, but the lack of a "batteries included" distribution. If only ActiveState made an ActiveLISP...
    - gruseom 18y ago
      What have you needed that you couldn't find?
      - gaius 18y ago
        OK, here's one example. I have an app that receives email, processes it, and sends it back. I need to get all its attachments, do work on them and build a new message. In Python parsing an email is: import email msg = email.message_from_string(sys.stdin.read()) How easy is that? The subject is msg["Subject"]. Iterating over the MIME parts is 2 lines of code. I could build all the scaffolding very quickly, and concentrate on the problems I needed to solve. Maybe this is just as easy in LISP - if you already know where to get all the bits, and I don't, and I'm not good enough to write a production-grade RFC822 handler in a day. I like LISP a lot and am trying to use it where I can, but at the end of the day, I have to get stuff out the door as quickly as I can...
        icey 18y ago
        I think more than anything else, this is probably the largest problem with Lisp adoption. Maybe Clojure will have better luck in this space because of its ability to drop into the JVM to get libraries.
        18y ago

xlnt 18y ago

So, it would take W hours to get Lisp working well. He will spend X hours writing and maintaining his python over the next Y years. And if he used Lisp instead, after the initial W hour investment, he would save Z hours on less maintenance and coding time thanks to Lisp's power. Is Z greater than W, or less than W? That's the critical question for him. How can he decide which approach is best without estimating the hour values of each variable? Edit: of course there's some other issues. maybe he'd spend 80 hours on python maintenance vs 100 writing lisp unicode support. the numbers are made up, but the point is that maintenance probably isn't much fun, so one might choose the lisp path even if it takes a bit more time. besides fun, one might learn more that way.

cstejerean 18y ago
Why are you automatically assuming that the maintenance costs of a Lisp app are lower than of a Python app? Lisp as a concept is very powerful. The current dialects, their implementations, respective libraries and package management systems on the other hand have often gotten in my way. For example take a look at http://article.gmane.org/gmane.lisp.cclan.general/807 http://article.gmane.org/gmane.lisp.cclan.general/807
- xlnt 18y ago
  More powerful language -> shorter, DRYer code -> less maintenance. (Plus a few other reasons. See PG's essays, PG's Lisp books, and SICP if you don't know the other reasons.) If you don't believe this, don't use Lisp. The guy writing the article does seem to believe it. He likes and respects Lisp. So he ought to analyze in the way I said.
  - sunkencity 18y ago
    So it's lack of faith that is his problem? But yeah I agree with you, the more powerful the language, the shorter code you can write. Though python is a pretty powerful language in it's own right, it's got a repl console and sweet little list comprehensions and more, so is the difference really that great between python and lisp? Python is not assembler after all. To know that I suppose I should have to learn lisp myself, which I haven't had the time to do yet. Surrounded by java zealots at work as I am though, and that clojure seems to be the best working non-statically typed language on the JVM I just might. The issue with utf-8 seems to be solved by now from reading the comments around here. But there are always problems working with utf-8 with libraries written by people that have never needed to work on non-ascii text, the code has simply not been tested thoroughly on the problem of working with utf-8 text so while it might be production quality regarding to ASCII there are weird bugs that pop out of the woodwork when working with musical notes. On a related note: I've written a few programs in ruby where I've really run into trouble not having decent unicode support in the language. With iconv you can easily make it work if you are working with characters that map to an 8-bit character set. But if you are working with characters that map to several european languages at once, and need the euro symbol, you're in the cold. You can have utf-8 strings in ruby yes, but if you pry them apart, or make changes to them, they loose their utf-8:ness and look like shit. This is an issue that should really be solved at language level, if you don't want to have roughly similar the same abstraction level dealing with strings as you have in C. I love ruby, but I hate working with utf-8 strings in it just now.

jimbokun 18y ago

Clojure might be a good choice. Implemented out of the box, it should get Java's Unicode support for free.

brlewis 18y ago
Kawa Scheme was already mature at the time this article was written. He definitely could have used it.
sage_joch 18y ago
I actually just decided to start learning Closure. I was really impressed by this introduction: http://clojure.blip.tv/file/982823 http://clojure.blip.tv/file/982823 and http://clojure.blip.tv/file/982957 http://clojure.blip.tv/file/982957. I've tried to get into Lisp a number of times (largely because of the arguments/enthusiasm expressed for it in Hackers & Painters), but have not found an implementation that seemed worth pouring large amounts of time and energy into. My first impression with Clojure is that it could become the first "mainstream" Lisp.

astrec 18y ago

Older article by the looks. Could be powerPC thing. I'm using SBCL and Slime (aquamacs) on my Macbook right now - or more accurately I would be if I wasn't procrastinating on HN ;)

omouse 18y ago
I think OpenMCL works fine on the PPC architecture. Not sure about SBCL.

jrockway 18y ago

Uh, what? SBCL + SLIME works fine on OS X. In fact, the canonical SLIME video uses that exact combination. I haven't use CLISP on a Mac... but I'm sure it works fine. I also think it's interesting that he describes Python as having "outstanding" Unicode support. There's an article on the front page right now about how poor Python's Unicode support is. (There's some support, but it's not outstanding. Merely acceptable.)

cstejerean 18y ago
Might be considered outstanding when compared to no support at all. You're right though, Unicode in Python could be much better, but on the other hand I've never had Python's Unicode support get in my way.
- jrockway 18y ago
  I will be sure to apply that logic to other situations ;) "You know, I'm outstandingly attractive when you compare me to nobody at all!"

sellout 18y ago

The article is over two years old at this point. SBCL works fine on Macs now, and OpenMCL (now called Clozure CL) supports Unicode. (NB: I am employed by Clozure)

jshen 18y ago
does OpenMCL run on 32bit intel chips yet?
- marijn 18y ago
  Nope. (Runs like a charm on 64-bit Intels though.)
  - jshen 18y ago
    if you buy me one I'll give it a try ;) Barring a gift I'm stuck with my 32bit macbook pro for a while.

ken 18y ago

I know it's 2 years old, but it's fun to look back and see where we were, not too long ago. His #1 need is "Outstanding Unicode support", and he's switching to Python for this. Just today there was a blog post that made the rounds, "The Truth About Unicode In Python" (http://www.cmlenz.net/archives/2008/07/the-truth-about-unicode-in-python http://www.cmlenz.net/archives/2008/07/the-truth-about-unico...) that gripes about Unicode in Python! One of the gripes about Python was that its internal representation is UCS-2 by default. In comparison, SBCL uses 21 bits internally, and his Python example works fine in SBCL (on the Mac, no less): * (characterp #\MUSICAL_SYMBOL_G_CLEF) T * (char-name #\MUSICAL_SYMBOL_G_CLEF) "MUSICAL_SYMBOL_G_CLEF" I wonder if he had to make the choice again on a fresh project today which he would choose. Things change fast.

marijn 18y ago
(But note that CL implementations also don't provide clever sorting or any kind of regexps at all. SBCL and Allegro do get case conversions right -- at least for Latin characters with accents. I'm too ignorant to test more exotic characters.)

tx 18y ago

He could have just said "I only use stuff well-supported on OSX". This isn't about Lisp, really. He'll face this dilemma "X vs OSX" over and over and over again, where X can be anything, from latest vim goodies to some arbitrary libraries. I was in the same situation and I simply ditched OSX: it just can't rival Linux as an ultimate programmers' world exploration vehicle. Ironically, it was Python and some Python libraries that drove me to Linux. I have a Mac too, of course, as an ultimate Safari+Photoshop machine.

0x44 18y ago
Wait, vim doesn't work on OSX?!
- tx 18y ago
  Vim works allright, but getting the latest version with all your favorite plugins won't be as easy as "apt-get and fly". When Leopard came out I was left without gvim for some time.
icey 18y ago
Picture, thousand words, etc etc.. http://lh4.ggpht.com/_gGwo1YUVIQg/RpYpNTwgJUI/AAAAAAAAApM/myMNYEX_6lI/IMG_2740.JPG http://lh4.ggpht.com/_gGwo1YUVIQg/RpYpNTwgJUI/AAAAAAAAApM/my...
- d0mine 18y ago
  On the picture: Guido van Rossum (the author of Python) uses MacBook. Therefore the above comment implies that Python should work on Mac OS X.
  - icey 18y ago
    Well, I'm glad someone saw it, because google seems to have killed it :(
  - bayareaguy 18y ago
    He could be running linux or freebsd on it.