<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 27, 2015 at 8:17 AM, Dennis Raddle <span dir="ltr"><<a href="mailto:dennis.raddle@gmail.com" target="_blank">dennis.raddle@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Martin,</div><div><br></div><div>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. </div><div><br></div><div>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. </div><span class=""><div><br></div></span></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><div>Very well put. I didn't really think about what meant by "practical," and it depends on context.</div><div><br></div><div> 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.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div>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). </div></div></div></div>