Visual programming and mushiness

This morning I'm rereading bits of my long Hacker News visual programming post and trying to remember why I spent so much time on this and what I was aiming towards. I kind of got spooked by the number of views it got (even if it was mostly empty Hacker News calories) and dropped the thread on why I actually cared. Or maybe I'd mostly lost interest anyway, like with the bat and ball? Don't fully remember.

My original inspiration for the project was close to the Dutilh Novaes stuff I've been posting about here recently:

Dutilh Novaes focuses on formal logic, but I’m curious about formal and technical languages more generally: how do we use the properties of text in other fields of mathematics, or in programming? What is text good at, and what is it bad at? Comment threads on visual programming turn out to be a surprisingly good place to explore this question. If something’s easy in text but difficult in a specific visual programming tool, you can guarantee that someone will turn up to complain about it. Some of these complaints are fairly superficial, but some get into some fairly deep properties of text: linearity, information density, an alphabet of discrete symbols. And conversely, enthusiasm for a particular visual feature can be a good indicator of what text is poor at.

This is a pretty convoluted background setup, and unsurprisingly most of the responses were more on the object level of talking about visual programming itself. I still think there's something interesting there, though. I think my original idea was to have a second blog post going into the connection with writing more, and maybe I'll still do that some time if I regain enough interest.

I'm mostly interested in the properties text has that makes it rigid and repeatable:

• a fixed set of symbols that can be easily distinguished from each other
• a set way of organising these symbols: in lines and paragraphs in the case of normal writing, more complex and rule-bound formatting in the case of code and maths. Brackets, indentation, etc etc
• a 'grammar' of how these symbols can be combined. Normal writing takes regularities from speech (consistent sounds used to refer to the same things, recurring patterns of word use) and formalises these further, adding e.g. punctuation rules. Formal languages add way more of this stuff., e.g. keywords and very rigid rules of combination.

A lot of complaints about visual tools were about some kind of mushiness compared to normal text. The famous 'LabVIEW spaghetti' is an obvious example - there's no set formatting rule, so the lines end up all over the place. Another common complaint is lots of mouse use: the mouse is sort of the default interface tool for continuous mushy things, rather than discretised precise things which can be mapped to individual keyboard shortcuts, so this fits the same pattern. Also complaints about version control and diffing, which don't play well with mushiness.

This also connects back to my Kill Math note a while back. Miller is also complaining about mushiness in Victor's simulation tool:

What is the actual quantitative content of this discovery? If some relationship appears to hold — is this relationship approximate or exact? Numbers might go “up together” or “down together”, but is the underlying relationship linear, exponential, periodic, or what? If no relationship appears to hold — is that because I can’t see it, or because it’s not there?

Hm there's a lot more I could say about mushiness, including its good points, but I'll end it there for now. This worked well though, I'm also remembering why I'm interested in Derrida. I want to understand his story on repeatability better.