<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><item><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></item></parent_chain><comment><author>munro</author><text>Ability to fiddle isn&amp;#x27;t tied to static or dynamic programming, it&amp;#x27;s just every static language platform I&amp;#x27;ve seen including The Haskell Platform neglects making it easier to fiddle.&lt;p&gt;When trying to build complex software in Haskell, I find myself spending a lot of time commenting&amp;#x2F;uncommenting swaths of code, just so I can get part of a algorithm to load in GHCi.  It sucks.  What I wish would happen is GHCi allowed me to load just the things that type check, and skip the rest, so I can fiddle.  This is definitely possible.  Not compiling is great for production, but not while developing.&lt;p&gt;Software is built in pieces, if I&amp;#x27;m working on one piece, another statically unrelated piece shouldn&amp;#x27;t prevent me from working.  In this regard Haskell GHCi (and many static languages), makes developing more complex than dynamic languages, but again it&amp;#x27;s not intrinsic.&lt;p&gt;I also wish when I run my tests, it listed all the type errors, as well as run tests on the code that do type check.  Having more safety mechanism in Haskell helps with writing correct code, but compiling doesn&amp;#x27;t mean the code works.  Automated testing is still more useful for writing software that works.  Haskell isn&amp;#x27;t as safe as many people think [1].&lt;p&gt;&lt;pre&gt;&lt;code&gt;    sort a = a ++ a  -- it compiles, so it must sort
&lt;/code&gt;&lt;/pre&gt;
[1] &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;hackage.haskell.org&amp;#x2F;package&amp;#x2F;base-4.8.0.0&amp;#x2F;docs&amp;#x2F;Prelude.html#v:head&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;hackage.haskell.org&amp;#x2F;package&amp;#x2F;base-4.8.0.0&amp;#x2F;docs&amp;#x2F;Prelude...&lt;/a&gt;</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><item><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></item></parent_chain><comment><author>hyperpallium</author><text>Requirements Uncertainty: Fast iteration has many benefits - especially when you (or your client) don&amp;#x27;t actually know what&amp;#x27;s &lt;i&gt;required&lt;/i&gt; (&amp;quot;agile&amp;quot;); and when what is &lt;i&gt;required&lt;/i&gt; changes quickly, because of changes in competitors, customers, technology, regulation etc.&lt;p&gt;But you&amp;#x27;re right, as projects get larger, a priori design and static types quickly become essential. And at that point, requirements are usually known and frozen.&lt;p&gt;I predicted that the natural resolution would be languages with both (i.e. optional static types, especially at important interfaces) - but while this feature exists, it hasn&amp;#x27;t taken off.&lt;p&gt;Instead it seems that performance is the main attraction of static types in the mainstream (java, c#, objective-c, c, c++); and ML-family and Haskell are popular where provable correctness is wanted.</text></comment>