Recently I came across an astounding business concept which borrowed from visual IDEs to extend editing good to other fields.
Aside from clapping my hands in joy, this brought to mind scatter-dot experiments I conducted throughout my career as a programmer. Experiments which question how programmers write, read, think about and interact with code.
Baby Step - The Synapse Editor (2001)
Synapse was an all-in-one code editor, note taking and mind-map tool. On the coding side, its simple advantage was making it really easy to put two files side by side. The mind map was something, as it featured infinite zooming, which provided a way to move granular content in and out of context.
Antegram 1.0 (2002)
I found UML useful to design software, but wanted something more direct. So I created my first visual editor for Java and C++. To this day I am forever amused at how "Visual IDE" could mean one thing, or another entirely.
In Antegram, declaring new classes and functions was through clicking on the canvas, then typing a declaration; drawing connectors would bind members to types, and types to packages.
Manually laid out nodes cause programs to have shape, making their structure somewhat memorable.
In Antegram, I'd only see the currently expanded functions. This approach really helped me with larger programs, and thinking of the signature (not the source) as what should define a function.
Antegram 2.3 (2003)
Eventually I wished for more concision in code graphs - what I was after was envisioning libraries with maybe 1000~2000 program files, and navigating them super fast.
I then opted for non overlapping windows, which would conveniently re-layout when double clicking anything.
Other features included:
- Vector icons condensing member modifiers into a visual presentation, but also displaying the relative sizes of packages (give an idea of how much code lives where).
- A playful color scheme, consistently associating with various packages.
Not so surprisingly, the "signatures first, code second" concept was maintained.
I used Antegram professionally, notably to build a complete POS (point of sale) system with custom networking.
I continued using Antegram until perhaps 2007 when I joined my first dev team. At that time I not only needed to collaborate - I also switched from Java and C++ to another language. I didn't really mind using Eclipse but I also shared my work with colleagues, one of whom commented that visual representation had taught me software architecture.
Then, there was a long gap in my experiments. I worked in HaXe, Objective-C++, Python and other languages. Switching language often is interesting but does not help maintaining coding tools.
Howl (2020)
Around 2020 I had adopted Atom as my choice editor. It did lack detailed outliners, but made it easy (and faster than VS) to put files side by side. I also used much larger screen and I think it's useful to note that Antegram was a delight to use at 1024 x 600 on a netbook.
I don't find scrolling (or hopping around through searches) productive. Half of my answer to that is LRR (less responsibility principle) - in other words, when a program goes beyond 30-40 lines, I start questioning whether the associate type is doing too much. The other half is ruthlessly concise formatting, and the nail (in the coffin of conventional formatting and code visualization) was the Howl notation.
Howl lets a user type code, and get... Unicode wiggles? I think of the Howl notation as unreading (quickly, more visually parsing) what doesn't matter. User defined keywords (type, functions, variable names) are often left unchanged. Modifiers and other keywords are condensed into single characters.
Being just a notation, bidirectional conversions are a thing. Howl is compatible with (now defunct) Atom and VS Code. In Atom, a Treesitter grammar availed syntax coloring.
Conclusion
Throughout the years, I kept an eye on VHCI and its connection to how we think about program code.
Most approaches to visual editing are code first, which perhaps should be a surprise, as it does not help structuring libraries, and requires separate documentation.
How about formatting? When working with a team, if we agree on a format I think using a linter is the best (not always practical!). But when I write my own code, I tend to mentally project onto an 80x40 (or 50x40) grid
Care to share your coding and VHCI journey? If so, welcome to comment!
Top comments (0)