- informative (e.g. flowchart as ancillary description)
- informative and significant (e.g. executable flowchart)
- informative, significant and responsive (e.g. edit-triggered updates)
- infromative, significant, responsive, and live (e.g. stream-driven updates)
- tactically predictive (adds programming via selection from running predicted behaviors)
- strategically predictive (adds inference of gross functionality)
Natto recently gained multiplayer cursors, and it's fun to imagine collaboratively live-coding parts of your application, and then including them in the main codebase as an asset file (these canvases are just JSON files that could be easily included in a git
repo).
You can also imagine having a DEBUG
flag which swaps parts of your application to be live-Natto-modifiable.
git
branches visible and editable at the same timeThere is really no boundary between the code and the world, and this allows for some wonderful workflows. For example, there is no boundary between programming and debugging - if something is acting weird, you can simply pause time, open the logic, and probe widgets and wires to see what state they're in. Tweak the logic on the fly and resume again. It's blissfully iterative and doesn't require you to learn any additional tools, e.g. a time-travel debugger or a Whitebox.
— I did Advent of Code on a PlayStation
- again, this is not about "VPL" which is node-and-wire interface, but about a VPL which:
- shows its state to you - the values flowing through the system
- is "live" (as in Live-Coding) and allows you to prod at the values to see what happens
Everyone who has written interactive software has experienced the same interplay. The programmer writes some code, runs it, and sees how it behaves and feels. The results are partially expected, partially surprising, and they feed into the next cycle of design. The ability to shape and reshape software requires a capacity for rapid prototyping - for turning an unarticulated idea into a working prototype quickly enough to be able to change it, to listen to it, even to throw it out and to go on to another. In this activity, the nature of the programming language and environment can make a large difference - perhaps as large as the difference between modeling in clay and sculpting in stone.
— Bringing Design To Software - Terry Winograd
- interestingly Winograd points out here that some languages/environments are better at "changing" and "listening" to the prototypes - my bet would be that Live-Coding makes it easier to have tighter feedback loops, but there's probably more to unpack here!
I collaborated with José on a set of research prototypes that show a direction towards expanding Livebook with additional live-coding concepts: probing, tracing, and live test feedback.
In 2019 I got a chance to teach a couple of live-coding workshops using Liveboard. Environments with immediate feedback make a great teaching tools, and we also managed to spend some of the time actually playing around and making music.
October was all about exploring different creative-coding-related uses of Haskell: famous live-coding environment — Tidal, and (a bit less) famous graphics library — Diagrams.
Tidal is a live-coding environment for creating live music. It's mostly sample-based, using SuperDirt as a backend (which itself is SuperCollider addon).