## Feb 27, 2019

* TOC
{: toc }

### Salon de Refuge 2019

I've spent a ton of time on this the past couple of weeks. It's been a bummer because it's time away from my Turbine devtools visualizations. But it's not wasted time, for sure. I've learned a ton! Done a lot of research and firmed up my thoughts about things.

Yesterday I had a really wonderful conversation with JE about how to move forward, considering that my paper needs drastic improvements and reduction in scope. We considered a lot of things, but ultimately decided it could be good for me to explain how I became convinced of the original FRP paradigm, instead of trying to argue for it in the abstract. I spent all day today on it and put it on the dctp draft file, where I've been keeping all of this work. It may be silly but I didn't feel like polluting this log with all those random notes.

### Questioning the Salon

The past week I did a bit of traveling, and lost some work time there. I've also been feeling a bit bummed about working on this Salon essay instead of my Turbine visualizations. Part of me thinks I should just scrap the Salon essay, pull out, not go to >Programming< at all, and just focus on my devtools.

Otherwise, I only have 2 weeks before going to SF where I may not get much research done at all, then a week at home, and then >Programming<. Basically, I am worried that come April 8th, I will be right where I am now on my main research thread.

Instead of that, I could use those three weeks to make solid progress on my devtools visualizations.

Or I could zoom out and see this as a longer-term investment in my career as a researcher. I am getting myself out there, explaining what I am doing and why I think it important, and setting the state for interesting research in the future. 

Also, I wonder how little work I can get away with. Maybe the presentation I came up with today is decent, only requires another few hours, and I can ask not to be published (or just allow my original piece to be published because who cares?). Jonathan will help me navigate this...

### Week of 2/25 and 3/4

The rest of today will be random inbox tasks, such as organizing the London and SF meetups. Tomorrow is travel so I do not expect to get much work done. 

Friday and all of next week is open. I want to work on:

* make progress on Turbine viz (30 hours)
* researching Coda for Dark (4-7 hours)
* organize London and SF meetups (4 hours)
* organize SF trip (2 hours)
* publish JE podcast (5 hours)

Author: Steve Krouse

drafts/dctp.md

@@ -1115,6 +1115,71 @@ shielded from operational... (what about https://granule-project.github.io/resea
 
 Can we do with just functions at the bottom (no types and combinators) or do we need those for speed?
 
+### Web Programming Without Migranes
+
+I taught kids to code in Scratch, which was awesome, but eventually they wanted to make web apps.
+  
+So I built a blocks for JQuery. [http://cycle.thecodingspace.com/#fjweme](http://cycle.thecodingspace.com/#fjweme)
+
+JQuery. Great for simple things.
+
+Problems: Hard to keep everything in sync. Have to worry about all possible state paths. String identifiers.
+
+[https://jsbin.com/cimabug/edit?js,output](https://jsbin.com/cimabug/edit?js,output)
+
+I saw my 11-year-olds getting burned by mutable state everywhere, but try convincing 11-year-olds to follow code conventions. It’s much easier to bake those conventions into the language and not give them the rope to hang themselves.
+
+Enter reactive programming: ReactJS, VueJS, CycleJS.
+
+Describe the view as a pure function of state, where state changes over time. Automatically keeps view in sync with state. 
+
+So I built a blocks for React. [https://stevekrouse.com/cycle/index.html#count-the-clicks](https://stevekrouse.com/cycle/index.html#count-the-clicks)
+
+Problem: child elements have to update parent state. Example: editing todo items need to propagate changes to the whole list.
+
+Enter: Redux, The Elm Architecture.
+
+Store all app data in a single large object and emit actions from child nodes that update state.
+
+Problem: non-modular, loose coupling on strings
+
+Ultimately, the problem is loopy-ness between our state and view:
+
+- The JQuery solution is string identifiers (of HTML elements) and global mutation 
+- The Elm / Redux solution is also string identifiers (but of Action types) and simulated global mutation 
+  
+
+Why don’t we do recursion the FP way? 
+
+- No string identifiers 
+- No mutation 
+- State is a local as possible 
+  
+
+This requires
+
+- Recursive monads 
+- Complex higher-order flow types 
+- And there are no popular libraries for it 
+  
+[https://codesandbox.io/s/j7k1no7659](https://codesandbox.io/s/j7k1no7659)
+
+Never mind! String identifiers and simulated global mutable state are fine.
+
+Wait a minute. Can we make these cyclical, higher-order streams understandable by humans?
+  
+Visualizations?
+  
+[https://user-images.githubusercontent.com/2288939/52494957-9e906a80-2bcf-11e9-95bb-a4505688183c.png](https://user-images.githubusercontent.com/2288939/52494957-9e906a80-2bcf-11e9-95bb-a4505688183c.png) (I’ll want to improve this and make it about my simple todo list running example.)
+
+Ultimately I hope to make a non-textual editor for user interfaces: Scratch for web apps. (You could also say website builder, like Squarespace, weebly, Wix, etc, of arbitrary complexity.)
+
+#### Notes
+
+- [http://soft.vub.ac.be/~cfscholl/ProWeb17/ProWeb_2017_paper_5.pdf](http://soft.vub.ac.be/~cfscholl/ProWeb17/ProWeb_2017_paper_5.pdf) 
+- [https://web.archive.org/web/20180530055638/https://futurice.com/blog/reactive-mvc-and-the-virtual-dom](https://web.archive.org/web/20180530055638/https://futurice.com/blog/reactive-mvc-and-the-virtual-dom) 
+- [https://docs.google.com/presentation/d/1lKAwh7x1oQel88tJrW211R90k3cQZHSXyvaz3wBhmwM/edit#slide=id.p](https://docs.google.com/presentation/d/1lKAwh7x1oQel88tJrW211R90k3cQZHSXyvaz3wBhmwM/edit#slide=id.p)
+
 ### Multi-node DCTP (potential draft 2)
 
 Dikstra's 1968 Goto Considered Harmful argues that we can produce better code by replacing goto with structured commands, such as functions, if-statements, and loops. In this tradition, the functional programming community has continued to demonstrate how we can produce better programs without various side-effects, sometimes with the introduction of new language features. For example, many forms of mutable state can be expressed with recursion.  

notes/jonathan-edwards/02-27-19.md

@@ -0,0 +1,80 @@
+---
+title: JE Meeting 02/27/19
+---
+
+# JE Meeting 02/27/19
+
+talk forces me to focus on headlines
+what am I really saying if I only have this much bandwidth?
+
+Steve: expressions are the way to go
+JE: that's the whole FP thing
+Steve: what about that all FP isn't FP enough like my last paper
+JE: Haskell is imperitive is already a thing. already too general a point
+JE: lots of people are waking up to monads aren't great and now are exciting about algebraic effects
+JE: this feels too much of a common message
+JE: FRP feels like the core of your message for a while
+
+explaining pure frp / conal to humans
+good enough for salon
+key: explain denotational religion to normal people
+how neat would this be and explain some of the benfits 
+but here's where it falls down and open problems
+it's not there yet
+have to admit its more complicated than ex. the elm architecture or something
+
+more modest claim is more interesting than a solution
+promising idea is better gives people something to do
+
+relational database were denegrated because too inefficient compared to my hand-optimized hand traversal algoritms, but they were wrong because we could have a general-purpose optimizer that does better than people... when people complain about sql they don't hand-write queries but just optimize sql... it doesn't solve everything buts its known as a big win. parser generators are another great example of this. there are technical connections between the two query optimization. why can't we do this for programming? focus on semantics and have a smart compiler do the optimiziation? programming is premature optimizaion handling bits and pointers...
+
+fp is about the what not the how, but it breaks down when we get big stateful systems. the advanges are irrelevant when simulating imperitive so we need to go further, so we need to go further and get the true semantics of them so we don't encode sequential semantics. it's frp but we haven't figured out how to do it yet.
+
+the story is about the failed promise of functional programming: was about to solve all our problems by getting rid of all our implementation details
+
+how the hell is memoization so hard in FP? why doesn't naive fib work? https://wiki.haskell.org/Memoization
+
+specification langauges throw aroudn quantifiers and sets and there are no way to implement those searches. prolog is done via searching and you specify how the searching happens. easy to check if specification is correct, but really hard to generate. like cryptography.
+
+there's no one essential complexity, but for any problem, there's some incidental and we're looking for better ways of reducing incidental complexity. there's no one optimal way of programming, but some ways have more complexity than others for variuos problems.
+
+for a wide class of problems, fp removes a lot of complexity that imperitive programing has.
+
+fp makes progress by getting rid of inesseitnal state, but when state is essential fp has problems. so what do we do when state is essential? FRP is an answer there.
+
+------------------------------------------------------------------------------
+
+the talk to give at salon is the talk motivating your research. get up there and explain what I'm working on to my fellow researchers. this is your problem statement. here's why I think this is an interesting idea that has promise that'll revolutionize the world.
+
+one option is to tell the story of how I became convinced of this way over the other ways.
+
+then explain how there are open problems that need to be solved and which ones I'm working on now.
+
+the talk can be really different from the paper. don't worry about the paper, just put your talk together. when it's done we'll make a call on what to do with the paper.
+
+------------------------------------------------------------------------------
+
+jquery --> neat but suffers from mutable state, etc
+
+trying to do fp UI with fay (silly poem?) --> a nightmare, just simulates jquery
+
+reactJS --> I fell in love. but there wasn't a great story for updating state
+
+Redux / Elm architecture --> I fell in love again. Then I worked on a large redux app and realized the out of tarpit problem
+
+Read staltz article about where the arrow lives. Fell in love with CycleJS. Const everywhere. Problems: hot and cold observables. Elm architecture again. String ids to connect things.
+
+Finally found my way back to Conal FRP and struggled for a while and eventually got it. Problems: no popular libraries (most in Haskell), doesn't transition to HTML-type interfaces well, really hard to work with the types (visualize things) http://soft.vub.ac.be/~cfscholl/ProWeb17/ProWeb_2017_paper_5.pdf
+
+Benefits of it: 
+  - denotative, so only subexpressions and no action at a distance
+  - no strings ids to connect things, solve recursive knot with true recursion (but the fixpoint thing is a total nightmare)
+  - less random apis (redux middleware, hot and cold observables) but harder to implement (no great ones)
+
+Ultimately I want  modular/proportional understanding. I don't want my head to hurt. (Watching kids untangle messes. I don't want to give people the rope to hang themselves.)
+
+1. the arrow must live at the mutated thing - no action at a distance
+2. the computer must be able to staticly determine what could affect what (redux and string connectors are too messy)
+3. the api should be as simple as possible  - least amount of arbitrary concepts, like middleware, dependency injection, etc... maybe cut this part out....? 
+
+Maybe add stuff about JQuery blocks, react blocks, js projectional editors to what isn't harmful...?