Eureka! A monumental breakthrough has just occurred this morning in my understanding and approach to designing the Data Spatial Programming (DSP) model. One of my most significant intellectual hurdles has been to visualize how this DSP model maps computationally to Object-Oriented Programming (OOP) and procedural models. Let me explain this breakthrough, how the DSP model relates to the more conventional models, and why it’s not just a novelty but a serious game-changer for programmers.
The Struggle
For a while, I had this lingering thorn in my mind – I struggled to find a simple and intuitive way for a programmer to internalize and quickly “see” what DSP is and why it’s beneficial. Sure, it was easy to show people how it works, but explaining why it works, that was always fuzzy and hand wavey. Until this morning, that is.
The Breakthrough Insight
The insight that dawned on me this morning was almost too simple to believe. But that’s the beauty of it; the simplest solutions are often the most profound ones. So, what is it? Well let me first attempt a succint definition of DSP. The DSP model fundamentally expands the notion of objects and methods/functions into nodes, edges, and walkers. Instead of functions/methods calling other functions/methods, passing and returning variables, we have walkers. Walkers travel through a graph of nodes and edges, carrying data through the graph, and triggering “abilities”. These abilities are similar to methods, but instead of having arguments or returns (as in a call stack), they only access data in the walker that’s visiting an associated node or their own data within the associated node. This allows the programmer to now represent deeper relationships between object types and employ a data in-situ (or spatial) style of programming, making solution complexity much more modular, encapuslated scalable. Now, lets look at the key insight…
From OOP to DSP
The key (amazingly obvious in hindsight) breakthrough insight is that much like there is a theoretical equivalency and convertibility between OOP and procedural representations of a program, there is a similar one between DSP to OOP/procedural. This data spatial programming model doesn’t exist in a vacuum but follows in the footsteps of major language evolutions in our era. How can we convert an OOP model into a DSP one you ask? Here are the steps:
- Transition Functions to Walkers: For all functions, take all parameter variables, its own and those values passed to sub calls, and make those “has” variables. Remove all these parameter specification from itself and its sub-calls. Now, you have a walker.
- Transition Classes to Nodes: For all the classes you’ve created in your program, take all method parameters and make them “has” fields in each class. Now, your methods are abilities… almost. For the next step, Visualize your objects as now disconnected nodes in space – indeed, this is what objects are in OOP.
- Create Edges: For each class (now node) method that calls the method of another class, create an edge between these nodes. Now we can remove all the parameter passing within class methods and implant those parameters into the walkers that visit the node.
- Update Walkers Path: Finally, update the walker’s path-taking logic according to this created graph of connected nodes. Voila! You now have a DSP version of your OOP program.
Note:
Also note, this transformation can be done backward to go from DSP to OOP by following the same process in reverse.
This DSP version of your program isn’t just equivilant to the OOP version, it now has the potential to be much better. This is primarily because you now have much richer semantics to express a given problem’s solution. With the addition of edges, you can now represent deeper relationships between object types. And with the complete encapsulation of data, and a data in-situ style of programming, you can make your solution complexity much more modular, encapuslated and ultimately scalable.
This is the foundational insight nugget…
I realize this may seem a bit overwhelming and complex for some, but I assure you, this insight is monumental for the DSP programming model. This insight nugget creates the foundation of how to make clear what DSP is but also showcases its potential benefits in a way that can be intuitively understood by programmers familiar with OOP and procedural programming. This insight will be vital in further developing and communicating the nuances and potentials of the DSP model.
The DSP model holds promise for revolutionizing the way we think about and manage data. As we continue to design and refine it, I hope this breakthrough insight will help others better understand this new approach and its potential to transform programming.
