4 ms·
It's not so much Haskell that is to blame, but how it's used in practice. To be fair, I have seen similar over-complicated projects in Scala and even in Java: b
by misja111 5y ago
It's not so much Haskell that is to blame, but how it's used in practice. To be fair, I have seen similar over-complicated projects in Scala and even in Java: but there it seems to be more rare.
The problem is, you have this language which offers you a million handy little tricks which seem very useful for all kinds of little niche problems. The boring and common sense approach would be not to use them, because it would give your colleagues too many headaches to figure out what they are and why you chose to use them. But in practice the temptation is often too strong.
- ParetoOptimal 5y ago> you have this language which offers you a million handy little tricks which seem very useful for all kinds of little niche problems. The focus should be on the core abstractions like Functor, Monad, Monoid, Applicative, etc that are sound, non-leaky, universal abstractions that are useful for all kinds of little niche problems. > The boring and common sense approach would be not to use them, because it would give your colleagues too many headaches to figure out what they are and why you chose to use them. But in practice the temptation is often too strong. The boring Haskell approach you describe should include taking advantage of those core abstractions. If your coworkers don't get them, they should learn the core abstractions and how to use them.