futureofcoding
diff --git a/‎_data/git-log.json
+1-1 b/‎_data/git-log.json
+1-1
diff --git a/‎notes/jonathan-edwards/12-12-18.md
+151 b/‎notes/jonathan-edwards/12-12-18.md
+151
@@ -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 %}