## Chores and reading

Today I wasn't really in the mood to do much hard thinking, so I spent a few hours in my inbox catching up on things, doing random chores around the house, and finally brining myself to do some reading relevant to the research topics I've been thinking about lately.

I started with reading [Ian Horrock's UI with Statecharts](http://futureofcoding.org/media/Constructing%20the%20User%20Interface%20with%20Statecharts%20Ian%20Horrocks.pdf), but to a break to go directly to the source ([Harel's Statecharts](http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf)), and then back to Ian's book. I read parts and skimmed parts of both. They seemed semi-relevant to what I'm trying to do. As far as I could see, neither referenced the management of complex, nested state. They seemed to assume that non-state data (such as the currently displayed value on the calculator screen) was stored somewhere magically.

I then read a series of Andre Staltz posts. It turns out my link to his post on Friday was actually the incorrect post. I meant [this one](https://futurice.com/blog/reactive-mvc-and-the-virtual-dom). He had a lot of other interesting posts, but I found myself not excited about the conclusions he drew. In particular, I didn't like his discussion of [hot vs cold observables](https://staltz.com/cold-and-hot-callbacks.html) because I don't love his conclusions, although I couldn't find any fault with his logic. It'd be a bummer if there wasn't a more elegant way to model this distinction. It really seems like an incidental complexity type of thing. I also came to realize that I find stream-based programming a bit annoying. While it's kinda cool, I wonder if it's overly abstract, the way Haskell can get sometimes.

I then re-read (for the 10th time), [Elm's Farewell to FRP](http://elm-lang.org/blog/farewell-to-frp). Again, an article that feels profound but that I don't like for some reason, mostly because there are a lot of concepts in it that I don't quite understand, but don't like the conclusions reached. It feels similar to when I had to learn AngularJS. I don't really know what the concepts mean, but I can tell somehow that they are less elegant than they could be.

From there I found my way to [Lucid Synchrone](http://www.di.ens.fr/~pouzet/bib/chap_lucid_synchrone_english_iste08.pdf), but stopped after a few paragrahs, and just like with statecharts decided I wanted to go to the source, so I started reading [Lucid](http://worrydream.com/refs/Wadge%20-%20Lucid,%20the%20Dataflow%20Programming%20Language.pdf). I'm actually a little shocked that I haven't read this before. There's so much here that I was slowly coming to on my own, but it feels like they've brought it all together for me. And, of course, Bret Victor is a big fan of it I've heard, although I wasn't able to find his thoughts on it anywhere on the internet. My next steps are definitely to read through this, and maybe the Synchrone Experiment.

And as much as I want to avoid it, it seems like I may have to get my hands dirty with all this theoretical stuff. Read the Fran paper, other Conal Elliot stuff, maybe read Evan's Elm thesis, as well as other Elm blogs, etc. I imagine all of this stuff could provide interesting conversation topics with Brent next week...

Author: Steve Krouse