Future of Coding

JE Meeting 12/12/18

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

  1. 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.

  1. 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.

  1. What are related projects…?

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. 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

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

JE work

Subtext

Bourbaki Group

https://docs.google.com/document/d/12HqvjQeC_bm4EX_a9Uk7kqSsob1wakb75PMQ1Cs46pk/edit

Steve notes

Minimum Wrong Product

https://docs.google.com/document/d/1fNlZq-cz7zrye0TQ05gdJ8jfbFrJPGFC5lHTSAZp-XY/edit

Steve notes

Other things