<story><title>Becoming Productive in Haskell</title><url>http://mechanical-elephant.com/thoughts/2015-04-20-becoming-productive-in-haskell/index.html</url></story><parent_chain></parent_chain><comment><author>QuantumRoar</author><text>Scripting languages try to seduce you to just fiddle around until the output looks like something you want. While that quickly gives you some results, I think it&amp;#x27;s a huge roadblock in the mid- to longterm. Especially when programmers are only familiar with &amp;quot;easy&amp;quot; scripting languages, there are rarely insights about the general approach to the problem until the project already grew to become an abomination.&lt;p&gt;While fiddling around is still somewhat possible in Haskell, the language itself makes it quite difficult. Haskell kind of forces you right at the beginning to pause and think &amp;quot;Well, what is it that I&amp;#x27;m actually trying to do here?&amp;quot; It let&amp;#x27;s you recognize and apply common patterns and implement them in abstract ways without having to think about what kind of values you actually have at runtime. In that way Haskell is the most powerful language I know.&lt;p&gt;Have a tree&amp;#x2F;list&amp;#x2F;whatever? Need to apply a function to each of the elements? Make your tree&amp;#x2F;list&amp;#x2F;whatever an instance of the Functor type class and you&amp;#x27;re done. Need to accumulate a result from all the elements? Make it foldable.&lt;p&gt;Something depends on some state? Make it a Monad.&lt;p&gt;You either get a result or you don&amp;#x27;t (in which case any further computations shouldn&amp;#x27;t apply)? Use the Maybe Monad.&lt;p&gt;You need to compute different possible results? Use the List Monad.&lt;p&gt;Need to distinguish three different possible values that are different compositions of elementary types? Make yourself your own type and pattern match the behavior of applying functions.&lt;p&gt;Need to output in a certain way? Make it an instance of the Show class.&lt;p&gt;Most concepts that are used every day have some kind of idea behind them that is abstract and implementation independent. Haskell kind of forces you to reference those ideas directly. The downside is that you actually have to know about those concepts. However, knowing about the such concepts makes you also a better programmer in other languages, so it&amp;#x27;s not like it&amp;#x27;s a bad thing.</text></comment>
<story><title>Becoming Productive in Haskell</title><url>http://mechanical-elephant.com/thoughts/2015-04-20-becoming-productive-in-haskell/index.html</url></story><parent_chain></parent_chain><comment><author>david-given</author><text>The author&amp;#x27;s comments on noise chime true with me: every time I give Haskell a try I end up struggling with frustrating and opaque vocabulary, sometimes completely at odds with the way other languages use them: e.g. C++ also has functors, and they&amp;#x27;re completely unrelated to Haskell functors.&lt;p&gt;I really like the author&amp;#x27;s suggestion of mentally translating Functor to Mappable. Are there any other synonyms for other Haskell terms of art?&lt;p&gt;What I&amp;#x27;d really like, I suppose, is a complete overhaul of Haskell syntax to modernise and clarify everything: make it use actual &lt;i&gt;words&lt;/i&gt; to describe things (foldl vs foldl&amp;#x27;? BIG NO). Put in syntax redundancy and visual space to avoid the word soup effect: typing is cheap, understanding is expensive. Normalise and simplify terminology. Fix the semantic warts which make hacks like seq necessary --- if I need to worry about strictness and order of evaluation, then the language is doing lazy wrong. etc.&lt;p&gt;Basically I want language X such that X:Haskell like Java:K&amp;amp;R C.&lt;p&gt;This will never happen, of course; the people who have the knowledge to do such a thing won&amp;#x27;t do it because they are fully indoctrinated into the Haskell Way Of Life...</text></comment>