<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 25, 2015 at 9:50 AM, Martin Vlk <span dir="ltr"><<a href="mailto:martin@vlkk.cz" target="_blank">martin@vlkk.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br><span class=""><br>
<br>
</span>What'd be the definition of an okay programmer? If we agree that's the<br>
one that "learns how to solve a few standard problems and then applies<br>
the same thing over and over without much creativity", then I'll argue<br>
this will work with Haskell just like with any imperative language. If<br>
you train them on Haskell that is. :-)<br>
<br>
<snip><br>
<span class=""><br></span></blockquote><div><br></div><div><br></div><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><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> But I wonder if the same mechanisms that make Haskell concise (which are<br>
> some of the things that make it hard) also are bound up with its practical<br>
> advantages so that they can't be separated.<br>
<br>
</span>What you mean by practical? Does it mean that you can find enough people<br>
able to use it in your real-world project, without putting too high<br>
requirements on training them?<br>
<br>
If so, then we could say that given the current state of affairs, where<br>
the mass of okay programmers are trained on a different paradigm,<br>
Haskell is not all that practical.<br>
<br>
But if practical means that the language is well suited for solving<br>
real-world problems, in beautiful ways, once you get it, then it is<br>
uberpractical! :-)<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><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><div><br></div><div>Dennis</div></div></div></div>