Gallery of Programmer Interfaces

> 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 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.

So I wrote a projectional/structure editor[1] that does this sort of nested tiles representation. The reason for it wasn't to teach syntax though, it was to provide users with bigger, easier to interact with UI elements (reasons below).

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.)

[1] http://symbolflux.com/projects/tiledtext

[2] https://www.lamdu.org/

[3] https://github.com/disconcision/fructure

I think a more likely reason is keyboards. The main input device we use to interact with computers is a typewriter descendant, optimized for typing text. Mice are flexible but keyboards allow for more complex input.

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.

I think one reason is self-selection bias: Because all programming languages are text, everyone who is a programmer is necessarily adept, comfortable, and intimately familiar with representing programs as text.

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".

Maybe the solution is that we need to get away from general purpose languages for most software. There could be very powerful visual languages that one could develop given a specific domain. I work in pharma and I see a ton of scope for this, especially for the automation of daily work. Scientists might not be the best with C but they could be amazing given a DSL in a domain that they completely grok. I've begun working more and more with Siemens' S7 GRAPH language for sequential process control and its bloody amazing how it lets me visually represent complicated state transitions, loops and conditional logic in a very easy to understand intuitive way. It also lets you establish pre/post invariants, etc. I used to scoff at PLCs thinking I could trivially write than in C, but even ladder logic has humbled me more than a few times.

I actually have an old Genera manual, and added some figures from it: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bE...

The Mathematica screenshot can't be from 1988, it seems to be running on ubuntu 10 or newer judging from the title bar buttons look and position.

Edit: This is from 88 https://twitter.com/WolframResearch/status/10099016596554915...

I also don't think that LabView screenshot is from 1986. Looks like version 7-ish or 8-ish to me (mid to late 2000s).

I think they just picked random screenshots. For example they show Visual Basic with a Windows 95 interface but it predates it by several years.

Yeah, the dates are an approximation of when it was developed, but many screenshots come from much later, especially for pre-web tools.