[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.

[int_19h]

> I imagine a serious lisper would be offended by the suggestion (because, well, ergonomics matter)

Curiously, it did come up in the context of ergonomics in another discussion thread:

https://news.ycombinator.com/item?id=23178953

[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.