Open stevekrouse opened 7 years ago
I like these axioms http://incidentalcomplexity.com/2014/10/16/retrospective/
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...
1) Accessible to create, view and update anywhere, on any device
mobile friendly
2) Pre-requisites built-in (microworld, no user manual, just-in-time learning)
first person coding, messages, events as metaphors
3) Workflow built-in (asana, workflowy, and github all rolled into one and built in)
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)
amazing error messages that prevent bugs
5) No Ceiling
package manager imports
6) Simple made easy
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.
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.
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