Review: John Palmer on Spatial Software
What happens when virtual spaces mirror the mechanics of the real world, and how better connecting them may be the start of the next innovation boom.
John Palmer’s framework for talking about how apps and programs can improve by more closely mirroring the mechanics of physical spaces inspired me to think differently about how we build our digital world. As a civil engineer, I spend much of my day thinking about how we build and interact with our physical world, so it was refreshing to think about how we do the same in the virtual realm, especially because of how different and often loose the constraints to virtual worlds are.
In reading Palmer’s piece, the abstract vocabulary is at first less than welcoming to the reader, but if you go back and review the preceding piece; Spatial Interfaces, the post opens up and becomes much more straightforward. After dissolving the semantic tripping stones of the piece, the basic thesis of Spatial Software is that most of our virtual worlds today are arbitrarily organized in a vertical stack, and usually ordered by timestamp. Twitter is a good example of this. What Palmer proposes, is that we could gain new insights and methods of informational navigation by representing our largely vertical worlds differently.
While Palmer's examples of social media platforms and notes apps being possible places where spatial organization may be widely used in the future are interesting and have large implications for the wider world, I think he may have missed one important way that spatial interfaces could change our world forever.
One of the biggest inputs to the rate of change of our online world is the amount of brainpower that works to improve it every day. Giving the expert coders we have new tools is great, but bringing new people into the fold of software engineering is better. This prompted me to ask: “what if we could code in a way that was spatially familiar?”. The more that rookie coders can rely on intuition and spatial familiarity, the lower the field’s attrition rate will be, and the more innovation we’ll end up with.
So what would these systems look like, how can we make coding more approachable to potential software engineers by employing the idea of spatial intuition? One example of this is Minecraft’s infamous Redstone system. By manipulating the arrangement of virtual blocks within the game world, players can build simple logic machines to full on computers capable of emulating other video games.
Another example which may be more broadly known among coders is Scratch. By representing pieces of code as jigsaw-puzzle like pieces, and allowing the user to interactively use their intuition to put them together, Scratch exemplifies just how easy spatial coding interfaces could make software development in the future.
By creating more and better spatially intuitive coding interfaces, we may be able to circumvent some of the barrier to entry to software engineering, and jumpstart one of the largest explosions in human innovation yet. The prospects are boundless, and the cost minimal. Needless to say, I am very excited to see what comes next.
-Connor, Of All Trades
If you enjoyed this, please subscribe!
If you know someone else who would, please share!
To learn more about spatial software and interfaces, take a look at palmer’s site here
An old friend of mine who teaches software engineering has been thinking about this representation-of-code problem off and on for 20+ years. I'd be glad to make an intro if you're interested in pursuing this line of development further.
I'm all for this kind of exploration and experimentation but I'm _deeply_ skeptical that 'this time it'll be different'. This isn't a new idea by any means and a multitude of companies have existed, and still exist, that try to do this, or something very similar, and it sure _seems_ like there could be a good bit of money in it too. But nothing seems to have bridged the gap between toy problems and 'real' (e.g. useful) systems.
I think the first problem that potential programmers bump into, and struggle with for arbitrarily long durations, is being able to 'think' at the level of the 'computer' (i.e. the 'programming primitives' that are provided in any programming environment). Interestingly, and maybe tellingly, professional programmers often avoid this problem/constraint by working with 'higher level' abstractions, e.g. using an existing library that provides some kind of feature or abstract capability like adding numbers (represented – at some level – as something like a sequence or array of bits). But that really only pushes this problem 'up' into another level because, at some point, whatever it is you're trying to do has to be 'encoded' into whatever features or capabilities one has (and can think of or remember). There's a related phenomena whereby some initially very 'targeted' 'programming environment' adds more and more features/capabilities, and becomes more and more 'general-purpose', and ultimately becomes yet another 'regular' programming language.
The second problem is one more specific to these 'spatial' programming environments: programs _generally_ aren't of an 'integral' dimensionality (i.e. 1D, 2D, or 3D), even '3D programming' is _very_ difficult to understand visually (let alone 'higher dimensional' programming), often '2D programming' can be _extremely_ difficult to understand visually because it's often effectively 'parallel programming' (and that's hard for even the best professional programmers today), and, lastly, 'real' programs are almost always 'spatially' HUGE (i.e. too big to understand visually at a glance). I think the enduring use, and success, of 'linguistic programming' (i.e. almost exclusively in the form of code as 'text') is because it _is_ 'spatial' (basically '2D') but it also piggy-backs on our existing natural faculties that (can) handle recursion and 'chunking'/'categorization'. Things like Scratch only _seem_ easier, and more obviously 'spatial', because one can use them via 'drag and drop' instead of exclusively via typing. But, at some point, they're just (much) _slower_ means of ultimately 'writing' the same kind of code, and also ones without a lot of the interesting and useful 'tricks' that 'code as text' makes possible.
These 'spatial' programming environments also don't seem to help new or potential programmers with a lot of the other related skills that are necessary to create 'real' (e.g. useful) programs or programmed systems. _Writing_ code is just the first (or one) step! Testing code is just as important, and beyond a very shallow 'first pass', extremely difficult to do ad-hoc, let alone at the level that a 'spatial' environment readily allows. And beyond that, _maintaining_ code is almost something else entirely, and one that affects how one writes (and tests) code too. One big problem with 'spatial code' is that it can be very hard to 'refactor' it, e.g. to be more readily tested, maintained, or later extended.
An interesting parallel to a lot of this can be found in various 'factory management' games, e.g. Factorio. The game world is a very obviously spatial interface and the various items a player can 'build' are the 'program primitives'. And, inevitably, the same 'programming problems' occur (and recur): how to test one's code, how to debug it (especially when it's already 'running'), how to get two 'pieces' working 'in parallel' (but coordinated together), and (eventually) how to 'refactor' existing components of some system to adapt to some change in the environment.