Skip to content
Browse files

## Feb 27, 2019

{: 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)
  • Loading branch information...
Steve Krouse
Steve Krouse committed Feb 27, 2019
1 parent a3072bc commit f8aae3560ab97f07021eeed7a6d41d8d243a6c3f
Showing with 145 additions and 0 deletions.
  1. +65 −0 drafts/
  2. +80 −0 notes/jonathan-edwards/
@@ -1115,6 +1115,71 @@ shielded from operational... (what about

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. [](

JQuery. Great for simple things.

Problems: Hard to keep everything in sync. Have to worry about all possible state paths. String identifiers.


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. [](

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


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?


[]( (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

- [](
- [](
- [](

### 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.
@@ -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?

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)

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...?

0 comments on commit f8aae35

Please sign in to comment.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.