Design Goals

[stevekrouse]

First of all, I need to figure out how my thesis relates to the ideas I'm thinking about working on in ideas.md.

Places I can pull from...

• https://github.com/stevekrouse/cycle/blob/d6094179c97ec815198cf24cbab9248968a2f157/README.md#principles

• https://docs.google.com/document/d/1oSbI5z7BZVkHxf0gOabjz393HiLAys1WJeHnaVMg4dg/edit?usp=drive_web

• TODOs from futureofcoding.org/links

[stevekrouse]

I like these axioms http://incidentalcomplexity.com/2014/10/16/retrospective/

[stevekrouse]

First, my goal

Before I develop my thesis, which feels like a way of achieving the goal, I need a very clear goal. I starting working on this in /about but I think that's where I need to continue now before working on this...

Old priciples

Cycle v1 principles

1. Accessible to create, view and update anywhere, on any device

   • built on the web
   • mobile friendly

2. Pre-requisites built-in (microworld, no user manual, just-in-time learning)

   • types as shapes
   • first person coding, messages, events as metaphors

3. Workflow built-in (asana, workflowy, and github all rolled into one and built in)

   • helps you organize your project
   • nested feature to do list for top-down and bottom-up programming
   • includes branches and version control and collaboration
   • notifies you when you've been stuck on a feature for too long and should take a break or get help

4. Only logical bugs (helpful waiter that gives you tips and warns you against things, but ultimately brings what you ask for as long as it's not going to kill you)

   • blocks
   • strong types
   • amazing error messages that prevent bugs

5. No Ceiling

   • play nice with exsiting tech
   • firebase bindings
   • bootstrap bindings
   • package manager imports

6. Simple made easy

   • pass by value (no pass by ref)
   • scaffolding and autocoding for simple concepts that need boilerplate > behind the scenes magic

Original Future of Coding Thesis

Firstly, I believe syntax errors -- coding in plain text -- should be a thing of the past. We can solve this either through drag-and-drop coding like Scratch or projectional text editors like Prune.

Secondly, runtime errors can also be a thing of the past through a strong type system like Haskell’s or Elm’s.

There are a few really interesting projects that combine both of these ideas: namely Unison, Luna, and Lambdu.

Thirdly, I believe coding should be a cloud-based activity. The whole workflow from creating a new project to importing dependencies to collaboration to deployment should be as simple as using a normal consumer website like facebook or google docs.

Fourthly, I’ve fallen in love with the idea of visually representing types through shapes like how Scratch does. In Scratch Booleans are hexagons and conditionals have a hexagonal shaped holes, so students never have to even learn the word “boolean.” They just connect the shapes.

Finally, future of programming is more declarative than it is imperative. I think there’s a lot to learn from math and functional programming, including immutability and purity. However, I think we have some work to do to make many of these concepts, like Monads and higher order functions, more accessible to beginners, potentially through visual metaphors.

Jaime Brandon's Eve Design Principles

Grow with the user. The way to introduce a complex skill is to teach it gradually. Beginners should be presented with a simple interface. More complex features should be unlocked as they are needed. This allows simple tasks to be easily learned without imposing a ceiling on power.

Belong to the user. Advanced users should be able to understand and extend the environment itself. That means it must be open source, have a simple and well documented implementation and be designed for extending. We should encourage users to learn by reducing the number of steps it takes to go from having a question about a tool to opening the hood and poking around inside.

Be friendly and helpful. There should always be an obvious path from encountering a new problem to finding answers. Exploration and experimentation should be encouraged by teaching the user that every action is safe and can be undone. Error messages should be accompanied by a full explanation and suggestions for how to proceed.

Ergonomics matter. We should observe users and collect data to discover common actions and workflows. The environment should be optimised for the way that people use it, not the way that we think it should be used. Tools should communicate with each other instead of making the user perform the same actions manually e.g. consider the number of manual steps between seeing an error in production and reproducing it in a debugger - the ideal interaction is just clicking on the error in some dashboard and being dropped into a debugger with the same runtime state.

Computing is the means, not the end. Most end-users are not here to program for the sake of programming; they are trying to solve some problem in the real world. Every tool and feature must demonstrably and immediately save the user time and effort or they will ignore it. A simple tool that solves 80% of the users problems is often preferable to a complex tool that tries to do everything and requires a manual the size of a house.

Empiricism over ideology. If something doesn’t work in practice, it doesn’t work at all. We shouldn’t make assumptions about what users will understand or how they ‘naturally’ think. We should be aware of our history - of what has and hasn’t worked in the past and the reasons why. The real world exists, it is a mess and it won’t go away if we close our eyes and ignore it.