On Fri, Nov 27, 2015 at 8:17 AM, Dennis Raddle
Martin,
One issue I can foresee is having both good Haskell programmers and non-creative Haskell programmers on the same team. The good ones can easily write code that is incomprehensible to the non-creative ones.
It actually happened in my team twice that C++ code was thrown out and assigned to someone else for a complete rewrite, because the senior software engineer deemed that the original code was incomprehensible. In both cases it was code that used a few tricks that I think were good, and in both cases the replacement code was buggier.
This is not unique to Haskell; this is a problem with programming in general. People with more ability can write code that is clean, fast, and easy to read, but which "average" programmers find confusing. I don't think it's realistic to avoid that in any language; I've even had people review my Ruby code that used the "Hash[]" constructor to build a hashmap from a list and call that confusing.
Very well put. I didn't really think about what meant by "practical," and it depends on context.
I am gaining some Haskell momentum, and I see how the potential for conciseness seems to encourage the kind of thinking about a problem that leads to simplifications and optimizations. When I spend some time thinking about a good way to write it in Haskell, it's guiding me toward a better understanding of the problem itself that would potentially be helpful no matter what language I'm using. But using Haskell provides the impetus for this thinking.
In my opinion, thinking about the problem up front is the most vital
aspect of writing reliable, readable code, in any language. Haskell allows you to encode those insights into the types; in other languages, they frequently live only in your short term memory (or, if you're particularly conscientious, docstrings--although those are neglected the minute anyone else touches them).