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

the arrow must live at the mutated thing - no action at a distance
the computer must be able to staticly determine what could affect what (redux and string connectors are too messy)
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…?