I'm curious about the claim that it only takes a few days to get people productive working in Haskell. I like the language a lot, but learning it has definitely been slow compared to any other language I've learned. It just seems like there are a lot of changes to how you think.
Is this a feature of the way your code is structured that simplifies what people have to understand about the language before they can contribute?
To be fair to the OP, the original claim was: "People who have prior functional programming knowledge seem to find their stride in just a few days." I would be somewhat surprised if someone with no prior functional programming experience could be productive in a few days in Haskell, because as you say, there are a lot of changes to how you think about programming. It's a lot easier for people with experience in a Lisp, and even easier yet for people with experience in another ML descendant.
All that said, the structure of the code definitely does help a lot in lowering the bar for contributions. When Don Stewart was on the Haskell Cast [1], he mentioned that the way they use Haskell allows contributions from people who not only have no prior functional experience but who have little CS background at all past basic programming literacy. Much of the ability to do this comes from Haskell's rigorous isolation of side effects.
I probably should have been more explicit: I use higher order functions and recursion all over the place in higher level languages that I use, so I'm familiar with parts of functional programming. But structuring impure programs in Haskell still has taken a long time to get used to (and I'm not great at it yet).
I work with Andy, the author. I watched the Haskell push from the sidelines and did not learn it until well after it had already gained momentum. My intend behind not learning the language was to retain empathy with people who hadn't yet gone through the spin-up.
When I finally got around to learning Haskell, I found myself able to productively make small changes within a few days. A lot of the more... idiomatic? uses of Functor and Applicative took another week or so to learn. The books Learn You a Haskell and Real World Haskell were helpful there.
I am by no means an expert at Haskell now, but within a few weeks I was able to contribute to most areas of the stack.
I think it's easier in general to work on an application that's up and running . Architecting a new system in a language you're new to would be much more time consuming. But in the case where the groundwork is laid you get by with much less language depth. Recent someone posted on here about how financial analysts were able to use a subset of Haskell in the field without really having to think of it as programming at all, as all the plumbing under the DSL is covered up.
This is very true in every language, and doubly so in Haskell. If you just take the language as it is without any context, the language leaves whole classes of problems with a ridiculous overabundance of potentially viable solutions.
The one that springs to mind most prominently is error handling. What's the right way to do this? Option types? Exceptions? EitherT? We even explored a library that used type classes to provide Java-style checked exceptions.
We sorted this out early, when the "team" was just 2 people working in extra hours, but if we'd still been in that state when we scaled up, the project would have been a disaster.
FYI, the solution we came up with was to use option types for all recoverable errors. We only use exceptions for nonrecoverable failures that should trigger production alerts.
I've been learning haskell for the better part of 8 years. I say learning, because I spend far too much time trying to study the patterns and math from the abstract point of view. Every few months I print off a research paper and struggle with it for a few days until I get it. I never get to code large projects in it because no one uses it in industry up in the north.
I can code in the language no problem but sometimes I feel that idiomatic ideal is always just out of reach to all but the Simons.
Is this a feature of the way your code is structured that simplifies what people have to understand about the language before they can contribute?