## March 4, 2019

* TOC
{: toc }

### 2/28-3/4

I haven't been very productive the last few days. I came down with a cold towards the end of Saturday. I did just an hour of researching Coda for Dark, organized the meetups, started a test Zulip, and published the JE podcast. Ok, so not nothing, but I really need to get back to my main research! 

Oh, I forgot! I also read 14 chapters of TaPL on Friday. Not my focus but still worthwhile!

### Sad Mantras

Sometimes I find sad mantras rattling around my brain. At one point it was "grass is always greener" when I was considering doing something else, but everything I tried was worse than what I was doing. Ultimately, I got over it and now feel that research is a great choice for me. I don't salivate over other careers anymore or imagine them as rosier.

I do have a new mantra I've been trying to kick: "what do you have to show for your efforts?" I do have almost 40 podcasts. The Dynamicland essay and the LIVE bootleg. The Slack and a few meetups. A Twitter history. A very long research journal. A mediocre paper and presentation at REBLS. Another soon-to-be mediocre paper and presentation at the Salon de Refuge. 

I want something polished and shipped that I can point to. I think my Hareactive/Turbine devtool could be it, but maybe I should consider hacking it together in the Bret Victor style of a cool demo, but not an actual usable tool. After all, I'm not sure Hareactive/Turbine is the end-all-be-all that I want to support. It's more just a decent library I can use as a proof-of-concept.

### Gametrail 3/4/19

I'm going to henceforth refer to the Hareactive/Turbine devtool as gametrail because of "hare" and it's about following the paths of events and stuff. And "Hareactive/Turbine devtool" is too damn long.

One clear next step is from my last meeting with JE, where he suggested flipping the diagrams 90 degrees so that the flows flow downwards, which will allow the text more space. I think it'd definitely be worthwhile to re-do some of the mockups in this direction -- though maybe I should hold off until I do one or two more of these in live HTML so I get a better sense for how they feel. I could do the next live HTML one vertically, too.

I also had a really wonderful call with Josh Horowitz about layout algorithms on the 15th of last month. I've been meaning to add it here. One key point he made was that if a layout specification starts to "feel like sudoku" than it's probably undecidable and you need an algorithm for it, that'll likely have unpredictable outputs. What if the user deletes one node and the whole thing rerenders? Clearly that's not what we want. He made a really solid pitch for simple, mostly linear graphs, possibly in HTML with embbed shapes instead of in SVG with foreignObject text, with maybe a few wormholes here or there for the far-away branches.

In short, I need to go back to mocking up!

### Lambda calculus on the brain

I finally bought Pierce's Types and Programming Languages, TaPL from Stephen Diehl's recommendation. I also bought PFfPL from Cyrus Omar's recommendation, but haven't gotten it yet. 

After reading it all Friday afternoon, I thought about it a lot, particularly on my run yesterday (which likely helped get me sick). It got me wondering about how function substitution is so strange, including all the variable re-naming tricks we need to do to get closures to work. I also thought about how function scopes are super similar to objects/dictionaries. In other words, I was questioning the primacy of the functional approach.

Sometimes I think about how functions are really just constant expressions that you can reach into and tweak various parts of simultaneously. So they're "linked constants" + "tweakable constants". But I guess that doesn't cover first-class functions which are a strange closure thing.

All these thoughts eventually brought me back to an idea I've had for the last few months: taking denotational semantics seriously for user interfaces. Define *everything* as a function from x, y, t, keyboard events, and mouse events.

Part of how I arrived at this idea was I was thinking about how complicated HTML child to parent communication is, which is what spent last Wednesday on, and is related to my convo with Josh about layouts. But I am wondering if the HTML / CSS box model is clouding my thinking, and was wondering if I went to the denotational basics, I could get to the bottom of the complexity here. 

I thought about how to implement two input boxes, down to modeling the cursor as a rectangle. I didn't get very far with this. I bet, just like with multi-tier languages, there is a whole research topic that pulls on this thread of "layout languages." Of course there are the SAT Solver / cassuary things, but those run into the "sudoku solver" issues.

At the very least, I'd like to get to the bottom of the *essential complexity* of common, 7 GUI, interface problems, and see if I can express their inherent recursiveness elegantly. 

### Speaking of essential vs incidental complexity...

I'm beginning to get tired of these terms, because nobody ever defines complexity or points it out precisely. It's always hand-wavy. I have a sinking feeling this is an issue.

### Week of 3/4/19

Today was mostly a bust on account of the cold, but I did get the Zulip started, a bit of Coda research, and this log done. Tomorrow I will likely still feel sick, but hopefully I can get a few hours of work done, maybe Coda, email, or Gametrail mockups. I'd also like to get my meetups finished organized -- as they are both very close to "done".

Author: Steve Krouse

notes/josh-horowitz-2-15-19.md

@@ -0,0 +1,32 @@
+---
+title: Josh Horowitz 2/15/19
+---
+
+# Josh Horowitz 2/15/19
+
+_Chat about layout_
+
+- started with react and lots of math with x and y
+- render children and propogate back up, do it once for each layer
+- constraint-based 
+- cassuary
+- don't need parent-child communication -> single place solves all constraints
+- he gave up on foreigntext in svg
+- browsers don't support svg consistently, especially with foreignobject
+- position html elements over svg works fine
+- cassuary replaces the need for svg g element because that handles layout
+- solvers usually have imperitive APIs so he built a declarative thing on top of cassuary (like react is for the dom)
+- cassuary is very limited. only linear equations and equalities, which means it can't do very much. only lay out things with the structure of trees. not force-directed graph layout. it can't tell you if two boxes overlap or not because that requires OR operator which it doesn't
+- could think of it as a tree with a few little loops (instead of a graph), so you think of it as a directed acyclic graph with a few extra arrows
+- layout problems very quickly become np complete because of the possibility explosion of ways to combine things
+- here are some parameters, here's a function of how good a layout is --> fiddle with the parameters until we optimize the "good" function
+- josh is skeptical it can do large complex layouts because it gets trapped in local minima. it runs itself into a weird corner
+- optimization problem
+- if it looks more like solving a suduku puzzle, it won't be magic
+- maybe machine learning would be relevant
+- could make a wormhole for arrows to hide the part that would overlap
+- graphviz -> there are papers that describe these algorithms
+- could do canvas and position html elements absolutely on top, but more work to handle mouse events 
+- you can represent the network like a big graph, or use names, or the wormhole ideas
+- simple layout structures are more predictable for the user to anticipate and control, and won't be jarring when changes happen
+- could have layout be stateful/incremental so that things just change as little as possible based on how they are now