F-F-F-Flowsheets v2 🎉🎉🎉 demo

I think making software human-understandable (and by extension modifiable) is one of the biggest problems for software engineering. As it stands, both beginners and experts have difficulties understanding exactly what their own programs are doing as well as what programs written by other people are doing. We encode complex algorithms in static, abstract text descriptions that are hard for humans to understand and reason about. We have to imagine the behavior in our heads from these illegible descriptions. The behavior and internal workings of their programs are invisible. Not to mention that when trying to modify other's programs there is often a huge communication problem, trying to construct a mental model of what the program does is a tedious and often impossible endeavor because of missing context. Just think, how is it even possible to make "write-only code", code that was understood when written but is now completely unintelligible. To me, that should be impossible. Or think about how open source software is open in that its code is available, but closed in terms of being easily understood — there's the formidable cognitive challenge of understanding the program well enough to be able to modify it to one's ends. For most people, this is a significant and unreasonable effort. What to do about all this? To me, the answer is redesign programming so that it is primarily about communicating behavior to humans. A couple things I've made toward that end: * Legible Mathematics, an essay about the UI design of understandable arithmetic: link * FuzzySet: interactive documentation of a JS library, which has helped fix real bugs: link * Flowsheets V2: a prototype programming environment where you see real data as you program instead of imagining it in your head: ▶ this video * REPLugger: a live REPL + debugger designed for getting immediate feedback when working in large programs: link * Marilyn Maloney: an interactive explanation of a program designed so that even children could easily understand how it works: link In general, I think it's a neat research direction to redesign many concrete programs by hand in the most understandable way possible (using custom graphics, interactivity, game design mechanics — all the best things we have for helping someone understand things through media), and then use those experiments to work backward toward programming languages/environments. In the end, programming is essentially only limited by human understanding, so that's the most significant engineering program out there.

To make some of the ideas in this article a little more concrete, here are some research demos I’ve made: * Legible Mathematics, an essay about the UI design of understandable arithmetic: link * FuzzySet: interactive documentation of a JS library, which has helped fix real bugs: link * Flowsheets V2: a prototype programming environment where you see real data as you program instead of imagining it in your head: ▶ this video * REPLugger: a live REPL + debugger designed for getting immediate feedback when working in large programs: link * Marilyn Maloney: an interactive explanation of a program designed so that even children could easily understand how it works: link

As I see it, the number one hurdle in software productivity is human understanding. The more understandable software is and the easier it is to make software understandable, the faster and more accurately it can be modified. This is why functional models like React, DSL models like SQL, and constraint models are so widely used — they make what's happening in the software more understandable (at a worthwhile performance cost). A few of my own contributions: * Legible Mathematics: link * Flowsheets – showing data as you program: ▶ this video * REPLugger – showing data as you program in large systems: link * FuzzySet interactive code documentation: link

> While I know so many programmers are vehemently opposed to "visual programming" I wonder if we can make programming multimodal. "Visual programming" so far as been about visualizing program's static structure. Scratch and Labview do this, and this has some advantages, especially for beginners. But there's never been much advantage in understanding program behavior from seeing its structure, and I think tools for understanding program behavior are probably the most effective way of making all programming better. See my project Flowsheets for some experiments in this space: ▶ this video