| I have mixed feelings about this. I suspect Haskell has enough base-level complexity to be productive in it that it gets in the way of its adoption. Contrast that to say writing something to serve http requests in Go. The number of complex concepts or idioms in related library pieces is comparatively very low. [0] I’ve found the complexity of the solution should match the complexity of the problem being solved.
If the solution has equivalent number of moving pieces and choices as the problem space requires, then it’s been made “as simple as possible, not simpler”.
This is where some languages (tools) are better suited to a problem than others. Don’t reach for imperative patterns when css declaratively does what you want and has matured enough to have boiled down the very good ways of doing it. I like Joe Armstrong’s approach of writing and then iterating a solution (a method, part of a feature, whole feature) until the extra dead material falls off. So like I said, I have mixed feelings about this.
It’s a shame to have to add artificial complexity. [0]: Go and it’s libraries are admittedly not a perfect example. I find Go leans a little past the edge in trying to make things simpler than they actually are. But it’s not too far off. |