I think when programmers are introduced to languages, most grok procedural ones easier than functional ones, hence Lisp and its derivatives have struggled in popularity for decades.
From what I've understood about Haskell is that it allows you to divide your program into parts which are either pure functional, or mutable. That is great when you read the program, you can know that what you are reading now is immutable, whereas in the some other well designated parts it is mutable.
But with Lisps isn't it the case that statement 1 can be immutable while the next statement 2 is mutable? In other words it mixes mutable and immutable calls into the same program-file without really isolating them from each other in any way. And that means if one part of the program is "impure", so is all of it. You can't isolate those parts except by following a convention, but conventions are not something that it enforces. And you can't know which parts of your program are pure except by reading the code-statements in detail. Am I right?
I have been thinking about the reason why Lisps aren't more popular today. I'm not sure yours is the right reason though. It seems like the statement you make would be no more true today than in the 80s, when Lisp was much more popular.
Ultimately I think it might just be fads. Object oriented programming came along at the same time as the web, when the demand for programmers grew dramatically. That may have crystallized OO and imperative languages as the "default" style. Would be interesting to see the alternate universe where JavaScript actually was a Lisp.
JavaScript has been called "Lisp in C's clothing". JavaScript is not a "pure" functional language but are any of the Lisps either? They might have immutability as the default. But I don't see why an Object-Oriented language could not have immutability as the default as well?
Back in the 80s we had logo, that was super popular and a common way a lot of people (kids) learned programming, the birth of turtle graphics! That repl way of programming and getting visual results was really good. I think the biggest problem was that none of those languages were the languages for making games.
When I teach I constantly tell them to start with data and hard coded, literal data representations, this seems to make it rather easy to get used to a functional style.
