Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with.

If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more formally defined beasts fed by mathematical concepts. That's one trend I expect to continue, but then also not ad infinitum. In my view, Haskell is a good example of how you can overdo it, with the best intentions: concepts that are beautiful and frictionless in pure math become a cumbersome burden and an impractical cognitive load when translated too directly into a PL. I want more math in PLs, but I feel we haven't found a good balance yet. Maybe this turns out to be a moving target, too.

There are two languages I expect to keep their (niche) places for the foreseeable future: C and Lisp. Both are such a peculiar mix of properties that they are incredibly hard to beat in their respective domains. Maybe the same goes for Ada and Java, I wouldn't want to do any injustice :)

Haskell isn't "overdone". It's extremely principled and requires that, for example, you put the existence of stateful effects (e.g. I/O) in the type system. It requires you to specify state (to a degree, and with escape hatches); it doesn't eliminate it.

Haskell isn't that much of an investment when you consider what is gained. See, learning any new code base takes 3-6 months, and if the code is great, you learn a lot. If the code is garbage, well... perhaps you learn what not to do. Compared to the slog of learning a new corporate codebase, the effort involved in learning Haskell isn't that much... and the hope with Haskell is that the next software project you write won't be unmanageable... and I think that even average-case Haskell realizes it. (I focus on the average case because, of course, you can write shitty code in any language and you can write good code in any language, but languages differ in what tends to happen on average.)

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice.

I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful like all the mathematics that I love. But then I try to use it and, objectively, I get less done (even though I knew what an endofunctor was before even seeing Haskell!).

My longest stretch of trying to use Haskell every day was about 3 months at which point I was still substantially less productive than my preferred mix of C/Python/Lua (I mainly do heavy-lifting numerical work coupled with low-latency server designs). I also feel like I get more done in OCaml.

So, you being someone whom I identify as similar in skills to myself, I ask you: what gives? :-)

Well, depending on your problems, Haskell may simply not be the correct answer. It shines complex behavior for example, but "numerical work" normally means simple behavior (but highly optimized), and I'd be wary of it on low latency applications.

Haskell is powerful, but won't solve all the problems on the world.

To give a rebuttal to Haskell not being good for "numerical work", you might be interested in this pre-alpha numerics library:

https://github.com/wellposed/numerical#performance-faq

I'm tempted to agree with you re: low latency, then I run across stuff like this:

https://github.com/tomahawkins/atom

I believe it (or a similar library) are used in quite a few of a certain companies (or multiples) flagship applications, though I can't recall the details.