4 ms·
I like the distinction between spatial and temporal aspects of programming languages. I'm wondering if the author knows Lisp though, which helps translating bet
by beders 7y ago
I like the distinction between spatial and temporal aspects of programming languages.
I'm wondering if the author knows Lisp though, which helps translating between those two views of code in important ways (like Homoiconicity).
Also, when trying to understand code, we typically run a simulation of that code in our head. Since we have limited capacity doing so, having a simple flow with simple data is helpful.
If we hit the limits of our internal code processing capabilities, we are switching to a different mode: Experimentation, supported by tools.
In non-interactive languages that typically is a 'unit' test or a sample app or a debugger.
In interactive languages it is the REPL.
A REPL allows you to experiment with the mental models we acquired from reading the code.
Confirming hypotheses by letting the machine run experiments, validating the outcome, deepening our understanding of the code.
This is where I see visualization being most useful. Show the data before our hypothesis, show the data after we've run the experiment (i.e. v'=f(v)). Not just the type of data.
That's where I'd like to see better tools. (One example of this I'm currently using is re-frame-10x, which shows data epoch oriented and has neat diffs of what changed when an event was processed (i.e. time has moved forward).
- jmiskovic 7y agoI find it baffling that Lisp is still written in text. It's pure AST, so it's easy visualize and manipulate it as a tree. Small trees (definitions of functions and data structures) are composed into big tree that forms application. Why not do all development work (reading/writing) on this tree directly? In my view the Lisp should be first candidate for visual programming. Agreed, re-frame and its tooling is awesome. BTW is there any way to drop into REPL from context of event handler?
- Retra 7y agoI don't understand your surprise. Text has many compatibility, readability, and uniformity advantages. How are you going to diff a tree? How are you going to make the display consistent across platforms & tools? How are you going to represent the details of the program? In the end, you're still just projecting abstract objects onto a 2d plane, and text already does that in a maximally flexible way. Anything else is less.
- darkpuma 7y agoIsn't the most popular Lisp editor, emacs, AST aware? I'm a filthy vim using pleb but I'm under the impression that emacs is aware of s-expression encoded ASTs and has all sorts of 'chords' for manipulating the AST.
- kazinator 7y agoA program's abstract syntax tree in memory is still a form of text; it's just chopped up (not a linear tape of symbols), and some of the representations are altered. For instance the number 5 becomes 101 or perhaps 10101 (01 type tag) or whatever. Bits are still text: reams of text made of two symbols. The so-called visual programming languages do not get away from text. They show various boxes or blocks on the screen, but the contents of those blocks are pieces of text. Every single screenshot of a visual programming language shown in this article is nothing but snippets of text inside boxes. If we take a Lisp expression like (a a a) and show it as three boxes, each labeled with a, that is not an accurate tree representation. The actual tree is a DAG, in which there are three pointers leading to a single symbol whose name is a. If we show three boxes, then we do not have anything close to a purely visual AST language. We have a language of textual tokens which require passing through a reader so that multiple occurrences of the text a get turned into the same object.