## Mon 6/4/18 - Fri 6/15/18

* TOC
{: toc }

Apologies for going dark here the last two weeks. On the bright side, I have been quite productive, but in an analog sort of way...

### Fedex Kinkos to Brother printer

Two weeks ago, I spent 3ish hours reading [Functional Reactive Animation](http://conal.net/papers/icfp97/) on my phone. I was finally able to make it all the way through, reading every word, and understanding ~80%. I was very proud. But, I didn't love reading on my phone - I wanted to print some papers out. I didn't have a printer at home -- I hate printers, they always break, and cost a bajillion dollars to buy ink for -- so I went to kinkos to print out most of Conal's papers:

![image](https://user-images.githubusercontent.com/2288939/41498690-cb736744-7141-11e8-98b3-634d0b630f9e.png)

But here's where I felt like a stupid idiot: it cost $75 bucks to print all that! So I learned from my mistake and went on amazon to buy the printer with the cheapest cost per page, and found a [Brother printer](https://www.amazon.com/gp/product/B0763WDSYZ/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1) that fit the bill. It cost $70 itself, and will print ~500 pages before needing more ink. It's a 10x price reduction!

### FRP Reading

#### [Functional Reactive Animation](http://conal.net/papers/icfp97/)

Finally able to make it through -- this was probably the 3rd or 4th time I attempted to read this paper.

##### Bouncing Ball (solved)

As it turns out, Conal solved [my bouncing ball problem](http://futureofcoding.org/log#a-bouncing-ball-graph) in this paper. And I don't mean that he gave me hints towards the solution. I mean that he actually gave the code to solved the *same exact problem*. And it's beautiful:

![image](https://user-images.githubusercontent.com/2288939/41498825-84ad7036-7144-11e8-95ec-ad2e0b9acc83.png)

It's very similar in spirit to what I created. Of course, there are no graphs or visualizations in the code, which is where I want to take this. FRP lends itself really well to live values and graphs.

#### [Genuinely Functional User Interfaces](http://conal.net/papers/genuinely-functional-guis.pdf)

Also great. Also was able to read every word and understand closer to 90% this time. 

**Arrowized FRP is when you use signal combinators, not signals as first class.** This is supposed to help with spacetime leaks, as well as modularity. But of course, they are two-sides of the same coin, and it's easy enough to translate from one to the other.

##### Paddle Ball is beautiful

The hardest parts of this definition are `xvel` and `yvel`, but it all makes sense when you read the paper and look at it for long enough: 

![screenshot 2018-06-16 at 9 09 38 am](https://user-images.githubusercontent.com/2288939/41498840-0913ade0-7145-11e8-85f0-d14793df524a.png)

#### [Denotational design with type class morphisms](http://conal.net/papers/type-class-morphisms/)

Harder and slower. I probably got closer to 60% of this one, but I do feel like I have a much, much better grasp of what programmers mean whey they **model programming concepts with mathematical objects**, and what **semantics** means.

#### [A Fifteen Puzzle in Fran ](https://www.microsoft.com/en-us/research/publication/a-fifteen-puzzle-in-fran/)

Read like a tutorial, explaining how to code an example project. Interesting and helped cement the ideas of FRP. Fascinating how he explained the structure of signal combinations in pictures:

![image](https://user-images.githubusercontent.com/2288939/41498780-6b01893e-7143-11e8-9813-b7c5fa2be9f4.png)

#### [Two-handed Image Navigation in Fran](http://conal.net/papers/TwoHanded/)

Another tutorial. A bit harder to follow.

#### [Push-Pull FRP](http://conal.net/papers/push-pull-frp/)

I've been having trouble with this one, so have been putting this one off for now, but hope to get to it soon. It's a prerequisite for a number of other papers I want to read.

#### [Asynchronous Functional Reactive Programming for GUIs](https://people.seas.harvard.edu/~chong/pubs/pldi13-elm.pdf)

I skimmed through this one. I wasn't terribly impressed with Elm. I can see now how it's Haskell-lite and FRP-lite. It's definitely more synchronous in spirit, taking some interesting ideas without super-solid foundations and running with them.
#### [Experience Report: Functional Reactive Programming and the DOM](https://2017.programming-conference.org/event/proweb-2017-papers-experience-report-functional-reactive-programming-and-the-dom)

Really wonderful read - very easy for me to assimilate because I'm so familiar with the DOM. It also helped me see how much of the trouble of FRP comes from not properly and completely abstracting over the imperitivity of the DOM.

##### Recursion between FRP and the DOM

They do a good job of specifying this problem:

> ...the DOM tree in an FRP application can change in response to changes in FRP behaviors and events. However such new elements in the DOM tree may also produce new primitive event streams... which the FRP program needs to be able to react to. In other words, there is a cycle of dependencies..."

The easy solution to this is to give elements names, which we can then use to filter the event stream, but that doesn't feel quite right. 

Ultimately, the problem is referential transparency: I want to be able to create two buttons that look identical but when I put them next to each other, they emit two different event streams. How is this possible if they are identical? They are not identical! When they were put next to each other, the position of one of them was changed in the layout function, and thus they emit different event streams! Of course in order to preserve modularity (so we don't only get event streams at the top level, when everything is being laid out), we need to use a trick I learned from Conal where you translate the event stream going into a "component" with the inverse of the translation you used on its position. (I haven't entirely worked out this scheme, but I feel it's promising.)

### Monad Reading

#### [What we talk about when we talk about monads](https://arxiv.org/abs/1803.10195)

From Jonathan Edwards. Great recommendation!

Be careful about the "romance of mathematics". It's perfect-ness is illusory. Yet despite this, I still feel like math is our best way to reduce incidental complexity.

This definitely made me even more skeptical of monads! He showed cases where people put the word "monad" in the title of their papers when it had no business being there - just to show how cool they were.

#### Monads and input/output (section 7 of ["being lazy with class"](http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf))

Fascinating to learn about. Moggi introduced monads to structure the denotational semantics of state and exceptions, but "a denotation semantics can be viewed as an interpreter written in a functional language" and "Wadler used monads to *express* the same programming language features that Moggi used monads to *describe*.

#### [Can functional programming be liberated from the von Neumann paradigm?](http://conal.net/blog/posts/can-functional-programming-be-liberated-from-the-von-neumann-paradigm)

I printed this one out and re-read it for the 7th time. It's so fucking brilliant.

"Programming is more about the middle than the end, i.e., more about composition than output." And quoting Roly, "What looks like imperative output can be just what you observe at the boundary between two subsystems."
We need imperativity in our functional code (usually structured with monads) when we haven't properly abstracted that particular API into a functional interface yet. For example, think about `putChar` and `getChar` from the terminal. How fucking imperative is that?! But FRP (even React) shows you that you don't need to put and get characters from the screen imperatively. Instead you can describe the UI input and output declaratively - no monads required! The way to get rid of monads is by abstracting over imperativity (databases, file systems, operating systems, etc), one by one.

### Other Reading

#### [Tangible Functional Programming](http://conal.net/papers/Eros/)

I enjoyed the beginning, but also had trouble sticking with this one, but hope to get back to it soon. It's so up my alley!

#### [Promise of Live Programming](https://2016.ecoop.org/event/live-2016-the-promise-of-live-programming)

This was a fun one. Live programming provides a rubric through which to rate a programming system, but not to come up with a programming system.

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

This is one of my favorites! These recipe diagrams are just devine! He really makes the case that functional programming is about explicit data dependencies, and it's gorgeous.

#### [Destroy All Ifs](http://degoes.net/articles/destroy-all-ifs)

Really great. He goes even further than I do when thinking about this topic: instead of inputting booleans (or union types) into functions, we should add lambdas, which are semantic explanations of what we want done.

### Todos as of 6/16/16

I'm continuing from [the last todos in this journal](http://futureofcoding.org/log#todos-as-of-52118) (without the completed or no-longer-relevant ones):

* Follow up with Jonathan Edwards with my research direction, current problem(s), next steps, ask for relevant papers, schedule next chat, and send him Woof code

* Read the papers I've printed out, including
  * [Push-Pull FRP](http://conal.net/papers/push-pull-frp/)
  * [Monadic Functional Reactive Programming](https://www.researchgate.net/publication/262292005_Monadic_Functional_Reactive_Programming)
  * [Practical Principled FRP](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.724.7758&rep=rep1&type=pdf)
  * [Hazelnut](https://arxiv.org/abs/1607.04180)
  * [Back to the Future: Time Travel in FRP](http://www.cs.nott.ac.uk/~psxip1/papers/2017-HaskellSymposium-Perez-BackToTheFuture-TimeTravelInFRP-latest.pdf)
  * [Lambda in Motion: Controlling Robots with Haskell](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.456.1707&rep=rep1&type=pdf)
  * [Fudgets](https://www.researchgate.net/publication/2247556_FUDGETS_-_A_Graphical_User_Interface_in_a_Lazy_Functional_Language)
  * [Tangible Functional Programming](http://conal.net/papers/Eros/)

* Other things to read
  * Simon Friis Vindum, including [Let's reinvent FRP](http://vindum.io/blog/lets-reinvent-frp/), Hareactive, and reach out to chat
  * Re-read [Elm goodbye to FRP](http://elm-lang.org/blog/farewell-to-frp). Maybe I'll understand it now. Or soon.

* Update the plan, possibly stealing stuff from the never published [plan v6](https://github.com/stevekrouse/futureofcoding.org/blob/3821ba9d0ad65a7f6aaea583be8283aba16558e5/plan.md)

* Reach out to Sean McDirmid, and maybe read [this paper he referenced](https://www.cs.colorado.edu/~ralex/papers/PDF/Conversational_Programming.pdf)