Codithm, A Universal Pattern Design Language
There is definitely something remarkable in doing things by hand. An involvement with the matter than no alternative can match.
The act of expression on paper is powerful. Not only it gives you room to perform but also the contemplate your performance as it unfolds. It is intuitive and unforgettable.
Expression is always driven. There is a problematic at hand; something it wants to address. In this sense, expression is an answer; the door to a solution.
Problem-solving starts with thinking the problem, not the solution. As we wrap our head around the situation we try to angle the issue. Awareness chains into ideation whose result is an algorithm; the concept of a solution.
Algorithms are so generic and powerful. A prescriptive tool that helps us shift the description of a field with a problematic configuration to compute a new state of its reality. It is a code to effective behavior.
Pay close attention, you will realize their omnipresence.
Almost anything we find around is the product of a design-act either by ourselves or by others. Its space is governed by the rules of the intellect behind it. Within its bound, to get what we want, we must speak its grammar; we must code patterns.
I have seen in the past and still see people brag about “coding directly”, claiming that algorithms are a waste of their time. A problem challenging enough is all it takes to make them resort to “pen and paper” or see them walk away as a failure.
I understand the attitude. There is more on coding than thinking code. For most, thinking might be a stretch and even too abstract.
I always looked at the available means of thinking code on paper with dissatisfaction. They felt unnatural. That aside, the process in itself is something else. Those who took the time to experiment with it and noticed how it improved their ability will surely concur.
As a matter of fact, thinking code does not have to be in-code per say. Each has his own process. Mine comes in the form of drawing shapes and geometries. If you ask me, I’d say that I am charting the topology of the problem.
The taught algorithmic language fails at being an interface between human thinking and machine thinking. It is just a softer replica of a programming language.
In “The Core Elements of Coding”, we left the discussion at topic of design patterns. This essay can be thought of as a follow up and will detail a language I have been using to think code.
My idea outlines a language that integrate the most essential ingredients of code while leaving more freedom in the expression of solutions; a sort of proxy language.
Codithm is my instantiation of such idea.
Designed with the spirit of practicality in both writing and reading, I did strive to mix in the various insights I’ve accumulated over the year with some stylistic aspects.
I argued in [article] that most if not all modern coding languages share the same core components which are, variables, conditionals + loops, functions and finally objects.
This componentization synergizes well with the dichotomy of code into data structure and data operation.
Variables encode data and functions, the operations on it. The latter, as mentioned before, adheres to the IPO model. The combination of data propagating through the instances of such model generates an informational flow.
Code in its entirety and throughout its execution is an informational flow. It is made of sub-flows that are created and terminated as data permeates through the decisions structures we compose as a solution to the problem at hand.
The computational answer to a problem results in the design of an object whose mutation from the problematic state to the desired solved state is nothing but a flow of information.
This way of putting things leads us to view code through the lenses of flow. Its default direction in all programming languages is top-down. And practically all languages define two ways to altering it, that is, conditionals and loops.
Based on what I elaborated so far, I introduce a descriptor called, the flow operator.
I define the inward and outward motion of data between code objects along the direction of writing.
We can employ the flow descriptor to express all the important data operations along with execution control. In what follows, I employed geometric terminology for these operations based on this tweet.
Data Translation
Data Rotation+Scalling
Execution Control
Beside flow and the whole dynamic aspect, code is also made of data. The virtual substance contained memory. It has mass to define its capacity and also shape to convey its suitability.
The completing piece of this algorithmic language is another descriptor I termed, the structure-type operator.
Type
Structure
Reading and writing goes hand-in-hand. The effort we make in writing is proportional to how much we want the reading to be efficient. All I did was to reverse engineering that need into a suitable language.
I don’t know for most of you, by my process of reading and understanding code follows a simple directive. As I run through the lines, I strive to keep track of data and its shape as it goes through transformations and execution decisions. All, while I speculate (if not commented) about the meaning of the processing it underwent within the context of execution.
And so both the flow and structure-type descriptors help us keep track of such things. This language is by construction the adequate representation to formulate solution patterns.
This concludes the exposition of Codithm in its zeroth version. I link here the repository where I keep the files related to any future development I make. Suggestions and elaborations are welcomed.
