3 ms·
It's not even necessarily that they have a steep learning curve, it's that there's such a deep case of TMTOWTDItis in each of those. I can't speak to Clojure;
by mumblemumble 7y ago
It's not even necessarily that they have a steep learning curve, it's that there's such a deep case of TMTOWTDItis in each of those.
I can't speak to Clojure; I'm still learning it and haven't used it professionally. But it seems promising insofar as it seems to be quite opinionated. Groovy and Scala aren't. So they both have a lot of concepts to learn, and those concepts all overlap and interact in surprising ways. On my team, I've started banning certain parts of Scala from the codebase. Not because I think they're bad features, per se, but because carving the language down to some semblance of an orthogonal subset seems to be the only way to ensure that 4 programmers won't solve the same problem 6 different ways in the same codebase.
I run into the same problem with Haskell. Haskell's a great language and I think everyone should put some time into learning it. But it was designed as a language research platform first and foremost, and that's evident everywhere. So I'm hesitant to try using it on a large team. I'm kind of hoping that someday someone will produce the Haskell equivalent of Clojure. It doesn't need to try and be minimalist like Scheme. It just needs to have fewer than 5 string types, and save the senior developers from having to spend 85% of their time coaching the junior developers on when to choose a monad and when to choose an applicative functor.
- aoeu512 7y agoSounds like your talking about Idris, Elm(JavaScript), ReasonML([JavaScript] https://reasonml.github.io https://reasonml.github.io), or F#(.NET)... Monads are for context-sensitive mini-languages (>>=) (=<<): they have a direction and sort-of sequential semantics, >>= is concat . map, <$>(map) is for context-insensitive languages (can be run in parallel)...