## 3/22/18 scattered notes

* TOC
{: toc }

### What I read/watched today

I got a reply from Kevin Lyangh which first sent me to [this video on statecharts](https://keminglabs.com/talks/#yow2015)

Then to I stumbled onto a few David Nolan talks, which I thought were interesting mainly because they referenced "Two Cultures of the Scientific Revolution" (which I recently read and didn't think much of), as well as Out of the Tarpit (which I also recently re-read and enjoyed). 

I then got pulled into [Rich Hickey's Value of Values](https://www.youtube.com/watch?v=-6BsiVyC1kM) which provided some good counter-arguments to my [thoughts about specificity](./notes/kill-primitives). Echoing what I just heard from David Nolan, he mentions that we almost always choose bad abstractions and that they often get too much in the way. This point really stuck with me, because abstractions and math seem so elegant, yet maybe their overapplication, like with class inheritance in Java, is what gets us into trouble. On the other hand, simple primitives are portable and easy to understand.

Then I read almost all of the articles on The world of statecharts, read most of the threads in the chat.

Rosmaro (and medium posts)

https://sverweij.gitlab.io/state-machine-cat/

I also read the first few chapters of [Ian Horrock's Constructing the User Interface with Statecharts](./media/Constructing the User Interface with Statecharts Ian Horrocks.pdf).

I also took [some silly notes on how I'm beginning to view much of the "evil" in programming due to historical accidents that have remained with us long past their usefulness](./notes/historical-accidents). (Side note: I think it's probably fruitless to look for "the root of all evil" in programming, be it historical accidents today or primitives yesterday. There are two ways to replace this persuit: 1. Be more explicit about trade-offs, and the contexts under which you'd choose between alternatives, and 2. Look for a positive philosophy of what programming is, almost in the John Dewey sense.) 

### What remains

* Finish reading [Ian Horrock's Constructing the User Interface with Statecharts](./media/Constructing the User Interface with Statecharts Ian Horrocks.pdf) after page 49.
* Read [xstate's docs](http://davidkpiano.github.io/xstate/docs/#/) and maybe bulid something in it
* Read the final two pieces of The World of Statecharts that I haven't read yet: [one](https://statecharts.github.io/use-case-statecharts-in-user-interfaces.html) and two](https://statecharts.github.io/how-to-use-statecharts.html)
* 
(read more about rosmaro guy's no if and no boolean, as well as the anti-if campaign)
* maybe post to [the statecharts chat](https://spectrum.chat/statecharts/general)
* read [this research paper about statechart UI building](http://phrogz.net/developing-user-interfaces-using-scxml-statecharts)

### Yearning for real-world problems

After watching all of these videos, I was left with a sense of blah. What do I do with all of these thoughts? Is this method or that method better? Under which circumstances? My thinking became so divorced from any concrete problems that I felt impossible to compare the trade-offs between alternatives.

And so I had an idea: what if I use coding on WoofJS as a way to explore many of these ideas. More specifically, what if I use refactoring WoofJS to explore some of these ideas?

The tantilizing idea would be to start small, maybe just one boolean flag, or one function, and slowly refactor the app back to some sort of sanity. Of course, we still are left with the problem of determining what is sane and what is insane. I don't want to simply move WoofJS from VueJS to some new platform, like CycleJS or Elm or xstate, and just have similar-ish problems but in a new framework. That's a very expensive way to try out a framework.

Yet on the other hand, I fear that re-building simple apps, like a button that counts how many times it's been clicked, or even ToDo MVC will not expose me to the truly intricate and sticky problems that would expose whether an approach is good, and also motivate alternative approaches to solving such real-world problems.

A relevant thought here is to bring in Alan Kay's advice to Samantha John: make a list of a few complex applications you want to be able to create in a framework to test and motivate its generality. This is reasonable advice. Some that come to mind:

* [ToDo MVC](http://todomvc.com/)
* [RealWorld](https://github.com/gothinkster/realworld)
* Basic scratch games (http://coding.space/scratch)
* Basic JS apps (http://coding.space/web)
* Agar.io 
* Candy Crush (Sam John's idea)

Author: Steve Krouse

notes/historical-accidents.md

@@ -0,0 +1,34 @@
+---
+Title: Historical Accidents
+---
+
+# Historical Accidents
+
+Is this the root of all evil? 
+
+A historical accident is technological compromise that persists despite overcoming the limitations it stemmed from. (Looker is a good example... databases used to not be fast enough for analytical queries, now they are. Plus redshift exists.) This perspective almost advocates keeping track of all compromises so that when technology improves, we know to update to the ideal case. Or more realistically, asking of a technology why something is not closer to an ideal or simpler state.
+
+Much of it comes from limited disk size. Some from processing power.
+
+Examples of "features" in programming languages that we'd do better without:
+
+* mutable state (this was more space efficient)
+* 0-index arrays
+* sequential evaluation: it's not just go-to's, it's all control flow, including if-statements, function calls with side effects (which are really just subroutines)
+* Even boolean algebra (and, or, not, nor) feels super historically tied to the way logic gates work. So low level! 
+* Fasly and truthy, and really all shortcuts seem to be the limitations of our code interfaces to do something like autocomplete for us so we don't have to type by hand
+* Event listeners are probably an accident or something (I'm thinking of the unification of states and events with the scheme I thought of for woof mousedown catching things)
+
+
+<script>
+
+(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
+
+ga('create', 'UA-103157758-1', 'auto');
+ga('send', 'pageview');
+
+</script>
+<script repoPath="stevekrouse/futureofcoding.org" type="text/javascript" src="/unbreakable-links/index.js"></script>