10 ms·
As a counterpoint - at CircuitHub, we migrated from NodeJS / Angular to Haskell / Elm and couldn't be happier. I think a core reason for our success is that we
by seddona 7y ago
As a counterpoint - at CircuitHub, we migrated from NodeJS / Angular to Haskell / Elm and couldn't be happier.
I think a core reason for our success is that we built our team from experienced developers that had built large applications in other languages. Then arrived at Haskell as a better solution.
I have heard some negative experiences that I would attribute to a few different factors.
1. Lack of Haskell experience in the early team.
2. Lack of experience building large real-world applications (too academic)
3. The startup/group didn't achieve product-market fit, and Haskell was scapegoated.
None of these problems are Haskell specific, just run of the mill team issues.
- sokoloff 7y agoHow common is it for the same person to have both strong Haskell experience and experience building large real-world applications? I’ve tried to find a way to use Haskell (lacking strong experience there, but with lots of large app experience), and I’ve not managed to find a situation where pulling the trigger makes sense because of the risk of getting “stuck” with a poor path out.
- FpUser 7y agoIn tech world languages are like a religion. Their choice does not really have to make sense. Hence unless it is 100% total proven failure the affiliates will try any means to protect/advocate/spread whatever language they like.
- Koshkin 7y agoThis is an inconvenient truth.
- seddona 7y agoMaybe try contributing to a large Haskell codebase first to get a feel for what Haskell is like in in-the-large and gain some comfort. I'll add this problem is not at all Haskell specific. If you put an experienced Java developer to work architecting a large Python application where they have no prior Python experience you are going to experience similar problems. I'd say the problem is perhaps a bit more acute with Haskell as the paradigm is likely more different to the prior language. So if possible get at least one person on your team that has experience with a large Haskell app and pair them up with other devs.
- matt-noonan 7y ago> How common is it for the same person to have both strong Haskell experience and experience building large real-world applications? I would conjecture that it is more common than what you’d expect from random chance. In my case, I picked up Haskell only after building large systems in C++, Objective C, Lisp, and Python. The draw was that Haskell let me express the kind of system invariants that make it possible to reason about a large codebase. Since then I’ve written production Haskell in three different companies, none of which appear on this list.
- gridlockd 7y agoRequiring a team made out of wizards to successfully launch a product is a huge downside though. Pretty much anything you do in NodeJS/Angular is run-of-the-mill stuff that your run-of-the-mill hires should be able to work on.
- galaxyLogic 7y agoYes and you can have your monads too, in JavaScript
- Koshkin 7y agoBut see Greenspuns Tenth Rule of Programming (substitute Haskell for Common Lisp and JavaScript for Fortran).
- gridlockd 7y agoI do not believe that the rationale behind this rule applies to any dynamic/scripting language. It would apply to Haskell though, unless Haskell itself works well as a scripting host.
- crimsonalucard 7y agoYou can have monads in any language. If you have a functor you have a monad. If you have a type that wraps or encodes another type in a lossless or lossy way you have a functor. Therefore a functor exists in any language with compound types therefore every language that has compound types has monads. The difference is Haskell makes these concepts explicit.
- galaxyLogic 7y agoI would be interested in learning more about how does Haskell make monads "explicit"? Does Haskell have the keyword "monad"? Does Haskell have support for ensuring that monadic laws hold for any prospective monad?