Why calculating is better than scheming (1987) [pdf]
I&#x27;ve skimmed this article a few times now, and something I&#x27;ve always had trouble with was this:<p><i>“…problem like this are damaging if one is trying to present programming as a discipline subject to mathematical analysis.”</i><p>because <i>in general</i> programmers steadfastly refuse to subject their discipline to mathematical analysis, and continue to look for some aesthetic balance between &quot;enough abstraction&quot; and &quot;enough whitespace&quot;.<p>Here is a program to sum a list of numbers:<p><pre><code>    +&#x2F;
</code></pre>
This definition is even less cumbersome than the Miranda or the Lisp, but it&#x27;s unclear what the author expects us to conclude from this. <i>And yet</i> I think it&#x27;s perfectly reasonable to posit that shorter programs are better. Shorter programs have less bugs[1], and run faster[2], and yet for some reason there are a lot of programmers who believe their job is to produce <i>more code</i>. Fuck those guys. Seriously.<p>[1]: See Code Complete and Software Estimation: Demystifying the Black Art, by Steve McConnell.<p>[2]: <a href="https:&#x2F;&#x2F;stacresearch.com&#x2F;m3" rel="nofollow">https:&#x2F;&#x2F;stacresearch.com&#x2F;m3</a><p>Then we have the pursuit of &quot;traditional mathematical notation&quot;: I don&#x27;t think it produces better programs or better programmers. Computers do not execute mathematical notation, and mathematicians can&#x27;t agree on their notation to enough specificity to permit as much useful computation[3]. It is clear that notation is important[4], but there is frighteningly little real research in this space. Zero-cost abstractions still take up source code, and yet many programmers think this is <i>given</i> as a good thing, despite Dijkstra’s wonderfully succinct observation:<p><i>“…the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length.”</i><p>[3]: See Whitehead and Russell, Principia Mathematica<p>[4]: <a href="http:&#x2F;&#x2F;www.jsoftware.com&#x2F;papers&#x2F;tot.htm" rel="nofollow">http:&#x2F;&#x2F;www.jsoftware.com&#x2F;papers&#x2F;tot.htm</a><p>Lazy is also bad. Computers aren&#x27;t lazy. Starting off by thinking about them as lazy puts programmers on that path for total abstraction. So much energy has been put into trying to hide concurrency-problems[5] that it&#x27;s no wonder most big-data programs generate so much heat. The real value in Scheme Streams is that they&#x27;re explicitly concurrent, and other languages that have optimised for those constructs[6] have discovered a great deal of utility.<p>[5]: <a href="http:&#x2F;&#x2F;hadoop.apache.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;hadoop.apache.org&#x2F;</a><p>[6]: O=spawn(fun(P)-&gt;P!{f,self(),F()} end,[self()]), receive{f,O,X}-&gt;X end.<p>It&#x27;s almost like we&#x27;ve plucked some ideas, said they&#x27;re important, and then used them as a lens to study our languages without even doing <i>the first thing</i> by showing how we can know they are important to the point of excluding everything else.<p>About the only thing I really like about Miranda (and Haskell, etc) is the pattern matching, which is dope. Seriously good stuff. I don&#x27;t know how to square that with array languages, but I think it&#x27;s worth thinking about since they (array languages) seem to have otherwise sorted out program length and notation.