Hacker News new | ask | show | jobs
by werpon 4890 days ago
I've invested a lot of time in trying to learn Haskell properly.

On one hand, it's incredibly rewarding when a completely new and strange concept finally 'clicks', then you write a few lines to test your understanding and it just works.

On the other hand, it's frustrating to realize that there are still a lot of concepts you don't fully grasp, several libs that are still out of your reach, yet another completely new way of structuring your code that you are yet to unravel. Essentially, that you are (I am) still a newbie.

All in all, I find Scala better suited to learning FP and applying your newly-acquired knowledge to develop mildly useful apps, as quick results usually lead to more motivation. Just IMHO.

(Not to mention there are many libs that aren't yet up to par with their JVM counterparts, but that's another can of worms.)

2 comments

One of the things I like about Haskell is that there's never scarcity of new concepts to learn: Functors, Applicatives, Monoids, Monads, Monad transformers, Comonads, Arrows, Lenses, Foldables, Iteratees... And every one of these has a world in itself!
On the other hand, that one time you just need a simple library for something, you get to use some guy's pet experiment for learning one of these concepts (Monoids, Monads, Monad transformers, Comonads, Arrows, Lenses, Foldables, Iteratees, Functional-Reactive Programming) you haven't learned yet just to parse some XML.

Yeah, a real productivity booster. It's like batteries included but with C4 attached to every battery.

Sometimes, people have work to do.

Yeah, those tricky monoids. So hard to learn, and even harder to use a library based on them. You have a whole whopping one function to learn, that does some incredibly convoluted and arcane nonsense called "appending"? What a horrible language. You should definitely devote more time to complaining about ridiculous strawmen like this, it seems like a very good use of time.
Here is some of my code to parse html:

    tstamp <- this ! "data-timestamp" >>> arr parseTime -< el
    (path, score) <- css "td[class~=score-time] a" >>>
        (this ! "href") &&& (getAllText >>> arr parseScore) -< el
So yes, you do have to learn about arrow syntax in order to use HXT efficiently. For most newbies it is not an easy concept to grasp, not helped by the fact that HXT isn't a very well documented library.

    tstamp <- this ! "data-timestamp" >>> arr parseTime -< el
This, on the other hand, is one of the thing I don't like about Haskell: there are 4 operators on this line, and no easy way to see, at a glance, their precedence. Also, some operators are "mentally interpreted" as flowing data left to right or right to left; changing the direction mid-statement, I find confusing. I have the same problem when unix shell commands are expressed like this:

    program < input > output
"Use >>> like a pipe in unix" is not an easy concept to grasp?
I shouldn't have to learn what parser combinators are to just rip a few things out of a tree of XML.
Good, good. Now take it to the next level. Rather than just using a scary word that means something very ordinary and mundane, try making up totally nonsense combinations. Like "I shouldn't have to learn co-recursive monomorphic functoid transformers just to open a file!".
I personally find the "universe of knowledge" to attain an attraction, not a repellent.
I guess it depends in what context you're looking at it. What makes Java so successful is its simplicity. You can get fairly quickly up to speed on it, and you can have junior coders on it producing code quickly without shooting themselves in the foot too much or spending a couple of hours trying to find out how to update a tree efficiently.

On the other hand, as a hobbyist, it's absolutely fantastic.

In the case of Java, the simplicity of language leads to complexity of programs.

The extra difficult-to-learn parts of Haskell makes for programs that are more practical, shorter and easier to work with.

There's a trade-off between simplicity and power - and we don't really want to maximize simplicity only. And if we did, Java would not be a good candidate either.

But many dev shops just want a pool of cheap labour and care little about robustness. And the abundance of cheap labor is a function of both learning curve and critical mass.

I gather this is not a design goal of a language with "avoid success at all costs" as an unofficial motto