🧵 on the first 25 minutes of https://futureofcoding.org/episodes/057 Summary: • It would be cool to create a visualizer for low level software. Assembly language in particular would benefit from visualization to catch errors in register allocation, manual memory management. • A retro game console may be a simple test bed for trying out various FoC ideas. You could literally save snapshots of all 64KB of RAM for some machines every single frame, and then perform further analysis on them, diffs and so on. • A similar idea: GPU Maker 2000 like RPG Maker 2000 but for GPU programming. • The Gameboy has a particularly ideal form factor for a convivial tool for thought. In particular, it has a camera, something I wasn't aware of. Does anyone have a good sense of the space of Assemblers out there? Surely there exist debuggers for Assembly? Maybe reverse engineering is a space to look at? Are there any debuggers or reverse-engineering tools with command languages? Ghidra does seem to have something: https://resolute-tech.com/an-introduction-to-ghidra-scripting. Does anyone here have experience with it?

I am converging on the idea that the FoC is not replacement of text with no-code, but augmentation of text with dataviz, i.e. dataviz assisted development. This seems to be what you want here (I can't help with the specifics of assembly). Yo do not need the same set of dataviz for all problems, so I think complexity is not an issue, as you only pick the tools that make sense.

Re the idea that retro consoles might be a good testbed, since we can handle the whole systems with our current tools: Alan Kay would argue that we ought to do this with our current platforms, with the aid of supercomputers, and that we're limiting the scope of our ideas by not doing it. I agree with him, since on a retro console you won't typically need to deal with concurrency, and certainly not with parallelism.

I actually remember RPG Maker 2000 there was a forum around the 2000’s where I spend a lot of time back then where it had a sub forum.

Re: retro consoles. Yes, I would love to make a Gameboy emulator that included all the visualisations from this talk (particularly the pixel data related ones from ~29mins on)

For many years now, I've wanted to make an easy to use card game builder. Would be less time sensitive than a console. Complexity comes in managing state well: phases of a turn, turns combining into rounds, phases, matches. Some combinatorial trickiness: sets and runs. And I'd feel good about the result if the system can automatically generate AI players of different skill level and disposition based off the rules. I mean given this set of rules, you could have an "aggressive" player who tries to do this and this.

do we really need a visualizer?

IMO, the question about “visualization” might be rhetorical - visualization of what? Debugging belongs to the realm of creativity, not of clockwork engineering. Debugging is iteration. Debugging is notation-specific. Debugging is paradigm-specific. For example, if you Design a system using, say, the OO paradigm, you want a debugger that shows you the OO-iness of your code, not, say, machine-level single-stepping from a completely different paradigm. @Kartik Agaram’s Handmade-network video reminds me of a long-standing je ne sais quoi I’ve had about GVL . Kind of a projectional editing REPL (based on simplistic-SVG?).

You can debug asm programs with

gdb

, which has various affordances for tinkering with what's happening in the running program. I've written a couple of interactive interpreter/emulator systems for small architectures to make it easier to live code embedded systems. (When I taught Operating Systems at uni, I'd always have the students deal with the pain of working directly with the slow hardware before introducing cross-compilation, then emulation, on faster hardware to help them develop an intuition for when to make those decisions in real life.)