> Then, of course you work with Haskell for a bit and end up going back to whatever you started with

Why do you think that? Haskell sees pretty widespread industry usage these days.

In my experience Haskell is exactly what one of it's creators called it "a DSL for writing DSls". Elm can be viewed as one of such dsl, occam razor focused on web front-end. Otherwise,90% of the time you are stuck in IO along with some really hard to grasp libs to help your pl learnings and rarely anything else

I'm not really sure what you're trying to get at? While, sure, Haskell excels at making (e)DSLs, it's far from the only usage for it. For web development it's quite good as well, a long with a ton of other areas. There are plenty of practially oriented libraries, and at the same time, also plenty of libraries focused on using as much of the advanced type system as possible.

I'm not really sure what you mean by "stuck in IO" but that's a consequence of laziness so it's pretty much unavoidable in FP in general.

As for "hard to grasp libs," I find them much easier to use than C libraries. They're actually quite well suited to certain domains.

This is simply not true.

I think you're mistaking Haskell for Lisp?

> Haskell sees pretty widespread industry usage these days.

Yes, just for one example:

https://www.reddit.com/r/haskell/comments/86cg1u/jobs_obsidi...

Did you have to link to a 5 months old post? :)

Each week some new job gets posted on r/haskell.

I linked to this one because it is relevant to Elm, also because I now work here :)

Reminder that lisps are FP too.

Depends on which lisp and who you ask.

For many, functional programming is just as much about expressive type systems, purity, and immutability as is about robust first-class funtions and higher order functions.

Lisp is like the python version of Haskell (as compared to Java I guess?) It's a rough metaphor but I think it makes enough sense.

I know that many today use "functional" to mean ML-derived languages but that definition is incorrect.

Lisps are not very much like Haskell at all, and have different goals. Which is why today's ML-centric worldview of functional programming so often forgets about them.

JS is a bad lisp

Why do you include Reason? Reason is just an alternate syntax for OCaml which has a "fancy" type system like Haskell or purescript.

Well, typeclasses and monads are not easy to implement in ocaml, to the best of my knowledge

We use monads extensively (with monad syntax provided by the ppx_let extension) and OCaml also has a sophisticated module system that is useful in a similar way that type classes are. I would say type classes and a good module system are essentially incomparable language features though, and programming in Haskell always feels painful to me once you get to a few files without modules.

monads are; there's just no syntactic support for them in the language, so they're a little clunkier to work with than they are in haskell

I am currently employed full-time writing Haskell.

Laziness is a superficially useful anti-feature.

I'd suggest waiting with OCaml until dependently-typed languages become more practical.

This is simply false. One can debate laziness as a default, but pure immutable languages need laziness.

> pure immutable languages need laziness

https://mercurylang.org/

If you put the most valuable thing in the universe inside a box that can't be opened or permeated by any force in the universe--then that thing is no longer valuable. Go find the former #2. If you have a programming ideal and that ideal requires laziness--then you've messed up. You have to conclude that there was something flawed about the ideal.

I'm a lot more confident about laziness being bad than about what you're thinking of as "a pure immutable language" being bad, but part of the problem about laziness is that it's a feature apart from the language it's in. If you implement a cache with a hash table in any normal language, then you can later on check and see how much data you have cached, keep track of your cache hit rate, empty the cache, pre-load your cache from a previous run, and so on. To work with your cache, you have the language itself at your disposal. If you implement a cache with a lazy list in language X, then language X can't help you. You'll need to hope that whatever Gods dangled laziness before you, also have some tools dangled elsewhere.

> If you put the most valuable thing in the universe inside a box that can't be opened or permeated by any force in the universe--then that thing is no longer valuable. Go find the former #2. If you have a programming ideal and that ideal requires laziness--then you've messed up. You have to conclude that there was something flawed about the ideal.

Not at all what I am talking about.

Please consult the literature on the subject and then we can continue this conversation as equals.

> I'll just bet that you haven't read anything, because you disagree with people I think are, like, super-duper smart :)

Maybe if I read enough Foucault, or drink enough bleach, we'll be able to continue this conversation as equals :)

> I'll just bet that you haven't read anything, because you disagree with people I think are, like, super-duper smart :)

It is quite obvious from what you have said you are not aware of the literature surrounding laziness.

Please do not cross into incivility regardless of how wrong someone is or you feel they are.

https://news.ycombinator.com/newsguidelines.html

Yeah, there's no amount of bigoted "Haskell uber alles" posturing that can replace a simple, supported argument. None of the reading you think you've done, and I haven't, has succeeded in distinguishing your output from that of a complete poser.

Please don't become uncivil on HN, regardless of who started it or did it worse.

https://news.ycombinator.com/newsguidelines.html

Why do you think so? I don't even remember the last time that I used lazyness myself. Not to mention that there are other pure functional languages (such as Idris) that are strict.

You can consult Okasaki's thesis (regrettably it is somewhat out of date) for a list of functional data structures. Some of them are lazy, some of them are strict. But being able to use all them is essential to getting good asymptotic complexity.