<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>cies</author><text>Great article. I do think a better &amp;quot;Getting started with Haskell&amp;quot; guide is Chris Allen&amp;#x27;s:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;bitemyapp&amp;#x2F;learnhaskell&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;bitemyapp&amp;#x2F;learnhaskell&lt;/a&gt;&lt;p&gt;OP&amp;#x27;s article is still a great way of wetting appetite, and sharing insights; but moving on from there is better facilitated by Chris Allen&amp;#x27;s recommendations.&lt;p&gt;There is also the IDE issue; FPComplete has a web-based IDE that is good for beginners, and it is possible to setup Emacs to be a very helpful IDE (though this is by no means simple). With Haskell an IDE is really helpful: see the errors as you type, and resolving them before running into a wall of compile errors.&lt;p&gt;Anyway: go Haskell. I&amp;#x27;m looking forward to a less buggy future :)</text></comment>