Dimensionality of program code (was: Exceptional coding style)

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Jan 17 15:33:47 PST 2013


On Thu, Jan 17, 2013 at 11:43:33PM +0100, Rob T wrote:
> On Thursday, 17 January 2013 at 20:17:06 UTC, Stewart Gordon wrote:
> >OTOH, because we tend to view code in a two-dimensional form, and
> >even rely on line breaks and block indentation to make code
> >readable, I can understand people thinking of code as 2D.
> >
> >And there are languages in which the code structure is inherently
> >two-dimensional, e.g. Befunge.
> >
> >Stewart.
> 
> So far we have not considered what happens when we get into parallel
> programming. It seems that the old ways of viewing code breaks down.
> We have to represent in text form not just one thing happening at
> one time, but many things happening at the same time, so the
> dimensions increase and the interactions between simultaneous
> cooperating components often becomes unpredictable in ways that
> cannot be represented very well in text form. You can still
> represent the code in text form, but I wonder how effective that is
> compared with a graphical approach to the problem, i.e., simulating
> the programming model graphically in 2 or 3D space.
[...]

It's easy to represent in 2D or 3D a *simulation* of program execution
(i.e., a particular instance of execution), but how do you represent
concurrent program *logic*?

For example, consider this: you have a program in which up to 5 threads
may be running at the same time, and they access a number of shared
variables.  In order to fully capture the semantics of the program
(w.r.t. to concurrency), you'd have to somehow depict *all possible
interleavings* of the 5 threads, including parallel executions. How
would such a thing be depicted in 2D or 3D?

Furthermore, if you're going to be mapping degrees of freedom in state
space (which is essentially what you're doing if you want to capture the
interactions between simultaneous cooperating components) into Euclidean
space, then 3D is, in general, going to be far too few dimensions to
fully represent the program. Non-trivial concurrent programs have far
too many degrees of freedom to capture in a mere handful of dimensions.
You'll need to be able to display (*and* visualize) spaces of arbitrary
dimensionality (anywhere from 4D to, say, 237D, or 10423D for large
projects) to be able to work with such a programming model.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson


More information about the Digitalmars-d mailing list