A steep learning curve means effectively more power. And that means responsibility. If modularization means separation of concerns, and thus less responsibility, lack of power is largely mitigated, but it puts the responsibility on the s/w-architects.
Just like LISP's strength supposedly is revealed when it's the whole OS. And as they say, any involved program will contain an ad-hoc implementation of LISP :)
C, eg., also resembled the hardware architecture more closely. With concurrent programming, though, we see more functional influences creep into the staple languages. It's the other way around with Haskell's do notation.
Anyway, as a research project, it is rather academic. Therefore it is often not backwards compatible, which is an immediate show stopper and also shows that it's far from finished, due to its bigger goals.
Most somewhat experienced developers could pick up Golang in a day or two, having come from C++/Java, but learning Haskell is much more daunting, at least in my personal experience. I don't feel like Golang really brings anything new to the table, it just takes away stuff, which isn't a bad thing.
However, learning Haskell was really eye opening to me, and yet, even a year later, I feel somewhat comfortable writing code but I am only beginning to try to learn performance analysis and think about laziness. I mean, imagine hiring someone who's only used imperative languages and telling them to start writing code that doesn't use for loops or if statements which don't have corresponding else statements.
A language really shouldn't require its language-specific glossary to be mandatory reading, just to understand anyone speaking about it. I could just learn any other language in half the time!
from the above comments
> "I have this pure function that I want to apply to the inner value of my functor"
pure function I know well enough, that is the same for any language, functors though... is that a function object that can be applied to something? then why does it already have a value?
I can take terminologies from C, to python, or C#, and feel a-okay, but haskell kinda feels like it went and shut it self away from the world, and its terminology developed differently due to that, I guess.
Haskell uses a lot of terms specifically from Category Theory. People in the J community are very mathematically inclined, and usually work on different fields of mathematics. I am working on geometric algebra (Clifford Algebra) in J.
I find the J documentation much more friendlier than Haskell's docs.
And J has several IDE's that come bundled with it: JQT - a QT Gui with syntax highlighting, a help section, a minimalist project structure; JHS - a web-based IDE with hooks to D3 vs. the standard plot in JQT; and there is a Python-based IDE (JQide).
There are labs that walk you through chapter-based examples in the interpreter's REPL. One of the newer labs uses videos that go along with the lab in the console, all part of the J ecosystem.
I personally think that Haskell will maintain that purity of purpose, and not get diluted enough to be picked up by the average coder. Even J remains obscure after decades too, but I am hoping that all of the array hoopla (GPUs, big data, machine learning) will bring it to the forefront as a more natural fit, since its native unit and structure is based upon arrays.
Haskell is radically different for people