## Back at the FRP essay!

* TOC
{: toc }

The changes I'm comitting now were actually done this past Friday. It's not a ton of work but it wasn't pulling teeth - it was fun. And I'm excited enough about it that I actually made my girlfriend listen to me read it to her - she was a great sport. The langauge is a bit technical / high level. There's a lot I need to expound on / elaborate in there, and I imagine that some ambiguity in the essay are weak spots I need to explore more. 

Yesterday I had a lot of fun comparing and contrasting TodoMVC in Elm and Redux. I printed out the code for both on paper and wrote all over them. I have a lot of questions about the types of things in Redux that I'll have to investigate next.

One idea I had is that to make the comparison more apples-to-apples, I could write TodoMVC in Redux but with the Elm Architecture - this is possible but not the reverse. However, that is a bunch of work considering how slow my Reflex/ghcjs feedback loop is. Another possible task is implementing focus on input elements, localstorage, and url hash get/set in Reflex to make them truly equal - but that's not really the point so it may be more work than it's worth.

I only have two weeks before I have to submit to REBLS. I think I have enough for the paper in progress section, but I want to make it as best I can before that date. However, I also have work for Dark and First Round I should do this week - as well as taking some time off to spend with family that's around this month. It's a lot going on!

### Dark research

I spent 3 hours this morning compiling lists of various interesting progrmming environments. What I'm most excited about is my list of classics that I've never played with:

* Hypercard
* squeak / etoys / morphicjs / pharo / http://gtoolkit.org/
* Labview
* apl
* Self
* Forth
* Prolog
* Sketchpad
* Matlab / simulink
* Yahoo pipes


As well as a few I keep haering about:

* prograph
* paxmsp and pure data  vvvv
* JetBrains MPS 
* emacs org mode 
* TLA+ / Alloy
* Sonic Pi 
* R
* https://www.blender.org/
* Godot engine
* Qt
* Chalktalk
* http://mbeddr.com/
* http://openendedgroup.com/field/OverviewBanners2.html

Author: Steve Krouse

drafts/frp.md

@@ -9,45 +9,45 @@ title: FRP
 
 ## 1. Introduction
 
-Explicit dependencies clarify which sections of code are independent to our current investigations, keeping the "effort needed to concieve or to understand a program ... not more than proportional to the program length" [Humble Programmer].
+When trying to understand a small piece of a large software project, explicit dependencies clarify which sections of code are independent to our current investigations, keeping the "effort needed to concieve or to understand a program ... not more than proportional to the program length" [Humble Programmer]. 
 
-In pure functional programming, all terms explicitly list what they depend upon - as opposed to imperitive programming where terms can "be dependent on many, many different hidden mutable variables" [Out of the Tarpit]. 
+Explict data relationships is one of the benefits of functional programming, because all terms explicitly list what they depend upon. This contrasts with imperitive programming, where terms can "be dependent on many, many different hidden mutable variables" [Out of the Tarpit]. 
 
-However, functional programming isn't immune to hidden dependencies:
+However, functional programming can simulate "hidden mutable variables" via an compound state value that it passes around as an extra parameter:
 
-> 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).
+> 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]
 
-The popular Functional Reactive Elm Architecture suffers from this problem. I argue that the way to maintain explicit dependencies in Functional Reactive Programming is through cyclic and higher-order streams, as demonstrated by the Reflex framework.
+While this is considered an anti-pattern in many functional programming settings [TODO source needed], a variation on it has become the dominant architecture in Functional Reactive Programming. Originally concieved for the Elm programming langauge, The Elm Architecture has since inspired ReactJS's Redux, VueJS's Vuex, CycleJS's Onionify, among many other front-end state management libraries. [TODO source needed]
 
-2. The Elm Architecture
+This paper contrasts the Elm Architecture with Haskell's Reflex, featuring higher-order streams and cyclic streams, with an eye towards idepedent comprehensibility through explicit data dependencies.
 
-Elm is a pure functional language in the spirit of Haskell that compiles to JavaScript. It is an FRP-inspired langauge that only allows first-order and non-cyclic streams. 
+## 2. The Elm Architecture
 
-The Elm Architecture follows directly from the first-order, non-cyclic restrictions. Because streams cannot contain other streams, nor be cyclical, the only way to construct a user interface, which is inherently cyclical, is to have a single, large, language-supported cycle.
+Elm is a pure functional language in the spirit of Haskell. It compiles to JavaScript. It is an FRP-inspired langauge that only allows first-order and non-cyclic streams for reasons discussed in [TODO disease worse than cure?].
 
-<iframe width="500" height="300" src="https://mermaidjs.github.io/mermaid-live-editor/#/view/eyJjb2RlIjoiXG5ncmFwaCBURFxuIFxucmVkdWNlci0tPnN0YXRlXG5zdGF0ZSAtLT4gdmlldyBcbnZpZXctLT58ZXZlbnR8cmVkdWNlclxuIiwibWVybWFpZCI6eyJ0aGVtZSI6ImRlZmF1bHQifX0" frameborder="0" allowfullscreen></iframe>
+The Elm Architecture follows directly from Elm's first-order, non-cyclic nature: because streams cannot contain other streams, nor be cyclic, the only way to construct user interfaces, which are inherently cyclical, is to have a single, large, language-supported cycle.
 
-The Elm Architecture was built originally for use in Elm, but has since inspired ReactJS's Redux, VueJS's Vuex, CycleJS's Onionify, among many other front-end state management libraries.
+<iframe width="500" height="300" src="https://mermaidjs.github.io/mermaid-live-editor/#/view/eyJjb2RlIjoiXG5ncmFwaCBURFxuIFxucmVkdWNlci0tPiBzMihuZXcgc3RhdGUpXG5zMihuZXcgc3RhdGUpIC0tPiB2aWV3IFxudmlldy0tPnxldmVudCwgb2xkIHN0YXRlfHJlZHVjZXJcbiIsIm1lcm1haWQiOnsidGhlbWUiOiJkZWZhdWx0In19" frameborder="0" allowfullscreen></iframe>
 
-Let's examine the architecture. The reducer is a function that takes the old state and an event, and returns a newly computed state.
+The core of this architecture is its a compound state value, which along with the reducer, which returns a new state in response to events, "simulate[s] an arbitrarily large set of mutable variables." [Tarpit]
 
 ```haskell
 reducer :: state -> event -> state
 ```
 
-The way the view sends events to the `reducer` differs between the frameworks. As we saw above, CycleJS derives event information *outside* the view, such as `const clicks = DOM.select('#counter-button').events('click')`. React and Elm generate events from *within* view, such as `<button onClick={this.handleClick()}>` or `button [ onClick Increment ]`, respectively.
+The view is a pure function of state.
 
-Additionally, these frameworks sometimes wrap events in semantic labels called "actions" or "messages". For example, above the `onClick` event is labeled as the `Increment` action. This will become clearer in the Elm example below.
+The way the view sends events to the `reducer` differs between frameworks. CycleJS derives event information *outside* the view, such as `const clicks = DOM.select('#counter-button').events('click')`. React/Redux and Elm generate events from *within* view, such as `<button onClick={this.handleClick()}>` or `button [ onClick Increment ]`, respectively.
 
-In the Elm Architecture, we are explicit about the initial value of state, how the state determines the view, and how various events effect the state. This is a huge improvement over the Imperative Button above. For one, it gives us serializable state, which we can use for hot-swapping and time travel debugging!
+Additionally, these frameworks sometimes wrap events in semantic labels called "actions" or "messages". For example, an `onClick` event can be labeled as the `Increment` action. This will become clearer in the Elm example below.
 
-However, let's examine the Elm Architecture from a modular comprehensibility point of view. 
+Just like in imperitive programming, the Elm Architecture is explict only about the *initial* values of states.
 
 Any message can modify any state. In the reducer, called  `update` in [Elm ToDoMVC](https://github.com/evancz/elm-todomvc/blob/master/Todo.elm), the `Add` message triggers an update of three different pieces of state:
 
 ![image](https://user-images.githubusercontent.com/2288939/42886488-ab1c24c4-8a71-11e8-92f5-13dc2f282ad4.png)
 
-This means that you can't modularly gain a complete understanding of any piece of state. You have to look through *all* the messages for any piece of state, which may be spread across many files.
+This means that you can't modularly gain a complete understanding of any piece of state. You have to look through *all* messages to see if and how it affects the state in question.
 
 There's also a subtler way this undermines explicit dependencies: each piece of state can be modified in terms of *any other piece of state*. There's no explicit isolation between independent states. 
 
@@ -57,6 +57,10 @@ Additionally, any view element can emit any message. Again from [Elm ToDoMVC](ht
 
 If we’re looking to understand a single piece of state, we’re not much better off than with an entirely imperative framework: we still have to read more-or-less the whole application even if we wish only to comprehend only a small piece.
 
+## 3. Reflex
+
+The Reflex library was built for Haskell web development via ghcjs. It features higher-order and cyclic streams.
+
 ## ToDo
 
 * maybe reverse the order of the introduction
@@ -65,8 +69,7 @@ If we’re looking to understand a single piece of state, we’re not much bette
   * inversion of control (http://degoes.net/articles/destroy-all-ifs)
   * explicit in the math formula sense
 * the elm architecture section
-  * edit this section a lot 
-  * the elm architecture simulates imperitive, von-neuman, one word at a time architecture in a functional setting
+  * maybe simulates von-neuman, one word at a time 
   * argue that it's difficult to mechanically convert to explicit form
 * argue the treatment is *not* worse than the disease
   * This design decision was made consciously in Elm to decrease coupling. [3]