'''Programming in a Multi-Dimensional Universe''' -- A Thought Experiment

As hinted at in SwitchStatementsSmell, often the reason our code becomes a BigBallOfMud is because we are dealing with multiple dimensions/factors/aspects[1] of change in mostly linear (textual) code. For example, if we group our code by sub-nouns, then we are forced to de-group it by sub-verbs, etc. and have to create named references to other factors instead of direct grouping. '''References are ugly''', but necessary so far. If we initially group by factor "A", but the change request is on the grain of factor "B", then we have to hop around the code and find references to "B". (We try to pick the most common factor of change, but usually it's just choosing among the least of multiple evils, and we often guess wrong because Murphy runs the future.)

TableOrientedProgramming (TOP) suggests that 2D tables allow one to "group by" two dimensions at a time: one dimension is the "row" axis and the other the "column" axis. Thus, one is not forced to choose one aspect as "primary" over the other: each axis is an equal partner[2] and we can visualize the groupings  relatively easily because we are all familiar with grids.

We can in theory extend this TOP idea into something like the following table schema:

 code_snippets (table)
 ---------------
 aspect_1
 aspect_2
 aspect_3
 aspect_4
 aspect_etc...   (dummy place-holder for as many dimensions as needed)
 code_text   // the target "code snippet" cell

Then the grouping of code is simply a matter of querying with the desired aspects and sorting and grouping. Performance aside, this gives us the ability to see just about any aspect we want without "physically" rearranging the source code. It's essentially a virtual '''hypercube''' with a query language that allows one to "sample" different parts of the cube at a time to get a custom view. No more stinking references!

But in practice, we haven't learned how to manage code (or its equivalent) well this way. Thorny issues like understanding and managing scope still gum up the works. Going beyond 2D has not proven very human-friendly at this point (and even 2D has not fully gained traction).

But take a hypothetical being from a multi-dimensional universe who is used to "visualizing" and working with multiple dimensions. They may have learned some tricks or techniques for working with a virtual hypercube of code. '''What might these tricks or techniques be?''' I truly doubt such a being would use linear code because they have wider options. (Or, is there something "special" about linear code that makes it ubiquitous?)

If we answer this question, we may be able to make better code management tools/languages.

As a rough analogy, one of the reasons we struggle understanding and relating to quantum physics is that it does not match our every-day experience in a "world" that better fits a Newtonian physics model. If a being came from the quantum world (a really little dude perhaps), that being may be better at thinking about quantum issues and wouldn't have rely on giant chalk-board's full of equations to work with quantum rules.

--top

''Okay. Write a language that is capable of calling a function, and only that function, at the same time, and in as many threads as will queue or check for it. All threads will execute their control flow in parallel thread ticks - modulo any branching. Said function may then safely use each other's ''thread(aThreadId).locals['yoIaVariable']''. No, I can't think of a reason why either.''

And BTW, this is "I wanna be born as a local Einstein" material: 

    A dark history of time
    www.youtube.com/watch?v=oy47OQxUBvw 

Buh-bye, BigBang!

----
Footnotes

[1] I'll use these interchangeably for now, for good or bad.

[2] Relational actually favors row-wise operations over column-wise operations. But perhaps we can consider one of the modern derivatives of APL.