I highly enjoyed the recent discussion of Visual Programming Languages. Here are some of my favourite quotes, that seemed to capture something particularly meaningful to me. (Sorry about all the notifications <= credit where due. Broken into a few messages due to message length limits.)

@Edward de Jong / Beads Project very few languages today include FSM syntax, even though it is one of the key fundamental components of every program. Also, in every real-world FSM you have the possibility that one of the steps will fail. Having a system fail softly on a key step failing is a very interesting aspect neglected in most languages.

Warm take: Any new [visual?] language worth its salt should include a simple, generic FSM facility as part of the standard library.

@Stefan [...] an abstract graph, with generic arrows, their positions and lengths without meaning, pointing from and to equally as dimensionless boxes, all floating in a space that has no meaningful coordinates either — you can move things around and it doesn’t change anything other than the visualization.

It feels like there's another shoe yet to drop, when it comes to the design of VPLs — even the boring, traditional "node-and-arrow" ones. Giving the graphical characteristics of a visual language heightened meaning, representation, and dynamism is easily imaginable, and under-explored (evidence to the contrary heartily welcomed — I'll add it to the codex). So why don't we have it yet? One theory: used to be a painfully high bar for creating dynamic visual environments, but the explosive advancement of video game authoring tools is really lowering that bar. I mean.. have y'all played SpaceChem? Despite its intentionally constrained GUI (it is a game, after all), it's richer with metaphor than any VPL I've yet laid my mouse on.

@Tudor Girba it’s also important to distinguish between the way we write and the way we understand code. Whenever we talk about programming languages, we tend to conflate the two. The code is always consumed in the same shape it’s written in. I believe that is unnecessarily limiting.

This is probably my favourite reason to be optimistic about visual languages. With a text language, programmers would not tolerate the structure of their program being changed willy-nilly by their IDE. You expect the code to execute in the order it's written, within the scope it's declared, conveyed by the file you've allotted to it. With a visual language, programmers could be more permissive of wild alterations of structure and substance of the code in flagrante, including things like: which connections actually exist, how visual code-elements are laid out, how many & which names are assigned to a given thing, whether data may only flow along programmer-established paths, what data is present in the system, whether the execution model should be deterministic or not, and so forth. Why more permissive? Both for the cultural reason that this is uncharted territory free of the spectre of entrenched norms, and for the technical reason that visual communication allows a plurality of representations of the same fundamental thing, all of which can be treated as variably "real" or "virtual". The artifact of writing does not allow this flexibility — at most, it has typography; there's no "impressionistic" lettering versus "abstract" lettering, outside of concrete poetry. Again, the space of powerful system-building interfaces with shifting representations of the system has been best explored by video games (as a whole — not any specific game). But it's also been very well explored by 3D modelling/animation tools, which must show many, many different-but-mostly-equivalent representations of their data, all of which with subtly different degrees to which a detail is "real" or "virtual". All existing visual language GUIs (*That I've seen — counterexamples welcome) seem starved by comparison.

Warm take: Any new [visual?] language worth its salt should include a simple, generic FSM facility as part of the standard library.

erlang has two 😛 http://erlang.org/doc/man/gen_fsm.html and http://erlang.org/doc/man/gen_statem.html