It's understandable for teaching the concepts of syntax to people learning programming for the first time, but I don't think it tackles any of the essential complexity, or what makes programming hard.
It keeps getting reinvented in different guises, often with an air of democratizing coding, taking it out of the hands of the high priests (IT) and into the hands of the people. But what's hard about programming isn't if-statements, loops and assignments. It's incorrect assumptions and broken invariants, usually in runtime data, generated by code which is often distant.
Relatively few interfaces seem to deal with manipulating data rather than code. I think working with data is more likely to be useful and successful. Look at things like Visual Basic - a form designer is effectively manipulating a stored data structure which defines how a runtime data structure is going to get constructed.
I wanted the basic elements of the interface to be at a higher level than individual characters. The nested squares style rendering is highlighting grammatical structures in the language—not to teach syntax, but just to indicate where an interactable UI element is, the same way you have rectangular bounds around a button etc.
My motivation for this was to make it easier to manipulate code with lower-precision input devices (e.g. the microsoft kinect / leap motion), but I think there is general interest because a lot of the people writing these editors start from the premise that interacting with the AST directly (as opposed to character sequence) opens up doors, and nested squares is just kinda the most natural/obvious way of rendering an AST. It's also a more natural pairing with the input style of many of these interfaces (e.g. Lamdu[2] or Fructure[3]) which also operate at a higher level than character sequences.
The alternate rendering in itself isn't world-changing, it's the underlying change to directly manipulating a model that then gets rendered (as opposed to parsing the interface—i.e. character sequences—in order to arrive at the model) that's important.
(And even it probably isn't the most important revision to programming tools in general—but that doesn't make it not worth working on if someone's interest is in that direction.)
I think data manipulation interfaces are a good line of reasoning to investigate, but form designers aren't that, they're just for controlling visual placement of controls. The real MVP of dataflow manipulation programming for non-programmers is Excel.
VB and Delphi have components, non-visual controls that live on design surfaces, where their properties can be edited. Things like database connections and table connectors, which can further be linked up with data aware controls. Whole simple form-based CRUD applications can be built without any code at all, merely by wiring together components.
The wiring is data.
For me, writing code is about the easiest thing I do. Other than identifier completion, I don't need much beyond a basic text editor.
On the other hand, understanding code -- not just exploring it, but understanding it -- is the the hardest thing I have to do, and that's where a good UI could be helpful. I only made a superficial scan, but it didn't really seem like any of these UIs were designed to do that.
I don't really need a map to a code base so much as I need a tool for making my own maps (not just one!) into the codebase as I try to understand it. Or understand at least enough of it to do my current task.
Touch devices (like touchscreens or touchpads) could have helped with more direct manipulation of visual elements but they are always used on very limited (in terms of functionality and form factor) systems. On desktop computers they are far from ubiquitous and 99% of the time they just act as subpar mice.
The more I think about it, the more I think the people who tend to make criticisms about textual representations and then argue in favor of visual representations are not just wrong, but usually have things actively backwards; almost every criticism they make about text is actually a positive aspect of it. Not having a literal line appear from a call site to what it is calling, for instance, is a net positive, not a problem. I think this is why visual stuff has been bubbling slowly for decades and just never seems to get anywhere the way its advocates hope.
There is a whole other kind of programmer which doesn't exist yet— a visual coder— all of whom are doing something else right now, because there are no tools for them. It takes a large leap of imagination for a text-coder to empathize with these still non-existent visual-coders and make the tool that they need, and a large leap of imagination to envision a complete visual coding system from the ground up which can be used to solve actual problems and compete with the very mature text code tools that are already out there.
In short, "massive amounts of cultural inertia".
Copying erikj's comment from over there:
-----------------
I think Symbolics' Dynamic Windows and CLIM could be added to this gallery as well, as early examples of presentation-based user interfaces:
https://dspace.mit.edu/bitstream/handle/1721.1/41161/AI_WP_2....
ftp://publications.ai.mit.edu/ai-publications/2004/AIM-2004-005.pdf
Those look mostly identical today.
Edit: This is from 88 https://twitter.com/WolframResearch/status/10099016596554915...
[0] https://en.wikipedia.org/wiki/History_of_the_graphical_user_...
[1] https://en.wikipedia.org/wiki/Blit_(computer_terminal)#/medi...
These are some of the most popular programmer interfaces of all time...
Tinker 1981, showing a color Macintosh interface.
ProGraph 1983, also using an interface using colors.
Pecan 1984, the year the first Macintosh was released.
#/media/File:Teletype_DMD_5620.jpg){kind=link}