5 ms·

I'm surprised that this didn't bring up Paul Graham's "Blub" concept, in which non-Lisp languages are thought to be objectively less powerful than the universal

I'm surprised that this didn't bring up Paul Graham's "Blub" concept, in which non-Lisp languages are thought to be objectively less powerful than the universal language of Lisp. That's been a lot to blame for the mystical reverence of Lisp in the 21st century. While I'm a Lisp fan myself, and agree that it is more powerful than a lot of mainstream languages, the idea that it is the "most powerful" blinds a lot of hard-core Lisp devotees to things like Haskell that are worth exploring as well.

goto11 6y ago
The "Blub" parable is really clever because it says that when other people doesn't use Lisp, it is simply because they are incapable of understanding its power - not because of any practical or technical reason to chose another language. So any argument the "Blub" programmers might use to justify "Blub" is automatically invalid. Of course it can be used for any non-mainstream language, and I have seen it used for Haskell, where Lisp is the "Blub" language.
- exdsq 6y ago
  I’ve had this recently. Was writing Python but missed the ease of concurrent functional programming. Used F# but missed type classes. Used Haskell but missed dependant types. Use Idris but miss the build environment of Python.
  - bcrosby95 6y ago
    Yes, once you learn enough languages I feel like you just find yourself constantly wishing you had aspects of another language, pretty much regardless of what language you're using. Sometimes its directly related to the language, sometimes its something like the ecosystem surrounding it. This is why I'm wary of "right tool for the job" when it comes to languages. In my experience usually there isn't a singular obvious right language. Maybe one is 35% right, another is 38% right, and the golden ticket language is actually just 45% right. And sometimes you won't really know until you're halfway through the project. If you wanted a 100% singular obvious correct language, you would have to make a custom language with traits from a dozen different ones. But in the real world, the differences between languages you can actually choose from end up being not that large.
    - AnimalMuppet 6y ago
      I think of languages as a multi-dimensional tree, with branches extending in different directions. I think that the trick is to figure out what the yak-shaving aspects of the project are going to be (which you can think of as a vector), and picking the language that goes the furthest in the direction of that vector (and thereby does the most to minimize the yak-shaving). This requires that you be able to fairly accurately determine what the yak-shaving will be up front (which can be problematic).
  - whateveracct 6y ago
    > Used Haskell but missed dependant types. They're coming :)
    - exdsq 6y ago
      Oooh is there a link to the work/who’s working on it?
      - whateveracct 6y ago
        https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell ^ this has a bunch of info + external links. Richard Eisenberg is the one owning it afaiu. I think there's also a GHC branch somewhere but idr its name.
- marcosdumay 6y ago
  Hum... The Blub parable is really clever because it surfaces the very real problem that a programmer that don't know a language can not predict the benefits or problems of using that language. I don't see how people (you are the 3rd I see here) get the impression it's a Lisp-only comparison. PG very clearly says he has no idea what language should be on top, and even if there is a top at all. And even if he didn't, that would just make him a practical example of the paradox, and wouldn't make the idea any less valid.
  - goto11 6y ago
    In context (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html) he specifically states that he think Lisp is at the top of the power continuum. The point of the Blup-parable is to explain why Lisp isn't that popular when it is so amazing.
    - marcosdumay 6y ago
      Ok, after reading it again, by "very clear" I was overstating it, but there is this note: > [4] Note to nerds: or possibly a lattice, narrowing toward the top; it's not the shape that matters here but the idea that there is at least a partial order. And in no place he says Lisp is the end-all best language. At most he compares it with other languages his competitors used on the context of Viaweb, what on the bottom of the article means C++, Java, Perl and Python. He indeed goes on to argue that any language more powerful than Lisp would be Lisp, because macros work that way. If you don't take notice that he is simplifying things into a power continuum to make a point, that can mislead you into the message that Lisp is the most powerful language. But he puts some effort into making the message language agnostic.
      - int_19h 6y ago
        Is Forth Lisp? Given that you can control the reader, everything is possible syntactically, and semantics is entirely what you make it.
        6y ago
skocznymroczny 6y ago
I think the problem is looking at the prism of being the most "powerful" or "expressive" language and ignoring everything around it. Go and Java programmers don't use their language over Lisp because they are masochists and enjoy the exercise of programming in a less expressive language. They choose their languages because of ease of use, large healthy ecosystems (compiler and libraries) and excellent IDE support. I sometimes see similarities in the D crowd. Because D has such advanced metaprogramming capabilities, it also suffers from parts of the Lisp curse. Too often, any criticism of D or comparison is rebuked with "but you can do it in D using this template magic and there's a package that partially implements it".
- aidenn0 6y ago
  I'm not saying your first sentence is wrong, but your second sentence is missing something fundamental: 1. "Ease of use" describes Go reasonably well (anyone who has used a compiled language can figure out Go tooling in minutes), but I've never found it to be true for Java. Whichever you think is better, I don't think there is a case for Maven or Gradle being an order-of-magnitude easier to use than ASDF. 2. The "large healthy ecosystem" from the libraries point of view is a silly argument for Go, since 10 years ago Lisp clearly had the larger ecosystem. Something is fundamentally different (socially, technically, or otherwise) from Lisp to Go that Go could grow the library ecosystem it has from zero in a decade, while Common Lisp could not in 25 years. 3. The "large healthy ecosystem" from the compiler point of view is silly; Lisp has 2 healthy commercial implementations (Lispworks, Allegro), 3 very actively maintained open-source implementations (sbcl, ccl, ecl), plus several other "somewhat maintained" implementations. Thats almost Java plus Go put together. 4. It's funny you mention IDE support, because tooling in general, and SLIME specifically is what keeps me using Lisp. Java actually has fairly solid IDE support, but outside of the Smalltalk world, I've never seen anything even close to SLIME in terms of being a useful IDE.
andi999 6y ago
I think I read this a while ago and tried to learn lisp (i didnt fully understand macros, only superficially). Anyway. I think there are 2 kinds of 'powerful'. Yes, I can see that the Macrosystem is powerful. But in a sense the language seems 'overqualified but underskilled'. Let me explain: I basically need arrays for my work, array functions and fourier transformation (fft). I use python and i think it has much higher productivity then lisp on these fields (correct me if I am wrong). Also while the macrosystem easily allows (and probably requires) to write your own DSL, this productivity boost does not scale easily if you have a lot of ppl working on the same codebase. For Paul it didnt matter, it was two ppl only, and languages with comprehensive libraries didnt exist at that time. So if you have to build everything yourself (alone) then lisp is probably superior.
- traes 6y ago
  That's really a library problem. On a cursory glance it seems Racket supports DFTs.
  - int_19h 6y ago
    Isn't the whole point of Lisp to make everything a library problem?
- reikonomusha 6y ago
  For your first point: Yes, good quality domain-specific libraries go very far in allowing one to be productive. Lisp does not offer a good, general-purpose, integrated numerical computing environment (plotting, scientific functions, etc.) and as such wont be good for belting out scientific code. If you like DIY, then Lisp is wonderful to write scientific code in because it can compile to extremely fast code. For FFTs in particular, Common Lisp has very good support for them [1, 2, 3]. For matrix arithmetic, there’s an up-and-coming library called MAGICL [4]. As for DSLs, there’s no problem using these on a team. Their utility does scale if the DSL is actually solving a problem. [1] NAPA-FFT3 https://github.com/pkhuong/Napa-FFT3 https://github.com/pkhuong/Napa-FFT3 [2] BORDEAUX-FFT https://github.com/ahefner/bordeaux-fft https://github.com/ahefner/bordeaux-fft [3] Patrick Stein’s FFT https://github.com/nklein/FFT https://github.com/nklein/FFT [4] MAGICL https://github.com/rigetti/magicl https://github.com/rigetti/magicl

goto11 6y ago

The "Blub" parable is really clever because it says that when other people doesn't use Lisp, it is simply because they are incapable of understanding its power - not because of any practical or technical reason to chose another language. So any argument the "Blub" programmers might use to justify "Blub" is automatically invalid. Of course it can be used for any non-mainstream language, and I have seen it used for Haskell, where Lisp is the "Blub" language.

exdsq 6y ago
I’ve had this recently. Was writing Python but missed the ease of concurrent functional programming. Used F# but missed type classes. Used Haskell but missed dependant types. Use Idris but miss the build environment of Python.
- bcrosby95 6y ago
  Yes, once you learn enough languages I feel like you just find yourself constantly wishing you had aspects of another language, pretty much regardless of what language you're using. Sometimes its directly related to the language, sometimes its something like the ecosystem surrounding it. This is why I'm wary of "right tool for the job" when it comes to languages. In my experience usually there isn't a singular obvious right language. Maybe one is 35% right, another is 38% right, and the golden ticket language is actually just 45% right. And sometimes you won't really know until you're halfway through the project. If you wanted a 100% singular obvious correct language, you would have to make a custom language with traits from a dozen different ones. But in the real world, the differences between languages you can actually choose from end up being not that large.
  - AnimalMuppet 6y ago
    I think of languages as a multi-dimensional tree, with branches extending in different directions. I think that the trick is to figure out what the yak-shaving aspects of the project are going to be (which you can think of as a vector), and picking the language that goes the furthest in the direction of that vector (and thereby does the most to minimize the yak-shaving). This requires that you be able to fairly accurately determine what the yak-shaving will be up front (which can be problematic).
- whateveracct 6y ago
  > Used Haskell but missed dependant types. They're coming :)
  - exdsq 6y ago
    Oooh is there a link to the work/who’s working on it?
    - whateveracct 6y ago
      https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell ^ this has a bunch of info + external links. Richard Eisenberg is the one owning it afaiu. I think there's also a GHC branch somewhere but idr its name.
marcosdumay 6y ago
Hum... The Blub parable is really clever because it surfaces the very real problem that a programmer that don't know a language can not predict the benefits or problems of using that language. I don't see how people (you are the 3rd I see here) get the impression it's a Lisp-only comparison. PG very clearly says he has no idea what language should be on top, and even if there is a top at all. And even if he didn't, that would just make him a practical example of the paradox, and wouldn't make the idea any less valid.
- goto11 6y ago
  In context (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html) he specifically states that he think Lisp is at the top of the power continuum. The point of the Blup-parable is to explain why Lisp isn't that popular when it is so amazing.
  - marcosdumay 6y ago
    Ok, after reading it again, by "very clear" I was overstating it, but there is this note: > [4] Note to nerds: or possibly a lattice, narrowing toward the top; it's not the shape that matters here but the idea that there is at least a partial order. And in no place he says Lisp is the end-all best language. At most he compares it with other languages his competitors used on the context of Viaweb, what on the bottom of the article means C++, Java, Perl and Python. He indeed goes on to argue that any language more powerful than Lisp would be Lisp, because macros work that way. If you don't take notice that he is simplifying things into a power continuum to make a point, that can mislead you into the message that Lisp is the most powerful language. But he puts some effort into making the message language agnostic.
    - int_19h 6y ago
      Is Forth Lisp? Given that you can control the reader, everything is possible syntactically, and semantics is entirely what you make it.
      - 6y ago

skocznymroczny 6y ago

I think the problem is looking at the prism of being the most "powerful" or "expressive" language and ignoring everything around it. Go and Java programmers don't use their language over Lisp because they are masochists and enjoy the exercise of programming in a less expressive language. They choose their languages because of ease of use, large healthy ecosystems (compiler and libraries) and excellent IDE support. I sometimes see similarities in the D crowd. Because D has such advanced metaprogramming capabilities, it also suffers from parts of the Lisp curse. Too often, any criticism of D or comparison is rebuked with "but you can do it in D using this template magic and there's a package that partially implements it".

aidenn0 6y ago
I'm not saying your first sentence is wrong, but your second sentence is missing something fundamental: 1. "Ease of use" describes Go reasonably well (anyone who has used a compiled language can figure out Go tooling in minutes), but I've never found it to be true for Java. Whichever you think is better, I don't think there is a case for Maven or Gradle being an order-of-magnitude easier to use than ASDF. 2. The "large healthy ecosystem" from the libraries point of view is a silly argument for Go, since 10 years ago Lisp clearly had the larger ecosystem. Something is fundamentally different (socially, technically, or otherwise) from Lisp to Go that Go could grow the library ecosystem it has from zero in a decade, while Common Lisp could not in 25 years. 3. The "large healthy ecosystem" from the compiler point of view is silly; Lisp has 2 healthy commercial implementations (Lispworks, Allegro), 3 very actively maintained open-source implementations (sbcl, ccl, ecl), plus several other "somewhat maintained" implementations. Thats almost Java plus Go put together. 4. It's funny you mention IDE support, because tooling in general, and SLIME specifically is what keeps me using Lisp. Java actually has fairly solid IDE support, but outside of the Smalltalk world, I've never seen anything even close to SLIME in terms of being a useful IDE.

andi999 6y ago

I think I read this a while ago and tried to learn lisp (i didnt fully understand macros, only superficially). Anyway. I think there are 2 kinds of 'powerful'. Yes, I can see that the Macrosystem is powerful. But in a sense the language seems 'overqualified but underskilled'. Let me explain: I basically need arrays for my work, array functions and fourier transformation (fft). I use python and i think it has much higher productivity then lisp on these fields (correct me if I am wrong). Also while the macrosystem easily allows (and probably requires) to write your own DSL, this productivity boost does not scale easily if you have a lot of ppl working on the same codebase. For Paul it didnt matter, it was two ppl only, and languages with comprehensive libraries didnt exist at that time. So if you have to build everything yourself (alone) then lisp is probably superior.

traes 6y ago
That's really a library problem. On a cursory glance it seems Racket supports DFTs.
- int_19h 6y ago
  Isn't the whole point of Lisp to make everything a library problem?
reikonomusha 6y ago
For your first point: Yes, good quality domain-specific libraries go very far in allowing one to be productive. Lisp does not offer a good, general-purpose, integrated numerical computing environment (plotting, scientific functions, etc.) and as such wont be good for belting out scientific code. If you like DIY, then Lisp is wonderful to write scientific code in because it can compile to extremely fast code. For FFTs in particular, Common Lisp has very good support for them [1, 2, 3]. For matrix arithmetic, there’s an up-and-coming library called MAGICL [4]. As for DSLs, there’s no problem using these on a team. Their utility does scale if the DSL is actually solving a problem. [1] NAPA-FFT3 https://github.com/pkhuong/Napa-FFT3 https://github.com/pkhuong/Napa-FFT3 [2] BORDEAUX-FFT https://github.com/ahefner/bordeaux-fft https://github.com/ahefner/bordeaux-fft [3] Patrick Stein’s FFT https://github.com/nklein/FFT https://github.com/nklein/FFT [4] MAGICL https://github.com/rigetti/magicl https://github.com/rigetti/magicl