Jason Frame: Livecoding in JS
What do we mean by livecoding? Injecting code into a program whilst it's still running and we should see no change in the program (other than what we intended). For example a music generation system.
Rather than planning out a big system we can start with what feels right and then manipulate them until we get to where we need to be. Start with primitives and get on with using them. And it's fun turning a car into a tortoise.
- Flexible - prototypal not class based.
- Ecosystem - browser + node.js = node-webkit
- Single threaded - don't have to worry about what something else is doing.
- Event loop - natural synchronisation point.
- Generalised tools can be complex - optimised for nobody
- May make performance trade offs - browsers can't always keep up
- Evolve tools with application - what can we keep and what can we lose?
eval() is awesome. Eval is the core tool for livecoding.
- private state - don't pollute the global name space.
- variable injection - provide objects to user code. Generate method signature from defined objects.
- "globals" preservation - preserve state variables between code reloads, don't want to reset the global state when we hot reload code.
eval()- provide external access to the closure with an
eval()that runs in the closure scope but is accessible from outside.
- snapshots - save and restore entire application state. user code is responsible for it's state here.
- Clocksources - provide a wrapper round the time function so we can control this for snapshots.
Escaping the walled garden
Plan 9 operating system - everything is a file, really. Fuse file system is the equivalent, it allows us to mount the program state as a file system and intercept the file system calls. We can now use standard Unix tools to manipulate the game state.