4 ms·

This is neat and I love CF workers. But man - Haskell feels really difficult to wrap my mind around. Could anyone here comment on the learning curve and how i

This is neat and I love CF workers. But man - Haskell feels really difficult to wrap my mind around. Could anyone here comment on the learning curve and how it affected productivity for team adoption? Seems like it's on the more difficult side of things.

openfuture 6y ago
Idk, if you just denote your statespace with the types and then have all your code essentially perform case analysis then it's quite simple... There are some tricks that you need to express more complicated computation but they get more attention than use. Also there is the whole type theory rabbit hole that you'll fall down a few times until you understand where you want to be. The trick is to accept that the model is a simplification and rather than being as precise as possible find out where you can get away with simplifications.
jeremyjh 6y ago
It took me about six months to feel really comfortable after working on toy projects and libraries a few hours a week. I published a library that is still being used by others after only 2-3 months and looking at it now I still think it was done relatively well, though it was basically a simple wrapper. I began by reading the entire "Learn You a Haskell" book which is probably the best introductory book I've read about any programming topic, and then most of Brian O'Sullivan's "Real World Haskell". There are better sources than the latter now, which was outdated at the time (~2014). Of course, focused full time or at least half time it would not take nearly this long for a team to come up to speed as long as they have at least one really strong member from the start. I'd say people could become productive in a couple of weeks in those circumstances; which is still much longer than pretty much any other language that is actually used in industry.
MaxGabriel 6y ago
Learning curve is fairly steep, but very doable if you join a good team who doesn’t make things too complicated. Productivity is lower initially but much better on maintenance/refactoring. Overall I’d recommend it! Experience: Mercury (bank)‘a backend is 100% Haskell
bnchrch 6y ago
I’ve been through the Haskell learning curve. Long story short it’s awful and in my opinion not worth the pain. I think Haskells problems breakdown into 3 distinct areas. The community, the conventions and the language itself. Firstly the community can be hostile to a new comer. The documentation and tutorials for various libraries is often incomplete, outdated and written in a hard to grok plain text document. Asking questions can also be painful as there’s definitely a tinge of elitism to some of the power members. Secondly, the conventions that are often encouraged go against writing clear and understandable code. Function names are small. You have interface functions (doThis) that exist just to call private functions (doThis’). These odd conventions get compounded by a lot of warts on the language itself. So finally onto the language itself. There’s a lot of operators to keep track of. None of which do what you expect. And the ones you do expect, like dot notation, don’t exist until you turn on a language feature flag. For feature flags there’s a standard set of 20 that every experienced Haskeller turns on but good luck finding that out as a beginner, and good luck finding out that’s why the example isn’t working for you. There’s also 3 different types of String, all of them in active use by different libraries, which you have to manually cast between often. And the dev environment can be hard to figure out. Error messages are difficult to grok. The repl often breaks. And you sometimes run into hidden libraries that are in your project but arent accessable until you import them. Honestly it’s a mess and this is before I touch on the unique parts of a pure functional language like Haskell. Which is a shame because Haskell brings to the table some serious super powers. They’re just not worth the hit to developer productivity in a team setting.
- tome 6y ago
  Hi, thanks for sharing your experience with Haskell! Sorry to hear it wasn't a pleasant one. There is no overall authority in the Haskell world so I'm taking it upon myself to improve the experience of Haskell developers where I can[1]. If you would be happy to expand about the things you struggled with I would be very interested to hear concrete details, either here or on my issue tracker[2]. The things I am curious about are: > The documentation and tutorials for various libraries is often incomplete, outdated and written in a hard to grok plain text document I am keen to make an effort to remove outdated documentation and to complete incomplete documentation. If you give specific examples I shall try to do so. > Asking questions can also be painful as there’s definitely a tinge of elitism to some of the power members. Could you say which forums you discovered "elite power members"? For example, was it Reddit, Haskell-Cafe mailing list, #haskell IRC channel, Discord server? > Secondly, the conventions that are often encouraged go against writing clear and understandable code. Function names are small. You have interface functions (doThis) that exist just to call private functions (doThis’). For better or worse, that's the way the community likes to program. I'm not sure there's much I can do about that unless you have specific examples of code that could be rewritten to be clearer. > These odd conventions get compounded by a lot of warts on the language itself. Did you have any specific warts in mind? > For feature flags there’s a standard set of 20 that every experienced Haskeller turns on but good luck finding that out as a beginner, and good luck finding out that’s why the example isn’t working for you. Were there specific "feature flags" (called "extensions" in GHC) that you needed to turn on but that the compiler didn't tell you that you needed to turn on? That's uncommon (though it is possible, OverloadedStrings is one such example). Which examples did you try that didn't work because they didn't mention which extensions needed to be enabled? If you report them to me I will try to get them fixed upstream. > The repl often breaks Could you say more about in which way the repl ("GHCi") often breaks? > And you sometimes run into hidden libraries that are in your project but arent accessable until you import them. Could you say more? That sounds like something that could well be true but I can't see how it's a problem. You have to import libraries in many languages (Julia, Python, ...). What went wrong here? Thanks for any light you may be able to shed. [1] https://github.com/tomjaguarpaw/tilapia/ https://github.com/tomjaguarpaw/tilapia/ [2] https://github.com/tomjaguarpaw/tilapia/issues/new https://github.com/tomjaguarpaw/tilapia/issues/new
mrkeen 6y ago
Love it - very few languages come close to it. I miss it when I'm using Java/Scala/Rust/C/JS instead. But there's no way you could get a team to adopt it. Too many non-Haskellers will make up claims about needing to know category theory in order to do anything. Or it's academic, or design-by-committee. Someone commented earlier about Haskell having solutions to problems that only Haskell has, and I can give you a couple of examples: 1) Famously it has the Maybe type - instead of null - for dealing with possibly-missing values. In Haskell, if you want to chain together operations without checking for the presence of each value, you use ">>=". As many people have noted before, this is a cryptic symbol. You can just use JavaScript instead which has ".?". 2) It has mechanisms for cleaning up resources in the case you want to cancel something while it's running, notably ResourceT. Other languages take the approach where you simply cannot cancel a thread/future, thus preventing you from needing to write cleanup code in the first place. There's also the problem of its community. Rather that accept information second-hand I invite you to read a few posts from https://www.reddit.com/r/haskell/ https://www.reddit.com/r/haskell/ and see for yourself how it treats newcomers. I should also mention the type system. As any dynamic typing enthusiast will tell you, statically-typed languages are too verbose. And Haskell is too terse. So it kind of loses on both fronts there. You'll need to contend with people who don't like type systems because they get in your way, rather than helping you out. When I'm feeling lazy and I can't think of what to write, I just write "Int" instead and then let the compiler tell me what I was supposed to write, e.g. "Topic -> SequenceNum -> Value -> IO a0". src/Server/Paxos/Learner.hs:41:68: error: • Couldn't match expected type ‘Topic -> SequenceNum -> Value -> IO a0’ with actual type ‘Int’ • In the third argument of ‘learnService’, namely ‘callback’ In the second argument of ‘(.)’, namely ‘learnService myId topicLocks callback’ In the ‘learn’ field of a record | 41 | pure $ Learner { learn = liftIO . learnService myId topicLocks callback } | God knows how I managed to read that cryptic error message though.
1-more 6y ago
I also endorse Learn You a Haskell. I learned it after learning Elm which is WAY easier due to not having to content with an absolutely outrageous number of custom operators in Haskell.

openfuture 6y ago

Idk, if you just denote your statespace with the types and then have all your code essentially perform case analysis then it's quite simple... There are some tricks that you need to express more complicated computation but they get more attention than use. Also there is the whole type theory rabbit hole that you'll fall down a few times until you understand where you want to be. The trick is to accept that the model is a simplification and rather than being as precise as possible find out where you can get away with simplifications.

jeremyjh 6y ago

It took me about six months to feel really comfortable after working on toy projects and libraries a few hours a week. I published a library that is still being used by others after only 2-3 months and looking at it now I still think it was done relatively well, though it was basically a simple wrapper. I began by reading the entire "Learn You a Haskell" book which is probably the best introductory book I've read about any programming topic, and then most of Brian O'Sullivan's "Real World Haskell". There are better sources than the latter now, which was outdated at the time (~2014). Of course, focused full time or at least half time it would not take nearly this long for a team to come up to speed as long as they have at least one really strong member from the start. I'd say people could become productive in a couple of weeks in those circumstances; which is still much longer than pretty much any other language that is actually used in industry.

MaxGabriel 6y ago

Learning curve is fairly steep, but very doable if you join a good team who doesn’t make things too complicated. Productivity is lower initially but much better on maintenance/refactoring. Overall I’d recommend it! Experience: Mercury (bank)‘a backend is 100% Haskell

bnchrch 6y ago

I’ve been through the Haskell learning curve. Long story short it’s awful and in my opinion not worth the pain. I think Haskells problems breakdown into 3 distinct areas. The community, the conventions and the language itself. Firstly the community can be hostile to a new comer. The documentation and tutorials for various libraries is often incomplete, outdated and written in a hard to grok plain text document. Asking questions can also be painful as there’s definitely a tinge of elitism to some of the power members. Secondly, the conventions that are often encouraged go against writing clear and understandable code. Function names are small. You have interface functions (doThis) that exist just to call private functions (doThis’). These odd conventions get compounded by a lot of warts on the language itself. So finally onto the language itself. There’s a lot of operators to keep track of. None of which do what you expect. And the ones you do expect, like dot notation, don’t exist until you turn on a language feature flag. For feature flags there’s a standard set of 20 that every experienced Haskeller turns on but good luck finding that out as a beginner, and good luck finding out that’s why the example isn’t working for you. There’s also 3 different types of String, all of them in active use by different libraries, which you have to manually cast between often. And the dev environment can be hard to figure out. Error messages are difficult to grok. The repl often breaks. And you sometimes run into hidden libraries that are in your project but arent accessable until you import them. Honestly it’s a mess and this is before I touch on the unique parts of a pure functional language like Haskell. Which is a shame because Haskell brings to the table some serious super powers. They’re just not worth the hit to developer productivity in a team setting.

tome 6y ago
Hi, thanks for sharing your experience with Haskell! Sorry to hear it wasn't a pleasant one. There is no overall authority in the Haskell world so I'm taking it upon myself to improve the experience of Haskell developers where I can[1]. If you would be happy to expand about the things you struggled with I would be very interested to hear concrete details, either here or on my issue tracker[2]. The things I am curious about are: > The documentation and tutorials for various libraries is often incomplete, outdated and written in a hard to grok plain text document I am keen to make an effort to remove outdated documentation and to complete incomplete documentation. If you give specific examples I shall try to do so. > Asking questions can also be painful as there’s definitely a tinge of elitism to some of the power members. Could you say which forums you discovered "elite power members"? For example, was it Reddit, Haskell-Cafe mailing list, #haskell IRC channel, Discord server? > Secondly, the conventions that are often encouraged go against writing clear and understandable code. Function names are small. You have interface functions (doThis) that exist just to call private functions (doThis’). For better or worse, that's the way the community likes to program. I'm not sure there's much I can do about that unless you have specific examples of code that could be rewritten to be clearer. > These odd conventions get compounded by a lot of warts on the language itself. Did you have any specific warts in mind? > For feature flags there’s a standard set of 20 that every experienced Haskeller turns on but good luck finding that out as a beginner, and good luck finding out that’s why the example isn’t working for you. Were there specific "feature flags" (called "extensions" in GHC) that you needed to turn on but that the compiler didn't tell you that you needed to turn on? That's uncommon (though it is possible, OverloadedStrings is one such example). Which examples did you try that didn't work because they didn't mention which extensions needed to be enabled? If you report them to me I will try to get them fixed upstream. > The repl often breaks Could you say more about in which way the repl ("GHCi") often breaks? > And you sometimes run into hidden libraries that are in your project but arent accessable until you import them. Could you say more? That sounds like something that could well be true but I can't see how it's a problem. You have to import libraries in many languages (Julia, Python, ...). What went wrong here? Thanks for any light you may be able to shed. [1] https://github.com/tomjaguarpaw/tilapia/ https://github.com/tomjaguarpaw/tilapia/ [2] https://github.com/tomjaguarpaw/tilapia/issues/new https://github.com/tomjaguarpaw/tilapia/issues/new

mrkeen 6y ago

Love it - very few languages come close to it. I miss it when I'm using Java/Scala/Rust/C/JS instead. But there's no way you could get a team to adopt it. Too many non-Haskellers will make up claims about needing to know category theory in order to do anything. Or it's academic, or design-by-committee. Someone commented earlier about Haskell having solutions to problems that only Haskell has, and I can give you a couple of examples: 1) Famously it has the Maybe type - instead of null - for dealing with possibly-missing values. In Haskell, if you want to chain together operations without checking for the presence of each value, you use ">>=". As many people have noted before, this is a cryptic symbol. You can just use JavaScript instead which has ".?". 2) It has mechanisms for cleaning up resources in the case you want to cancel something while it's running, notably ResourceT. Other languages take the approach where you simply cannot cancel a thread/future, thus preventing you from needing to write cleanup code in the first place. There's also the problem of its community. Rather that accept information second-hand I invite you to read a few posts from https://www.reddit.com/r/haskell/ https://www.reddit.com/r/haskell/ and see for yourself how it treats newcomers. I should also mention the type system. As any dynamic typing enthusiast will tell you, statically-typed languages are too verbose. And Haskell is too terse. So it kind of loses on both fronts there. You'll need to contend with people who don't like type systems because they get in your way, rather than helping you out. When I'm feeling lazy and I can't think of what to write, I just write "Int" instead and then let the compiler tell me what I was supposed to write, e.g. "Topic -> SequenceNum -> Value -> IO a0". src/Server/Paxos/Learner.hs:41:68: error: • Couldn't match expected type ‘Topic -> SequenceNum -> Value -> IO a0’ with actual type ‘Int’ • In the third argument of ‘learnService’, namely ‘callback’ In the second argument of ‘(.)’, namely ‘learnService myId topicLocks callback’ In the ‘learn’ field of a record | 41 | pure $ Learner { learn = liftIO . learnService myId topicLocks callback } | God knows how I managed to read that cryptic error message though.

1-more 6y ago

I also endorse Learn You a Haskell. I learned it after learning Elm which is WAY easier due to not having to content with an absolutely outrageous number of custom operators in Haskell.