5 ms·

I really don't find that lisp, at least common lisp, is particularly concise. Consider lambda functions, one of those things that lisp is particularly praised f

I really don't find that lisp, at least common lisp, is particularly concise. Consider lambda functions, one of those things that lisp is particularly praised for; common lisp: (lambda (x) (+ x 1)) C#3 : x=> x + 1 ruby : { |x| x + 1 } python : lambda x: x + 1 Haskell : \x -> x + 1 Just in terms of character count, CL is the longest of the lot. No, the problem with trying to get a lisp under your belt has alredy been mentioned. Compared to the alternatives; - choosing an implementation is a research project (clisp? sbcl? allegro?) - documentation is weaker - libraries are harder to find and install (ASDF vs Rubygems, Python eggs, etc.) - emacs/slime is an investment to learn - examples are few and far between - the language itself (the words, not the punctuation) is inelegant (mapcar, setq, cdadr) I've tried really hard to learn lisp, and it turns out that actually, while there may be some platonic lisp that IS great, actually programming common lisp, now, is a massive effort in struggling in the dark.

Hexstream 19y ago
"I've tried really hard to learn lisp, and it turns out that actually, while there may be some platonic lisp that IS great, actually programming common lisp, now, is a massive effort in struggling in the dark." The weedout process has worked its magic again ;P You usually get rewards proportional to the effort... I don't think lisp is beyond anyone's reach if they work faithfully on gaining proficiency in it for 3 months, maximum. 3 months is nothing if it makes you a much better programmer, and/or you get to use this awesome language. I think it's important to first research lisp's benefits. Of course you won't be willing to spend the necessary efforts if you're not convinced... I know I just couldn't resist the appeal of closures, macros, CLOS (multiple inheritence, multimethods, class redefinitions) the condition system (restarts in particular), generalized variables and a bunch of other fun stuff.
- hernan7 19y ago
  Make it: 3 months full time, plus whatever amount of time is needed to become deeply conversant with all the underlying lambda calculus concepts.
  - Hexstream 19y ago
    You're saying nobody can become proficient (not "deeply conversant") in lisp in 3 months because I can't become deeply conversant in lambda calculus in 3 months?! nobody, proficient, lisp. I, deeply conversant, lambda calculus. You're comparing apples and oranges. I learned lisp (pretty deeply, I'd qualify myself as intermediate then and now) in what... 5 or 6 months? And I was alone. And I didn't know emacs. With some coaching and pointers I'm pretty sure I could have made it in 4. Aren't you happy?
    - hernan7 19y ago
      Well, we have 2 data points now. I guess we can agree that it's harder to learn than Python :-) For what it's worth, I think learning Lisp is useful for getting (re)acquainted with lambda calculus if nothing else.
      - tokipin 19y ago
        lisp doesn't strike me as a difficult-to-learn language. it actually seems the easiest of them all, definitely not harder than python to pick up. c++ is at the other end
- stevecooperorg 19y ago
  "The weedout process has worked its magic again ;P" Please don't call me a weed. You point out that the more effort you expend, the better you get. The problem is the rate of reward. Getting a productive lisp environment is hard work. Competing implementations, sometimes-compatible libraries, very little documentation -- these are things that make lisp, holistically, hard to adopt. Every other production language makes it easier to get to the programming. I can't think of a worse-supported production language than lisp. Also, the benefits you mention are either not that uncommon, or that valuable. The only thing lisp has as a unique feature is it's macro system, thanks to it's syntax. It's the only thing that can't be adapted straight into another language. Otherwise, the features you mentioned are basically available elsewhere; Visual Basic has closures. C++ has multiple inheritance. Python has multimethods. Ruby has class redefinitions. The thing is, I wanted to believe. I stocked up my library with PCL, SICP, the little schemer, and On Lisp. I learned emacs. I stuggled with asdf. What I found, though, did not seem to live up to the promise of a hidden pearl.
  - Hexstream 19y ago
    "Please don't call me a weed." Sorry :( "You point out that the more effort you expend, the better you get. The problem is the rate of reward. Getting a productive lisp environment is hard work. Competing implementations, sometimes-compatible libraries, very little documentation -- these are things that make lisp, holistically, hard to adopt. Every other production language makes it easier to get to the programming. I can't think of a worse-supported production language than lisp." I agree. "Also, the benefits you mention are either not that uncommon, or that valuable. The only thing lisp has as a unique feature is it's macro system, thanks to it's syntax. It's the only thing that can't be adapted straight into another language. Otherwise, the features you mentioned are basically available elsewhere; Visual Basic has closures. C++ has multiple inheritance. Python has multimethods. Ruby has class redefinitions." Well, it's uncommon and valuable to have all of them in a coherent language. Especially since they're pretty orthogonal features that complement eachother well. The whole is greater than the sum of its parts. "The thing is, I wanted to believe. I stocked up my library with PCL, SICP, the little schemer, and On Lisp. I learned emacs. I stuggled with asdf. What I found, though, did not seem to live up to the promise of a hidden pearl." I'm sorry that you've come to the conclusion lisp is not right for you. Maybe in a couple years you can try again and most implementation/library/documentation/etc issues will be resolved?
- jmtulloss 19y ago
  I would take 3 months to learn a new language, but then my startup would be dead. I picked up Python in a day. I'm quite proficient at it a year later. A simple syntax + a great standard library is the best way to get things done, if not the best way to learn to write software.
shiranaihito 19y ago
> - choosing an implementation is a research project (clisp? sbcl? allegro?) - documentation is weaker - libraries are harder to find and install (ASDF vs Rubygems, Python eggs, etc.) - emacs/slime is an investment to learn - examples are few and far between - the language itself (the words, not the punctuation) is inelegant (mapcar, setq, cdadr) - Exactly. Last year I started reading about Lisp etc, and wanted to play with it a little bit. These are the exact same obstacles I faced. If you ask about "IDEs" for Lisp, you're met with downright hostility for not embracing the glory of emacs with open arms - anything else is just unfathomable. Well, what if I'd like to just, you know, start using the language, and not learn a whole new world of an editor first? "Why does emacs + SLIME have to be the only viable option?" That's not a question you can ask, of course, but the answer would be something like "roll your own" anytime you need anything. (Oh, and Xach is a prick. He and Krysztov(or whatever) are practically high-fiving each other on IRC every time they alienate another new would-be Lisper) As for the implementation research, I sort of came to the conclusion that SBCL was the way to go, but documentation (for anything?) was pretty scarce, and ASDF feels like an obstacle too. Later on, I realized that Scheme is more elegant as a language, but it's more or less in the same situation as CL. Compared to these two, something like Python feels much more accessible to me (being a novice at all), because I get the feeling that I can just start using things whenever I want to make that effort. But that's just it - with Python, there's only the effort of learning the language as you use it. You learn the standard library as you go, and suddenly you notice you've accomplished a lot of things and had fun while at it. - At least that's how I imagine it will be when I get around to working on my own super-secret web-startupy project. With Lisps, you need to make a lot of effort just to get to the beginning, and that's a big problem.
- lnostdal 19y ago
  m-x slime (starts slime and sbcl) c-x-2 (split window in two; one for coding one for REPL) ..open a file at the top window by pressing c-x-f and typing in hello-world.lisp <enter> ..yay, start coding.. c-c-c to eval forms c-c-k to eval/compile the entire file q to close down "popups" (exceptions .. etc.) yawn .. what's the problem? .. are somewhat, "limited"?
- rsynnott 19y ago
ken 19y ago
You can shorten (+ x 1) to (1+ x), and if you get annoyed typing "lambda", it's not that hard to change it to something shorter like "fn". Also, CL has a lot of built-ins so I don't find I need to write lambdas nearly as often as in other languages. In this example, just say "1+". Another thing you'll find is that for trivial problems, Lisp might take a few extra characters, but it scales much better. Try making your Python lambda print the value of x first. Try telling your Ruby lambda that x (and x+1) fits in a machine word so it can compile the function into only a couple of CPU instructions. Try writing a metacircular evaluator in C#. :-) When you're just getting started, in any language, it doesn't really matter which implementation you pick. (FWIW, CLISP is byte-compiled, SBCL is a native compiler, and Allegro costs $600. Not unique to Lisp: you can find expensive proprietary C++ compilers, too.) As a Lisp and Ruby programmer, I disagree that Lisp's documentation is weak. I would be very happy if Ruby's docs were even half as good as Lisp's. I type "sudo apt-get install library-name" for both Lisp and Python libraries, so no difference there. (Ruby gems are less frequently packaged, and aren't compatible with the FHS, so they're a little harder.) Lisp examples seem to be more often found in (dead tree) books, while Ruby and Python examples are more often found on the web. Since Ruby and Python libraries (and even syntax) are still in flux, and Lisp predates the web, this kind of makes sense. If you can't buy a couple books, it can be rough, though some good Lisp books are becoming available on the web for free. Those symbols you picked are a little weird, but when's the last time you actually saw a cdadr? It is at least consistent (which is more than can be said for some languages!). I don't find "unshift" or "__gt__" any better. I don't want to sound like a pure apologist. I admit that Slime is an investment (if you don't already know Emacs). Apparently there is a Lisp plugin for Eclipse, but I know nothing about it. It is a shame more IDEs don't support Lisp well, though I can see why they don't. Finally, it could be simply that Lisp doesn't map well to your mind. (I don't mean this as an insult -- everybody's different. Maybe Smalltalk or Prolog or Sisal is your cup of tea.) I don't think Ruby maps well to mine, though I know some people who seem like Matz reincarnate -- which could explain why the docs are so sparse! The core of programming, to me, is having fun building good abstractions, and if Lisp isn't doing it for you, by all means, find (or invent!) something that does. Cheers!
- stevecooperorg 19y ago
  Hi, Ken. Thanks for the reply. I think what's happening currently in programming is that lisp-isms are filtering through to other languages. What used to be unique lisp-juice is available more generally, so the switch to lisp isn't perhaps as compelling. Anyway. I'm off to write that metacircular evaluator in c# ;)
gruseom 19y ago
In my experience, Common Lisp often doesn't come out best at the code snippet level. Where it shines is in building whole systems. After a while one passes an inflection point where one realizes, "Holy cow - what I'm doing now is supposed to be way harder than it is". I probably have this experience every week. You obviously put a lot of sincere effort into learning Lisp and I agree with much of what you say. After all that work, I wish I knew an easy way to communicate the joyful side to you.
- stevecooperorg 19y ago
  It may well be that it only really becomes apparent on larger projects. It's hard to get to that point, though, and maybe that's why the takeup is low. OTOH, some languages are particularly good on small things, but don't offer much help for large problems.
  - gruseom 19y ago
    Just out of curiosity, did you like working in Lisp? I mean, if you can abstract away from the annoyances you cited, did you actually enjoy the Lisp mode of programming (basically, writing syntax trees)?
    - stevecooperorg 19y ago
      I did, and I didn't. The "I did": It seems very sensible to use s-expressions for everything. That lispy syntax meant that I started seeing ways to encode almost everything as lisp. I even started keeping a todo list in s-expressions; (do (buy bread) (tidy (kitchen living-room bathroom)) (get life)) The classic XKCD cartoon had it perfectly: "I felt a great enlightment. I saw the naked structure of Lisp code unfold before me. The patterns and metapatterns danced. Syntax faded" I didn't: when it came to actual common lisp, cracks started to appear. The crazy mini-language for looping. The arbitrary-sounding names. The feeling that, if I ever wanted to do anything remotely windows-specific I would face years of horror. I've blooged about it more at http://www.stevecooper.org/2008/02/13/impractical-uncommon-lisp/ http://www.stevecooper.org/2008/02/13/impractical-uncommon-l..., if you've got too much free time. ;)

Hexstream 19y ago

"I've tried really hard to learn lisp, and it turns out that actually, while there may be some platonic lisp that IS great, actually programming common lisp, now, is a massive effort in struggling in the dark." The weedout process has worked its magic again ;P You usually get rewards proportional to the effort... I don't think lisp is beyond anyone's reach if they work faithfully on gaining proficiency in it for 3 months, maximum. 3 months is nothing if it makes you a much better programmer, and/or you get to use this awesome language. I think it's important to first research lisp's benefits. Of course you won't be willing to spend the necessary efforts if you're not convinced... I know I just couldn't resist the appeal of closures, macros, CLOS (multiple inheritence, multimethods, class redefinitions) the condition system (restarts in particular), generalized variables and a bunch of other fun stuff.

hernan7 19y ago
Make it: 3 months full time, plus whatever amount of time is needed to become deeply conversant with all the underlying lambda calculus concepts.
- Hexstream 19y ago
  You're saying nobody can become proficient (not "deeply conversant") in lisp in 3 months because I can't become deeply conversant in lambda calculus in 3 months?! nobody, proficient, lisp. I, deeply conversant, lambda calculus. You're comparing apples and oranges. I learned lisp (pretty deeply, I'd qualify myself as intermediate then and now) in what... 5 or 6 months? And I was alone. And I didn't know emacs. With some coaching and pointers I'm pretty sure I could have made it in 4. Aren't you happy?
  - hernan7 19y ago
    Well, we have 2 data points now. I guess we can agree that it's harder to learn than Python :-) For what it's worth, I think learning Lisp is useful for getting (re)acquainted with lambda calculus if nothing else.
    - tokipin 19y ago
      lisp doesn't strike me as a difficult-to-learn language. it actually seems the easiest of them all, definitely not harder than python to pick up. c++ is at the other end
stevecooperorg 19y ago
"The weedout process has worked its magic again ;P" Please don't call me a weed. You point out that the more effort you expend, the better you get. The problem is the rate of reward. Getting a productive lisp environment is hard work. Competing implementations, sometimes-compatible libraries, very little documentation -- these are things that make lisp, holistically, hard to adopt. Every other production language makes it easier to get to the programming. I can't think of a worse-supported production language than lisp. Also, the benefits you mention are either not that uncommon, or that valuable. The only thing lisp has as a unique feature is it's macro system, thanks to it's syntax. It's the only thing that can't be adapted straight into another language. Otherwise, the features you mentioned are basically available elsewhere; Visual Basic has closures. C++ has multiple inheritance. Python has multimethods. Ruby has class redefinitions. The thing is, I wanted to believe. I stocked up my library with PCL, SICP, the little schemer, and On Lisp. I learned emacs. I stuggled with asdf. What I found, though, did not seem to live up to the promise of a hidden pearl.
- Hexstream 19y ago
  "Please don't call me a weed." Sorry :( "You point out that the more effort you expend, the better you get. The problem is the rate of reward. Getting a productive lisp environment is hard work. Competing implementations, sometimes-compatible libraries, very little documentation -- these are things that make lisp, holistically, hard to adopt. Every other production language makes it easier to get to the programming. I can't think of a worse-supported production language than lisp." I agree. "Also, the benefits you mention are either not that uncommon, or that valuable. The only thing lisp has as a unique feature is it's macro system, thanks to it's syntax. It's the only thing that can't be adapted straight into another language. Otherwise, the features you mentioned are basically available elsewhere; Visual Basic has closures. C++ has multiple inheritance. Python has multimethods. Ruby has class redefinitions." Well, it's uncommon and valuable to have all of them in a coherent language. Especially since they're pretty orthogonal features that complement eachother well. The whole is greater than the sum of its parts. "The thing is, I wanted to believe. I stocked up my library with PCL, SICP, the little schemer, and On Lisp. I learned emacs. I stuggled with asdf. What I found, though, did not seem to live up to the promise of a hidden pearl." I'm sorry that you've come to the conclusion lisp is not right for you. Maybe in a couple years you can try again and most implementation/library/documentation/etc issues will be resolved?
jmtulloss 19y ago
I would take 3 months to learn a new language, but then my startup would be dead. I picked up Python in a day. I'm quite proficient at it a year later. A simple syntax + a great standard library is the best way to get things done, if not the best way to learn to write software.

shiranaihito 19y ago

> - choosing an implementation is a research project (clisp? sbcl? allegro?) - documentation is weaker - libraries are harder to find and install (ASDF vs Rubygems, Python eggs, etc.) - emacs/slime is an investment to learn - examples are few and far between - the language itself (the words, not the punctuation) is inelegant (mapcar, setq, cdadr) - Exactly. Last year I started reading about Lisp etc, and wanted to play with it a little bit. These are the exact same obstacles I faced. If you ask about "IDEs" for Lisp, you're met with downright hostility for not embracing the glory of emacs with open arms - anything else is just unfathomable. Well, what if I'd like to just, you know, start using the language, and not learn a whole new world of an editor first? "Why does emacs + SLIME have to be the only viable option?" That's not a question you can ask, of course, but the answer would be something like "roll your own" anytime you need anything. (Oh, and Xach is a prick. He and Krysztov(or whatever) are practically high-fiving each other on IRC every time they alienate another new would-be Lisper) As for the implementation research, I sort of came to the conclusion that SBCL was the way to go, but documentation (for anything?) was pretty scarce, and ASDF feels like an obstacle too. Later on, I realized that Scheme is more elegant as a language, but it's more or less in the same situation as CL. Compared to these two, something like Python feels much more accessible to me (being a novice at all), because I get the feeling that I can just start using things whenever I want to make that effort. But that's just it - with Python, there's only the effort of learning the language as you use it. You learn the standard library as you go, and suddenly you notice you've accomplished a lot of things and had fun while at it. - At least that's how I imagine it will be when I get around to working on my own super-secret web-startupy project. With Lisps, you need to make a lot of effort just to get to the beginning, and that's a big problem.

lnostdal 19y ago
m-x slime (starts slime and sbcl) c-x-2 (split window in two; one for coding one for REPL) ..open a file at the top window by pressing c-x-f and typing in hello-world.lisp <enter> ..yay, start coding.. c-c-c to eval forms c-c-k to eval/compile the entire file q to close down "popups" (exceptions .. etc.) yawn .. what's the problem? .. are somewhat, "limited"?
rsynnott 19y ago

ken 19y ago

You can shorten (+ x 1) to (1+ x), and if you get annoyed typing "lambda", it's not that hard to change it to something shorter like "fn". Also, CL has a lot of built-ins so I don't find I need to write lambdas nearly as often as in other languages. In this example, just say "1+". Another thing you'll find is that for trivial problems, Lisp might take a few extra characters, but it scales much better. Try making your Python lambda print the value of x first. Try telling your Ruby lambda that x (and x+1) fits in a machine word so it can compile the function into only a couple of CPU instructions. Try writing a metacircular evaluator in C#. :-) When you're just getting started, in any language, it doesn't really matter which implementation you pick. (FWIW, CLISP is byte-compiled, SBCL is a native compiler, and Allegro costs $600. Not unique to Lisp: you can find expensive proprietary C++ compilers, too.) As a Lisp and Ruby programmer, I disagree that Lisp's documentation is weak. I would be very happy if Ruby's docs were even half as good as Lisp's. I type "sudo apt-get install library-name" for both Lisp and Python libraries, so no difference there. (Ruby gems are less frequently packaged, and aren't compatible with the FHS, so they're a little harder.) Lisp examples seem to be more often found in (dead tree) books, while Ruby and Python examples are more often found on the web. Since Ruby and Python libraries (and even syntax) are still in flux, and Lisp predates the web, this kind of makes sense. If you can't buy a couple books, it can be rough, though some good Lisp books are becoming available on the web for free. Those symbols you picked are a little weird, but when's the last time you actually saw a cdadr? It is at least consistent (which is more than can be said for some languages!). I don't find "unshift" or "__gt__" any better. I don't want to sound like a pure apologist. I admit that Slime is an investment (if you don't already know Emacs). Apparently there is a Lisp plugin for Eclipse, but I know nothing about it. It is a shame more IDEs don't support Lisp well, though I can see why they don't. Finally, it could be simply that Lisp doesn't map well to your mind. (I don't mean this as an insult -- everybody's different. Maybe Smalltalk or Prolog or Sisal is your cup of tea.) I don't think Ruby maps well to mine, though I know some people who seem like Matz reincarnate -- which could explain why the docs are so sparse! The core of programming, to me, is having fun building good abstractions, and if Lisp isn't doing it for you, by all means, find (or invent!) something that does. Cheers!

stevecooperorg 19y ago
Hi, Ken. Thanks for the reply. I think what's happening currently in programming is that lisp-isms are filtering through to other languages. What used to be unique lisp-juice is available more generally, so the switch to lisp isn't perhaps as compelling. Anyway. I'm off to write that metacircular evaluator in c# ;)

gruseom 19y ago

In my experience, Common Lisp often doesn't come out best at the code snippet level. Where it shines is in building whole systems. After a while one passes an inflection point where one realizes, "Holy cow - what I'm doing now is supposed to be way harder than it is". I probably have this experience every week. You obviously put a lot of sincere effort into learning Lisp and I agree with much of what you say. After all that work, I wish I knew an easy way to communicate the joyful side to you.

stevecooperorg 19y ago
It may well be that it only really becomes apparent on larger projects. It's hard to get to that point, though, and maybe that's why the takeup is low. OTOH, some languages are particularly good on small things, but don't offer much help for large problems.
- gruseom 19y ago
  Just out of curiosity, did you like working in Lisp? I mean, if you can abstract away from the annoyances you cited, did you actually enjoy the Lisp mode of programming (basically, writing syntax trees)?
  - stevecooperorg 19y ago
    I did, and I didn't. The "I did": It seems very sensible to use s-expressions for everything. That lispy syntax meant that I started seeing ways to encode almost everything as lisp. I even started keeping a todo list in s-expressions; (do (buy bread) (tidy (kitchen living-room bathroom)) (get life)) The classic XKCD cartoon had it perfectly: "I felt a great enlightment. I saw the naked structure of Lisp code unfold before me. The patterns and metapatterns danced. Syntax faded" I didn't: when it came to actual common lisp, cracks started to appear. The crazy mini-language for looping. The arbitrary-sounding names. The feeling that, if I ever wanted to do anything remotely windows-specific I would face years of horror. I've blooged about it more at http://www.stevecooper.org/2008/02/13/impractical-uncommon-lisp/ http://www.stevecooper.org/2008/02/13/impractical-uncommon-l..., if you've got too much free time. ;)