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