We need visual programming. No, not like that.

Let's observe what developers do, not what they say.

Developers do spend the time to visualize aspects of their code but rarely the logic itself. They visualize other aspects of their software that are important, implicit, and hard to understand. Here are some visualizations that I encounter often in serious contexts of use:

• Various ways to visualize the codebase overall.

• Diagrams that show how computers are connected in a network

• Diagrams that show how data is laid out in memory

• Transition diagrams for state machines.

• Swimlane diagrams for request / response protocols.

This is the visual programming developers are asking for.

Fixed :)

Now I'm wondering what a programming language looks like that makes it easy to create such visualizations and keep them updated over time. My biases make me go first to Lisp, but in practice it's actually no easier to parse Lisp on a semantic level (e.g. detecting new variable scopes) than any other language. Maybe Glamorous Toolkit? @Konrad Hinsen @Tudor Girba

The visualizations you are talking about are first and foremost for reading, not for writing, which is indeed the most costly and painful problem in software engineering today. As such, this is not a programming language issue, but an environment issue. Moldable Development is a systematic method for doing exactly that. It turns out that reading needs are orthogonal with writing needs. Glamorous Toolkit is the most advanced and extensive environment that shows how far doing this systematically can get you. I do expect people will copy GT, and they very much should. My only worry is that they will not copy everything.

Thanks! Does GT currently support visualizations like call graphs (I'm sure), automatically extracting from code visualizations like state machines, heat maps, time sequence diagrams? Any programming language..

The idea is to not restrict the specific visualizations, but rather to enable one to construct custom visualizations of arbitrary input data. It is many times more valuable and cheaper to build custom visualizations than generic ones. There patterns language and the components are reusable, but the specific visual representations are less interesting for reuse. The question about programming languages is interesting. We can think of it as “are there parsers and semantic importers for language X”. But we can also think of it as “how do we build a parser and an importer for language X”. The former will lead to a library of parsers (like that built around ANTLr). The latter will lead to a dedicated environment for building parsers and importers faster. In GT we show that it is possible to have both, but really the interesting one is how to adjust to a language that you might not know.

That's indeed the main lesson learned (for me) from a few years in "moldable development" land. Support for situated development tools is much more valuable than generic development tools. The tools are better adapted to the specific task, and perhaps even more importantly, the user understands the situated tool perfectly well. I suspect that all this remains true if you cross out "development" - it should apply to any software tool. My near-term goal is "moldable data science".

Was doing my every-few-weeks scroll back and saw this, thought it looked interesting, and read it – thank you for linking; this is very good! (Don’t have more to say than that right now, but wanted to flag it up!)