## A productive few days in late Nov 2018

* TOC
{: toc }

### Fun Calls

#### JE

Went really well. [Notes here.](/notes/jonathan-edwards/11-21-18) The end-result was that I should either find or build my own Reflex alternative in JS. It's easier to start from a compile-target, a DSL, than from a visual editor. Once I have this built, I can use it to think about visual abstractions to compile to it. And I can use the framework to build those abstractions in a bootstrappy way.

#### Philip Tchernavskij

PhD student in Paris also interested in the malleability of software, but coming from the HCI and political perspective. His work sounds a lot like Dynamicland.

#### Kartik Agaram

Another person interested in the same goal / themes of software malleability. It's really fun to chat with people like Kartik and Philip where we agree so much on goals but are coming from different places and see entirely different implementations of these ideas. I got Kartik, to agree to [record the conversation as an experiment](https://www.youtube.com/watch?v=DuMdDXCMDk0). I think it went well. Apparently 18 people watched it. Maybe if we continue chatting from where we left off, I can grab the audio from the conversations and turn it into a podcast. Or maybe we can do a podcast from scratch at some point.

### Blinknote

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">💭Yesterday I wished for a dream note-taking chrome extension<br><br>🎁<a href="https://twitter.com/dankantor?ref_src=twsrc%5Etfw">@dankantor</a> supplied with me the initial code<br><br>👨‍💻I hacked for ~2 hours last night<br><br>✨I have a working Chrome extension! <a href="https://t.co/51Res4TnlI">https://t.co/51Res4TnlI</a></p>&mdash; Steve Krouse 🇬🇧 (@stevekrouse) <a href="https://twitter.com/stevekrouse/status/1065938988920422402?ref_src=twsrc%5Etfw">November 23, 2018</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

This was a really fun project, and it really energized me. In my head, hacking this together was like running up a hill and the prideful energy I felt afterwards was like running down the hill and I still feel like I'm running downhill three days later! I am actually writing this journal entry in Blinknote. It's so amazing to use tools that you make yourself. So much pride. It definitely encourages working and working with more of a smile. It also allows you to feel less boxed in - you can change things if they don't work for you. 

It makes me even more excited for my vision of programming as allowing others to make their own tools, collaboratively. Working on ones own tools makes me think of whittling a spatula from a branch with a knife. However I don't think that's the right metaphor for my system because I want to highlight the collaborative nature more.

### FoC London dinner

This was a lot more work than I expected, finding a restaurant, getting people to RSVP,  setting up payments, emailing people, dealing with dietary restrictions, confirming with restaurant, people's plans change, etc. One way to keep myself sane during this process is not to judge myself on the outcome but on the process, and even by just the fact that I'm doing it, trying things. My refrain is "full credit for showing up". I hope it goes well Wednesday!

### Kits vs apps

This is a common theme I've seen a lot ever since my visit to Dynamicland. I saw it again in Pharo and wrote up [a draft / ouline of an essay about it](https://futureofcoding.org/drafts/boundaries).

I've never liked the kit idea. In another incarnation, it's "everything is a document". I think the STEPS project had this. It's always felt messy, ugly, and lame. On one level this is just a surface thing: overlapping windows, lots of gray top navs of windows, nested menus and right-click menus. 

However on another level it feels like the messiness is a bit real. For one, it's usual a dynamicly typed system. For another, it always feels less polished and usable than apps. As in, I can't imagine my mom using it.

### I'm over the web

This is a big deal. For a while I've thought that HTML, CSS, and JS would be ok, as a compile target, but I no longer think so, particularly after Tudor showed me Pharo. He made the point that having everything in "a single render tree" is really key, and I don't feel I quite understand why but this does feel critical to me intuitively. 

Differences include: 

* single render tree, mentioned above
* different security model that will allow more things because it will expect users to understand more of the code they are "importing"
* caching that will make more sense, better offline & online story, maybe some peer-to-peer in there too
* different computational model from JS and HTML DOM

Thus my goal-system-I-have-no-name-for (wow, I really should come up with a working title for this... potluck? d1 for dream 1? I guess logichub could be d2?) will have to be built on a new system. Initially this system can be embedded within the web as a web app, but eventually I can imagine it having its own standalone "browser" that would work on various operating systems. Or I guess it could turn into an operating system itself!

Why start as a web app? I have to pick some platform and web is what I know best and I hate installing things and I love my chromebook so web seems like a solid pick.

The key question for all smalltalk-like systems: how do you prevent it from becoming its own universe? For example, Pharo or Lively Web.

My answer is that you start with single-user apps, starting with daily productivity tools, like notes, email, calendar, task management, and then once you have a critical mass, people will slowly spawn more ambitious projects that the community will use, and it will grow from there. 

I guess if it works within a webapp, people can use it on the web, so that's a pretty good story, as compared to Pharo which requires a download. So maybe the answer is that if we build it on the web to start with, it could seem like a website to most people, kinda like Lively Web or Tiddlywiki.

### Fluidity vs structure

I need to spend some time defining fluidity and structure, but this graph feels provocative:

![](https://i.imgur.com/iVXH72a.jpg)

I think fluidity has to do with live-ness, feedback loop speed, incremental actions causing incremental result, etc. And structure has to do with possible / impossible states, types, schemas. I'm stuck on where AST editors fit in this layout: they enable greater feedback loop speed knowledge of errors and prevent error states, yet they are not as fluid as using text but text doesn't give you as much info as fast.

One interesting note is that Airtable is particularly noteworth as having high structure and also high fluidity.

### Conal -> Turbine

Just as I decided (in the last meeting with JE) to build or find a JS lib for DCTP, I popped onto Twitter to find this:

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Stumbled across another *spot-on* post about FRP by <a href="https://twitter.com/paldepind?ref_src=twsrc%5Etfw">@paldepind</a>: &quot;Let&#39;s reinvent FRP&quot; <a href="https://t.co/Ga7ywHnySI">https://t.co/Ga7ywHnySI</a> .</p>&mdash; Conal Elliott (@conal) <a href="https://twitter.com/conal/status/1066073714104532994?ref_src=twsrc%5Etfw">November 23, 2018</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

Which led me back to [Turbine](https://github.com/funkia/turbine), which I had found a few months back and mistakenly disregarded as the "wrong kind of FRP" as mistakenly interpreted their Now monad thing. I'm now quite excited about this library! I already sent two long emails to the creator, Simon, and hope he responds soon. Here's what I wrote I'd like to collaborate on:

> 1. Documentation. For example, I had to figure out how `list` worked from reading the source and puzzling together a few examples without explanations. I'd love to help document every function in the API. (Additionally, I believe the code itself could use some comment documentation but that's more up to you.)  
>  
> 2. Understanding the types of the streams I'm working with would help a lot. Maybe getting TypeScript set up ([as I failed to do in the issue above](funkia/turbine-starter#2)) would help here. 
>  
> 3. Being able to "inspect" streams better as a debugging and understanding tool. [CycleJS has this wonderful devtool](https://github.com/cyclejs/cyclejs/tree/master/devtool) and there are [a number of other really cool stream visualization tools](https://github.com/stevekrouse/futureofcoding.org/blob/95bad27a4d9e2bbd0b186b7683eecf97197fe068/drafts/frp.md#71-visualizations) we can draw on for inspiration. At the very least, a better `console.log` story would go a long way. It was really tough to figure out what was going on with my streams.  
> 
> 4. Collapsing higher-order streams is really hard, but luckily [this picture](https://user-images.githubusercontent.com/2288939/48842176-78ef8400-ed8b-11e8-8996-307d841f9ac5.png) makes it a LOT easier. It saved my life last night as I was working on my favorite FRP problem of [buttons that add buttons that add buttons... but only the odd buttons](https://codesandbox.io/s/w2kvqr5nw8). Maybe we can build on this picture somehow or at least incorporate it into the documentation...  
>  
> 5. [As stated in the issue above](funkia/turbine#81), I don't like the way the model and view are separated. I wonder if it's possible to combine them like in Reflex and other "original FRP" frameworks.

And after we/I work on these more pressing issues, the next step will be building a layer on top of that Turbine that would make the development experience *much* better. That is, building a GUI that "compiles" to Turbine, for example, kind of in the spirit of Conal's Tangible Functional Programming. Here I am referring to more radical ideas than improving the documentation or a simple devtool, such a projectional editor in the spirit of Lamdu, Luna, Isomorf, Dark, Unison, and Hazel. 

### Todos 11/26/18

* wait for Simon palepind response
  * maybe get started on some of the issues: documentation, try to combine view and model, build 7guis things, play with TodoMVC if they have it (or build it)
* reflection episode
* edit Katherine podcast
* [regroup projects](https://futureofcoding.org/log#possible-dec-2018-re-group-projects)

Author: Steve Krouse