4 ms·

Far too many intelligent programmers swear by lisp for there to be no "there" there. I'm trying to learn it in my nonexistent spare time.

gagege 8y ago
I know what you mean and I think that feeling comes from a difference between lisp the language (learn in a matter of hours) and lisp the ecosystem (takes much longer to get confident with). And, you really need to learn both, unless you have time to make everything from scratch.
- bunderbunder 8y ago
  Well, you need to learn both if you're going to make a career of working in Lisp. But even if that isn't in the cards (and it isn't for most of us, for all sorts of reasons), there's still a whole lot of value in learning the language enough to go through and make a few things from scratch. I tend to agree with ESR on the subject: "LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot." (http://www.catb.org/esr/faqs/hacker-howto.html http://www.catb.org/esr/faqs/hacker-howto.html)
  - deleted 8y ago
    [deleted]
3pt14159 8y ago
Look, here is the deal with Lisp. It shows you the data structure of your computer program and lets you operate on it and that is neat. But it's not useful for actual work because the way you manipulate it makes it hard for you to understand what is happening without knowing all the ways your code is being manipulated. I have to write lisp for my editor (emacs) and I don't hate it, but I don't love it either. The syntax is hard to read quickly because it's cluttered and (usually) nest-y. If you're willing to trade complete purity away, try Ruby. It's basically everything you want from Lisp without the mess. Give up purity, get comprehensibility. Blocks are a really great way of doing things. You can even investigate the block source code as a string if you really want to. Dynamic method definition is well supported and predictable. Data structures are easy to compose and operate on. It's basically all the power but in a more comprehensible way. There's a reason why Rails came out of Ruby. It's naturally powerful.
- aidenn0 8y ago
  I don't get the whole "macros make your code incomprehensible" thing that is always brought up. A macro is just another way to add abstraction to your program. You might as well say functions are bad because without reading the source code for the function you don't know what the function does. A macro that looks like one thing but does something else is a bad macro. We don't throw away functions just because someone can write a function named "sort" that actually randomizes it's argument rather than sorting
  - marcosdumay 8y ago
    Macros are way more powerful than functions. They can hide way more side effects, can fill a namespace, and can surprise you on many other ways. This wouldn't be a problem if those surprises were rare and clearly marked, but the entire reason for macros to exist is to carry the surprises. As a consequence, having macros as the default (ok, second choice, not much better) tool of your language is bad. It's not that macros are bad by themselves, but they shouldn't be used often. Besides, powerful tools do not get well together with dynamically typed languages.
    - aidenn0 8y ago
      > Macros are way more powerful than functions. They can hide way more side effects, can fill a namespace, and can surprise you on many other ways. Abstractions that surprise you are bad. That doesn't mean the tool used was necessarily bad. > This wouldn't be a problem if those surprises were rare and clearly marked, but the entire reason for macros to exist is to carry the surprises. See above RE: surprised. Also, I can usually identify a macro from indentation, as most macros tend to have lambda lists similar to: ((FOO BAR &key BAZ) &body b) which slime will pickup on and indent appropriately. > It's not that macros are bad by themselves, but they shouldn't be used often. If by "use" you mean "write" I agree. I do write macros far less often than I write functions, and this is common advice for lisp programmers anyways. > Besides, powerful tools do not get well together with dynamically typed languages. Not all lisps are dynamically typed, even common lisp has optional type declarations and typed racket takes this further. Also the GP post suggested Ruby, so that's not a great alternative by this argument.

gagege 8y ago

I know what you mean and I think that feeling comes from a difference between lisp the language (learn in a matter of hours) and lisp the ecosystem (takes much longer to get confident with). And, you really need to learn both, unless you have time to make everything from scratch.

bunderbunder 8y ago
Well, you need to learn both if you're going to make a career of working in Lisp. But even if that isn't in the cards (and it isn't for most of us, for all sorts of reasons), there's still a whole lot of value in learning the language enough to go through and make a few things from scratch. I tend to agree with ESR on the subject: "LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot." (http://www.catb.org/esr/faqs/hacker-howto.html http://www.catb.org/esr/faqs/hacker-howto.html)
- deleted 8y ago
  [deleted]

3pt14159 8y ago

Look, here is the deal with Lisp. It shows you the data structure of your computer program and lets you operate on it and that is neat. But it's not useful for actual work because the way you manipulate it makes it hard for you to understand what is happening without knowing all the ways your code is being manipulated. I have to write lisp for my editor (emacs) and I don't hate it, but I don't love it either. The syntax is hard to read quickly because it's cluttered and (usually) nest-y. If you're willing to trade complete purity away, try Ruby. It's basically everything you want from Lisp without the mess. Give up purity, get comprehensibility. Blocks are a really great way of doing things. You can even investigate the block source code as a string if you really want to. Dynamic method definition is well supported and predictable. Data structures are easy to compose and operate on. It's basically all the power but in a more comprehensible way. There's a reason why Rails came out of Ruby. It's naturally powerful.

aidenn0 8y ago
I don't get the whole "macros make your code incomprehensible" thing that is always brought up. A macro is just another way to add abstraction to your program. You might as well say functions are bad because without reading the source code for the function you don't know what the function does. A macro that looks like one thing but does something else is a bad macro. We don't throw away functions just because someone can write a function named "sort" that actually randomizes it's argument rather than sorting
- marcosdumay 8y ago
  Macros are way more powerful than functions. They can hide way more side effects, can fill a namespace, and can surprise you on many other ways. This wouldn't be a problem if those surprises were rare and clearly marked, but the entire reason for macros to exist is to carry the surprises. As a consequence, having macros as the default (ok, second choice, not much better) tool of your language is bad. It's not that macros are bad by themselves, but they shouldn't be used often. Besides, powerful tools do not get well together with dynamically typed languages.
  - aidenn0 8y ago
    > Macros are way more powerful than functions. They can hide way more side effects, can fill a namespace, and can surprise you on many other ways. Abstractions that surprise you are bad. That doesn't mean the tool used was necessarily bad. > This wouldn't be a problem if those surprises were rare and clearly marked, but the entire reason for macros to exist is to carry the surprises. See above RE: surprised. Also, I can usually identify a macro from indentation, as most macros tend to have lambda lists similar to: ((FOO BAR &key BAZ) &body b) which slime will pickup on and indent appropriately. > It's not that macros are bad by themselves, but they shouldn't be used often. If by "use" you mean "write" I agree. I do write macros far less often than I write functions, and this is common advice for lisp programmers anyways. > Besides, powerful tools do not get well together with dynamically typed languages. Not all lisps are dynamically typed, even common lisp has optional type declarations and typed racket takes this further. Also the GP post suggested Ruby, so that's not a great alternative by this argument.