## Dec 13, 2018

* TOC
{: toc }

Feeling a bit overwhelmed, rushed, frenetic today for some reason. Deep breaths, Steve, deep breaths.

### One prototype at a time

[History and future of p4](#86)

Now that I'm settled on Turbine (modulus the 15 issues I created, and many more to come), I'm beginning to think about what I hope to build with Turbine: p4.

I was getting a bit overwhelmed with all my ideas for p4. I made a big list and asked JE for help figuring out what's essential and what I can do without for this prototype:

* Immutable editing
	* content hash like Unison and IPFS
	* do we hash definitions or expressions?
	* do we do work to cannonicalize hashes? (such as commutativity of addition)
	* no delete
	* no edit, only create new thing
	* refacorting
* Detachable GUI Literals
	* Everywhere you have a GUI, you need to be able to put an expression: detachable GUI literals!
	* GUI for every system f language primitive
	* Bootstrap visual editor?!
	* Are all apps just expressions visualized?
	* Expression-based operating system instead of file-based or app-based
* Other ideas
	* A la carte language semantics, like haskell langauge extensions
	* Always running, like spreadsheet or google doc, no run or pause, only open or close
	* infinite canvas (can I still use Turbine...?)
	* exploring which concepts we can move from the language compiler to the editor (no free variables, type inference is just local if not just a type “suggestion”)

He helped me realize that most of these ideas represent *entirely different prototypes*! I can't just combine them all like this. Prototypes explore one new idea at a time. So what's the idea for p4?

JE hit the nail on the head: p4 is an IDE for Turbine. This is particularly funny because p1 was an IDE for JQuery and p2 was an IDE for VueJS! Those both used blockly but that wouldn't help with p4 because blocks solve a different problem than what p4 is trying to solve: improve the PX of DCTP, most directly by _showing live streams as the user interacts with the output_.

On my run a few hours ago, I was thinking about what my data model would be for p4. Then it hit me: Turbine is the data model. (Along with hareactive, io, and jabz.) Those stream data structures *are the thing the p4 user is creating*. 

I *could* start p4 by building a projectional editor for Turbine/hareactive/io/jabz and all of JS. But can I get away with less?

One way to get away with less is to build a UI for the turbine/hareactive/io/jabz functions/combinators and then have users type regular text js where we need functional expressions (similar to aprt.us and pane).

The other way to do *even less* is to allow text to be the interaction model for Turbine and simply start with a devtools that shows the streams. If my main conviction is that seeing the streams will help, let's *just* do that. What's great about this idea is that a stream visualizer is a pre-req for any other p4 end-product anyways, so I might as well just publish it as it's own thing, and then move on afterwards.

In summary, p4 is now the Turbine devtools project, in the spirit of the CycleJS devtools.

Wait... because this feels reachable (I can imagine myself achieving it in early 2019 and it existing), it makes me wonder more about next steps...

* Do I try to take up the Turbine mantel and get others to use it?
* Do I go towards the structured editor idea?
* Do I experiment with one of the other ideas listed above?

All valid answers. The thing is, whatever I do, I need a UI library I love, and that library needs a stream visualizer, so build that first. And then we'll talk.

### Donation platform

Before starting the Patreon, I wanted to look around for alternatives. I found Stripe, Paypal and Donationbox allow for subscriptions with much less fees. However, I asked a few people with Patreons and a few of the people who said they'd be my supporters, and both said that I should stick with Patreon, mostly for the branding. It explains itself and gives off the right vibes, which is hard to do with a do-it-your-self platform. Patreon it is!

### Next week

* p4 & Turbine
* Patreon launch
* couple hours of freelance

Maybe something like:

* Monday - Patreon
* Tuesday - Patreon
* Wednesday - p4 & Turbine
* Thursday - p4 & Turbine
* Friday - freelance

Author: Steve Krouse

_data/git-log.json

@@ -0,0 +1,151 @@
+---
+title: JE Meeting 12/12/18
+---
+
+# JE Meeting 12/12/18
+
+* TOC
+{: toc }
+
+## Steve work recap
+
+### /about
+
+In a good place. Current thoughts:
+
+**JE:** likes top-level vision of customizing software
+**JE:** Mixed feeling with email client. Hits home and relatable. The risk of desigining for myself and other programmers is don't break out of what we already know. In design, there's the phrase "you are not the user"
+
+
+1. It's too in the clouds for day to day thinking. Only to edit every couple months
+
+**JE:** Complex, multi-front battle. Fog of war. You do probing maneuvors with a team of scouts to learn something about what happens. Need to do multiple probes in different directions. Such as the FRP paper
+
+2. Maybe it's too broad and I should collapse to something like Kartik's which is:
+
+> I'm working on ways to better convey the global structure of programs. The goal: use an open-source tool, get an idea for a simple tweak, fork the repo, orient yourself, and make the change you visualized -- all in a single afternoon.
+
+3. Maybe I should be less up front with my ambition...?
+
+> Let me conclude with some tactical advice. If you want to take on a problem as big as the ones I've discussed, don't make a direct frontal attack on it. Don't say, for example, that you're going to replace email. If you do that you raise too many expectations. Your employees and investors will constantly be asking "are we there yet?" and you'll have an army of haters waiting to see you fail. Just say you're building todo-list software. That sounds harmless. People can notice you've replaced email when it's a fait accompli.   
+>   
+> Empirically, the way to do really big things seems to be to start with deceptively small things. Want to dominate microcomputer software? Start by writing a Basic interpreter for a machine with a few thousand users. Want to make the universal web site? Start by building a site for Harvard undergrads to stalk one another.    
+>  
+> Empirically, it's not just for other people that you need to start small. You need to for your own sake. Neither Bill Gates nor Mark Zuckerberg knew at first how big their companies were going to get. All they knew was that they were onto something. Maybe it's a bad idea to have really big ambitions initially, because the bigger your ambition, the longer it's going to take, and the further you project into the future, the more likely you'll get it wrong.
+>  
+> I think the way to use these big ideas is not to try to identify a precise point in the future and then ask yourself how to get from here to there, like the popular image of a visionary. You'll be better off if you operate like Columbus and just head in a general westerly direction. Don't try to construct the future like a building, because your current blueprint is almost certainly mistaken. Start with something you know works, and when you expand, expand westward.  
+>  
+>  The popular image of the visionary is someone with a clear view of the future, but empirically it may be better to have a blurry one.
+
+4. What are related projects...?
+
+* STEPS
+* Webstrates
+* What you wish is what you get
+
+**JE:** Hypercard, Excel, What is it about these things that work point towards your vision that you can compare and contrast with?
+
+### Turbine
+
+Exactly what I'm looking for. Doing 7GUIs + todoMVC and already created [15 issues on Github](https://github.com/stevekrouse/futureofcoding.org/issues/96). I'm really impressed with it and Simon.
+
+**JE:** Question: what's the minimal / essential thing here to make progress?
+**JE:** Most of these things are longer-term issues. You can't do them all at once
+**JE:** Immutable editing problem isn't the first step
+**JE:** Self hosting is easy to push off as well
+**JE:** Same with detachable GUIs
+**JE:** The key thing is making FRP semantics very tangible, pokable
+**SK:** NEXT STEP: pencil and paper flow for 7GUIs
+**SK:** I think I can make progress here because I can be more incremental on 7GUIs from Turbine
+**JE:** Build a compile to Turbine IDE
+**SK:** Just like p1 and p2!
+**SK:** Can't use blockly because then I can't show the data
+
+### p4
+
+#### Fluidity not initial focus
+
+Initial focus is liveness (or something like it), not fluidity (because text input has unfair advantage and it can be added later)
+
+**JE:** Text is too low level. We need to capture more intention from the programmer. Schema change can be enabled live with projectional editing
+**SK:** It's ok to be mouse-based thing for starters. Might be the hardest interface problem ever encountered
+**JE:** We can drastically simplify with a few primitives, such as dragging things from here to there can be super powerful
+**SK:** Some sort of collaborative format or project like Haskell was for lazy could be neat
+**SK:** Just like p1 and p2!
+**SK:** We can agree it's a really big problem. This prototype won't deal with it. Please disregard that fact while looking at this prototype
+
+#### Motivating problems
+
+Maybe start with pure FP problems, like Pane does?
+
+**JE:** No, this is a trap. It's too simple. Doesn't have the hard problems. Must force face into hard problems: IO, circular streams, HoS, recursion, fixpoints
+**JE:** "I just want to ban stateless on LIVE demos" --> too simple. we already have excel
+
+Is todoMVC or the email client thing the end goal?
+
+**JE:** 7GUIs and TodoMVC
+**JE:** Maybe email client could be possible with Turbine's IO thing... as reach goal 
+**SK:** I guess we can do it hacky, but I want multi-node FRP to do it right
+**JE:** Multi-node FRP needs to contend with speed of light and message ordering
+
+#### Immutable editing
+
+* content hash like Unison and IPFS
+* do we hash definitions or expressions?
+* do we do work to cannonicalize hashes? (such as commutativity of addition)
+* no delete
+* no edit, only create new thing
+* refacorting
+
+#### Detachable GUI Literals
+
+1. Everywhere you have a GUI, you need to be able to put an expression: detachable GUI literals!
+2. GUI for every system f language primitive
+3. Bootstrap visual editor?!
+4. Are all apps just expressions visualized?
+5. Expression-based operating system instead of file-based or app-based
+
+#### Random ideas
+
+* A la carte language semantics, like haskell langauge extensions
+* Always running, like spreadsheet or google doc, no run or pause, only open or close
+* infinite canvas (can I still use Turbine...? **JE:** Stick to the DOM for this prototype if we can)
+* exploring which concepts we can move from the language compiler to the editor (no free variables, type inference is just local if not just a type “suggestion”)
+
+
+## JE work
+
+* [young mentor](https://twitter.com/jonathoda/status/1072680251497570304)...?
+
+### Subtext
+
+* https://github.com/JonathanMEdwards/subtext/blob/master/doc/Subtext%20by%20example.md
+* https://github.com/JonathanMEdwards/subtext/pull/1/files
+
+### Bourbaki Group
+
+https://docs.google.com/document/d/12HqvjQeC_bm4EX_a9Uk7kqSsob1wakb75PMQ1Cs46pk/edit
+
+#### Steve notes
+
+* How does this relate to LIVE workshops? How do the LIVE workshops leave us wanting more...? This relates to the secondary goal and the Plan B. (I feel quite satisfied by LIVE and maybe would just want it more often, maybe over a livestream...)
+* What problem does this solve for whom?
+
+### Minimum Wrong Product
+
+https://docs.google.com/document/d/1fNlZq-cz7zrye0TQ05gdJ8jfbFrJPGFC5lHTSAZp-XY/edit
+
+#### Steve notes
+
+* What problem does MWP solve for whom? Does it solve the creator of the MWP's problem of X? Or does it solve the reviewer of MWP's problem of Y?
+  * As a potential creator of MWPs, criticism and feedback is important to me. I feel like I am able to get that with a combination of messaging friends directly for it, the Slack group and Twitter, and putting it up on my website for posterity. It's important to know what [kind of feedback](https://twitter.com/stevekrouse/status/1069305083421224966) you want too 
+  * As a potential consumer of MWP's, I find video to be super useful to get the *feel* of prototypes. Beautiful, dynamic essays are great too. One way to think on this is to make a list of existing "things" that you learned from. Some that come to mind for me are: Seymour, Learnable Programming, Pane, Flowsheets
+* In other words, maybe start concrete by articulating the goals for your current subtext work and optimize that, and then abstract
+
+## Other things
+
+* work retreat...?
+* schedule next meeting
+* zoom next time!
+
+{% include analytics.html %}