<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 25, 2015 at 4:56 AM, Alexander Berntsen <span dir="ltr"><<a href="mailto:alexander@plaimi.net" target="_blank">alexander@plaimi.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
If the tables were turned and denotative programming were the norm and<br>
imperative programming the fringe community (not that denotative<br>
programming is entirely fringe as it were), you would no doubt have<br>
posed the opposite question.<br></blockquote><div><br></div><div><br></div><div>I don't agree. Having worked for 16 years in a government aerospace contractor doing C++ and Python programming, what I saw is that maybe half the programmers struggled with precise thinking and abstraction. They thought of programs as step-by-step recipes and implemented those recipes in exactly the same way they themselves had always thought about a problem. </div><div><br></div><div>Also having worked as a math tutor, I see many people who struggle with abstract thinking.</div><div><br></div><div>So my feeling is that at least half of the programmers I knew would reject Haskell outright and would feel it was pointlessly non-intuitive. Would they have thought it was intuitive if they were raised on it? I don't think so, because I think these same people were among those who struggle with all forms of abstract thought, like math students who may someday be able to appreciate a little math but are light years away from being math majors.</div><div><br></div><div>We can pose a world in which the "tables were turned" but for that world to come into existence a lot of things would have to be changed about the current world, particularly increasing interest in abstract math from a young age.</div><div><br></div><div>Okay, having written all that, please feel free to tear holes in my argument. I would like to be wrong and I don't have experience outside one workplace (and some math tutoring).</div><div><br></div><div>My workplace was much better than a contractor we briefly hired. Those folks had about a 90% struggle ratio with using things like object orientation. "Just get it done, quick and dirty" was how they thought. My own workplace had some very intelligent people but between the high numbers who were just barely competent programmers, and a more "practical" orientation in the management (documentation was highly emphasized, testing was highly emphasized, but elegant code was practically unimportant), I just can't see the adoption of Haskell by them, not in this lifetime, not in this universe.</div><div><br></div><div>Can an "okay" imperative programmer become an "okay" Haskell programmer? Does the necessary skill, work, motivation, and talent to program at an "ordinary" imperative level serve as a sufficient prerequisite for functional programming? I really don't think so, but I could be wrong.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, the tables aren't turned, and you aren't posing the opposite<br>
question, so let me give you a brief answer: Yes, Haskell is practical.<br>
<br>
To elaborate some: it is used in academia and industry. Not as much as<br>
some languages, but then again more than some other languages. Big<br>
universities like Chalmers use it, and big companies like Facebook use<br>
it. It is the primary language I myself use in industry as well.<br>
<br>
Let me repeat myself: Yes, Haskell is practical!<br>
<br>
<br>
If you have more specific questions, do not hesitate to ask.<br>
</blockquote><div><br></div><div><br></div><div>Yes, I do have more specific questions. For example is the conciseness part of what makes it practical in these uses? Is the conciseness somehow bound up with what makes it practical? In other words, could we imagine a simpler language with the same level of practicality but less of a learning curve?</div><div><br></div><div>By the way, I *love* conciseness and have experienced the possibility of it becoming intuitive. It's amazing once I understand an elegant piece of Haskell, once I have wired my brain to think in harmony with it, that it becomes immediately legible. So I know it's possible to make progress. I'm not saying that conciseness must forever remain an obtuse language.</div><div><br></div><div>But I wonder if the same mechanisms that make Haskell concise (which are some of the things that make it hard) also are bound up with its practical advantages so that they can't be separated. </div><div><br></div><div>Dennis</div><div><br></div><div><br></div><div><br></div></div></div></div>