[jhbadger]

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]

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.

[marcosdumay]

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]

In context (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]

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]

Is Forth Lisp? Given that you can control the reader, everything is possible syntactically, and semantics is entirely what you make it.

[marcosdumay]

I would say it fits his description (but well, I'm also quick to dismiss it all because ergonomics matter), so it's at least equivalent in power. I have no idea what he would say, I imagine a serious lisper would be offended by the suggestion (because, well, ergonomics matter), but would take a while to even understand why.

[exdsq]

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]

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]

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]

> Used Haskell but missed dependant types.

They're coming :)

[exdsq]

Oooh is there a link to the work/who’s working on it?

[whateveracct]

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.

[skocznymroczny]

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]

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]

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.

[reikonomusha]

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

[2] BORDEAUX-FFT https://github.com/ahefner/bordeaux-fft

[3] Patrick Stein’s FFT https://github.com/nklein/FFT

[4] MAGICL https://github.com/rigetti/magicl

[andi999]

Thanks. Just to clarify on the dsl remark: dsl work of course, but usually it is a two tier approach. First the dsl is designed and implemented, then the (other) team works with it on the main application. So far it looked to me (especially from Paul Grahams article) that in lisp usually these two phases are mixed, but i might misunderstand this.

[traes]

That's really a library problem. On a cursory glance it seems Racket supports DFTs.

[int_19h]

Isn't the whole point of Lisp to make everything a library problem?