## Dec 3 2018 Notes

* TOC
{: toc } 

### First two weeks Dec 2018

This week, the focus is on the podcast and my freelance work. I would like to publish my reflection 14 episode as well as edit Katherine's episode and prep for and record Vlad's episode. Let's say the podcast will be Mon, Tues and Weds this week and I'll do freelance Thursday and Friday.

Next week I want to focus on research, playing with Turbine and other p4 thoughts...

### Equality of code

I asked Paul Chiusano about hashing code that's equivalent but syntactically different, such as 1+x and x+1, and apparently Unison "doesn’t normalize commutative operations." Some relevant links he sent me are [Normalizing](https://en.m.wikipedia.org/wiki/Normalization_property_(abstract_rewriting)) and [Rice's Theorem](https://en.m.wikipedia.org/wiki/Rice%27s_theorem).

### p4 thoughts 12/3/18

#### Start with non UI motivating problems

A way to simplify this problem is to build an FP playground to solve normal FP problems with cyclical streams first and work our way up to UI:

* Such as the problems that [Pane](http://joshuahhh.com/projects/pane/) solves
* Here's an idea for a developer tool extension slice-and-dice playground thing. Here's a common pattern I found useful: 	querySelect some nodes and map/filter over them a bunch, such as:

```javascript
[].slice.call(editorElement.querySelectorAll('*'))

  .map(e  =>  [e,  e.innerText])

  .map(([e,  text])  =>  [e,  text.match(/^(#+)\s.*$/)])

  .filter(([e,  m])  =>  m)

  .map(([e,  m])  =>  [e,  m[1]])

  .forEach(([e,m])  =>  {

    e.style.fontSize  =  (50  -  (5*m.length))  ||  3;

    e.style.marginBottom  =  2  +  "px";

    e.style.marginTop  =  2  +  "px";
  })
```

The issue with this approach is that we may create a FP playground that won't scale up to cyclical UI problems...

#### Fluidity is not the initial focus

I realize that part of why structured editors haven't been able to compete with text-based coding is:

1. Computers come with a hardware input device especially designed for text input: the keyboard!
2. We all have spent dozens of hours learning to use this keyboard for text input!

It's simply not a fair comparison to expect a new interface to be as fluid as text from Day 1. Of course fluidity is important and of course making it work with people's existing hardware and skills will help with adoption, but they aren't the first things to worry about. Maybe the ultimate interface will require new input hardware and/or a lot of practice to get the hang of. Hopefully we can get away with the keyboard and mouse and make the onboarding simple, but we don't want to pigeonhole ourselves over it.

The initial focus should be on the comprehensibility of the code and the liveness of the experience. Liveness means that an incremental action should result in an incremental result. This is possible without fluidity, which means that "taking the incremental action" may not be ergonomic for some reason.

(However, I will note that fluidity is SUPER important to me. I would love to build an interface that's only optionally dependent on the mouse.)

#### All Literals are GUIs...

If we throw out text-based coding and agree to a structured editor of some kind, you may realize that we can automatically represent colors as a color picker instead of (or in addition to) a hex value or rgb value. Cyrus Omar has work where he embed's a regex playground right into the IDE. (As Tudor Girba says, whenever you leave the IDE, the "I" has failed.)

If you follow this line of thinking, you realize that ALL literals are GUIs! Numbers can be scrubbable or many other interactive representations, booleans are a checkbox thing... We can even nest GUIs! You could have a string as a widget which is basically a text box but you can add other arbitrary expressions inside - no more escaping characters necessary! Lists can be a specialized GUI where you can add and remove expressions or do comprehensions. 

We can continue this idea for all kinds of expressions: if-expressions, pattern-matching, lambdas, function application... Can we build nestable custom GUIs for every part of System F/Haskell?! I think so!

The key here is the nestability. Normally a color picker or other GUI is a top-level thing. But why? I don't see any reason why it can't be as expression-like as coding.

When you define a function it will default to a basic representation but it should allow you to *add a more specific GUI to represent your function!*

These thoughts were inspired mostly by Tudor Girba, but also are related to [Niko Autio's Microeditor ideas](https://futureofcoding.org/notes/niko-autio-microeditor.html). 

I am curious how to combine this idea with the ideas of Hazel and Josh's principle of radical visibility of preview evaluation with test data. Same with the hashing stuff. There are so many cool PX ideas to combine together!

Drawing this out will be interesting. And if I can show how we can do any pattern from Haskell, completeness is guaranteed!

In terms of implantation, not sure if HTML or canvas is the way to go. Would be fun to play with Turbine on this project...

Author: Steve Krouse