## FRP Essay, draft 2 started

* TOC
{: toc }

### Relaxing reading on Friday afternoon

I didn't feel like working on my computer, so I printed out my essay, Jonathan Edward's feedback, and grabbed a few papers to re-read I felt would be relevant. Turns out they really were!

From [What's Functional Programming All About?](http://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html)

> The core of Functional Programming is thinking about data-flow rather than control-flow.

> it's about managing the same complexity in a way that makes the dependencies between each piece of code obvious, by following the graph of where function arguments come from and where return values end up.

From [Out of the Tarpit](https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf):

> There is in principle nothing to stop functional programs from passing a single extra parameter into and out of every single function in the entire system. If this extra parameter were a collection (compound value) of some kind then it could be used to simulate an arbitrarily large set of mutable variables. In effect this approach recreates a single pool of global variables — hence, even though referential transparency is maintained, ease of reasoning is lost (we still know that each function is dependent only upon its arguments, but one of them has become so large and contains irrelevant values that the benefit of this knowledge as an aid to understanding is almost nothing).

Out of the Tarpit turned me on to Dijkstra's [The Humble Programmer](https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html):

> A study of program structure had revealed that programs —even alternative programs for the same task and with the same mathematical content— can differ tremendously in their intellectual manageability. A number of rules have been discovered, violation of which will either seriously impair or totally destroy the intellectual manageability of the program. These rules are of two kinds. Those of the first kind are easily imposed mechanically, viz. by a suitably chosen programming language. Examples are the exclusion of goto-statements and of procedures with more than one output parameter.

> Argument four has to do with the way in which the amount of intellectual effort needed to design a program depends on the program length. It has been suggested that there is some kind of law of nature telling us that **the amount of intellectual effort needed grows with the square of program length**. But, thank goodness, no one has been able to prove this law. And this is because it need not be true. We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called “abstraction”; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise. Of course I have tried to find a fundamental cause that would prevent our abstraction mechanisms from being sufficiently effective. But no matter how hard I tried, I did not find such a cause. As a result I tend to the assumption —up till now not disproved by experience— that by suitable application of our powers of abstraction, **the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length**. 

(Bold is mine.)

Reading Dijkstra was a revalation. This quote almost makes my part of my first FRP draft look like plagiarism for not attributing this idea to him!

> the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length

Honestly, I didn't know! But know I do.

### What my FRP essay is really about

I'm realizing that much of my essay need to be deleted, which is sad, but its important to be ruthless about "killing ones darlings" when it's time to. I went ahead and deleted it all and started afresh in the same file, but I expect that I will be coming back to the [first draft](https://cdn.rawgit.com/stevekrouse/futureofcoding.org/01f04f48eab8bd4740beb667ae3fb03b4aaf5b0c/drafts/frp.md) a lot to copy and paste various elements.

I see now that my essay is less about the importance of explicit dependencies, but more about how Elm doesn't have them, but Reflex does, and the reason is higher-order and cyclic streams. I worked on this essay for ~90 mintues today and it was a bit pulling teeth. I'm not sure if it's because I'm in a new setting -- the NY Public Library instead of home -- or if I'm sad about the mass deletion, or distracted by my other part time work, or whatever, but I'm going to stop working on this essay today in favor of other part time work, and start again tomorrow morning.