Lambda the Ultimate

This seems like a good paper but will take quite a bit longer to get through. But I want to point out how much more challenging doing science on design seems than just doing science on science. They pull out a lot of cognitive psych theories, which is definitely appreciated, but you get the sinking feeling that there is no actionable advice to be gained in the end.

The Physics of Notations does not consider encoding-side issues as it focuses only on the effectiveness of the resulting representation. Further research could expand the theory to include such considerations.

Bummer. One of my major motivations for using visual languages is that it should make diagrams easier to draw and maintain. Most notations don't enforce spatial constraints, for example, or provide guidelines for how to layout information. These are crucial for a successful notation.

For example, Microsoft Visio and Visual Studio have never supported automatically maintaining connector relationships for anything but the simplest arrow. This automatically dissuades people from experimenting and thinking about their relationships. Further, there is a little known "crow's foot rule" (Barker technique) when laying out entity relationship diagrams that greatly enhances user understanding. Even weirder, although the Barker technique was created by a guy at Oracle, the Oracle Designer software does not include affordances for using the technique. Compare Figure 3.24 and Figure 3.25 in the article I link about crow's foot rule.

Given the lack of automated support for the Barker technique, it is little wonder why I never bother to draw entity relationship diagrams. Its too much of a pain in the tuckus. I have actually never seen visual software that actually helps doing the Barker technique, and one day hope to set up some leisure time to think about the computational limitations of doing so, and code up a demo.

By the way, I have created a visual programming language in the past for querying data and helping to understand data better. My major motivation was how annoying it is to transform something like a LINQ query or (back then) SQL statement to use a GROUP BY or ORDER BY clause, or how annoying it was to have to manipulate characters on a screen to do what a simple checkbox could do: "group this field". My major limitation was I never figured out a satisfactory way to:

a) do left outer joins visually, distinguished from inner join. [I assume there is no need for right outer joins, as they are simply a noisy option if you have left outer joins).

b) help the "average Joe" figure out how to express sub-queries. I was able to do this for existential quantification rather effectively, but I could never figure out a way where users could say "where the price in our Charge Master was equal to what we got paid on these invoices I am querying".