4 ms·

This matches my experience. At the company I work at, we use Haskell for HTTP services. The software stack we've grown is extremely opinionated about how to d

This matches my experience. At the company I work at, we use Haskell for HTTP services. The software stack we've grown is extremely opinionated about how to do things. We provide just one way to do things like report errors, run queries, do work asynchronously, and so forth. We get people up and running with about the same amount of effort as we spend getting people going on our PHP, and I think a big part of the reason why is because we're able to constrain the education effort to the slice of Haskell that we want them to read and write. For instance, we accept the fact that we have new teammates who haven't yet truly understood what "do" blocks are all about. These people are nevertheless able to write perfectly serviceable, production-ready code. They've learned that they can chain imperative actions together in a particular way, and that's enough for awhile. Deep understanding comes later.

kornish 11y ago
Two questions - first, did you reply to the wrong comment? Seems like you might've meant to reply to thinkpad20's comment, which is about not needing to know everything to be productive. Second - where do you work?
- implicit 11y ago
  I'm at IMVU. We're hiring! :) http://www.imvu.com/jobs/index/ http://www.imvu.com/jobs/index/ I intended to react to the comment "But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast." I think this is true. There are too many ways to do everything in Haskell and they're changing too often. If you don't get very specific guidance, you're going to be totally paralyzed with indecision. I have good evidence that you can do very well by confining the solution space.
  - kornish 11y ago
    Nice! How long have you been there? It'd be interesting to hear how things have gone running Haskell in prod (and hiring, and such) since your guys' blog post in March of 2014. Gotcha. It also doesn't help that many of the canonical learning materials (e.g. LYAH, or Real World Haskell) are slowly drifting out of date.
vvanders 11y ago
Sounds very similar to approaches we've taken with C++ with a team that largely didn't have C++ experience(~15 devs, 2-3 C++ "experts", I use the term losely). Also similar to the approach DropBox said they use with their cross-platform C++ code form a talk a while back. In cases like this I feel like convention does a good job of keeping a codebase from spawling out into using every feature of the language.

kornish 11y ago

Two questions - first, did you reply to the wrong comment? Seems like you might've meant to reply to thinkpad20's comment, which is about not needing to know everything to be productive. Second - where do you work?

implicit 11y ago
I'm at IMVU. We're hiring! :) http://www.imvu.com/jobs/index/ http://www.imvu.com/jobs/index/ I intended to react to the comment "But when I try to dip my toe back into the Haskell community, a wave of despair washes over me. There's just too much. Haskell is changing too fast." I think this is true. There are too many ways to do everything in Haskell and they're changing too often. If you don't get very specific guidance, you're going to be totally paralyzed with indecision. I have good evidence that you can do very well by confining the solution space.
- kornish 11y ago
  Nice! How long have you been there? It'd be interesting to hear how things have gone running Haskell in prod (and hiring, and such) since your guys' blog post in March of 2014. Gotcha. It also doesn't help that many of the canonical learning materials (e.g. LYAH, or Real World Haskell) are slowly drifting out of date.

vvanders 11y ago

Sounds very similar to approaches we've taken with C++ with a team that largely didn't have C++ experience(~15 devs, 2-3 C++ "experts", I use the term losely). Also similar to the approach DropBox said they use with their cross-platform C++ code form a talk a while back. In cases like this I feel like convention does a good job of keeping a codebase from spawling out into using every feature of the language.