2D, 3D and 4D Languages

If you are looking for something about graphics, then go away. Nothing of interest here.

I want to coin some terms that allow us to describe the languages we use. Nothing fancy but we might find it useful to limit the pro/con discussions and abstract them to something simpler.

We have talked bout 3rd Generation and 4th Generation languages to allow us to conceptualize the abstractions at the language level as opposed the class level. 4G languages are still being sold by those after some money but continue to be generally despised by programmers that can't make them do what they need.

OK, so why add the concept of a dimension here? Well, it probably has something to do with how my mind works and is not necessarily anything anyone else might share but when you say "refactor these lines into another method" I see that as a vertical or horizontal shift in behavior. Perhaps they are being generalized into a base class, vertical obviously, or moved into a delegate class that would be a right shift. These are 2D movements performed in all languages but C, for example, is limited to these kinds of adjustments.

Some languages are able to move along the Z axis. Object Oriented languages add to the 2D shifts the ability to distribute behaviors across instances, while not being able to vary behavior along this axis they are varying state and therefore execution paths vary by vertical plane. Each layer represents a keenly scoped set of behaviors driven by the state passed in. These are cones of execution, from a single method entry point at the tip of the cone, the state is distributed out across a set of associated instances to apply the appropriate behavior.

These 3D models become more complicated when you consider how some line of code inside a cone might throw an exception that provides a pipe to some layer of your application, in-front-of and left-of the throw point. It produces a hole in the side of the cone where flow can pass to another location.

Cones are contained within other cones of coarse, the applications main method being the pointy end of the outer cone. The API design rules we apply like no globals, no leaky abstractions, scope actions on state within their own class, all go to explain why no cone sides should ever intersect.

If you are still with me, then on we move to the 4th Dimension. I don't know how you conceive this in real space but I tend to look at the time dimension as a set of invisibility cloaks. As you move forward throw the cloaks, the last set of 3D stuff you were looking at disappears and another set appears. Presumably, we could move backwards to start seeing back in time.

Well Ruby, and other dynamic languages, have started playing with this dimension. Each instance, executing it's methods in it's cone, can be changed at runtime. A call to File.new here is different from the same call there. This allows us to evolve what is being executed based on state, time or idle whim. Code is data, data is code.

Now these concepts have some evolution ahead of them since these changes are made at "indiscreet points" at the moment. So I have to make the change and then execute that change. I can't encapsulate a change and an execution into a single language concept but these are just the semantics we play with today.

Behind each invisibility cloak is a 3D model of a runtime. Each model contains a set of finite behaviors and their changing state. Any statement that mutates it's own behavior, creates an invisibility cloak.

Don't confuse these with threads. Threads are shiny, sparkly little stars, like the sparklers from fireworks night, that run around your 3D cones doing stuff. There may be many of these things in a single 2D or 3D model, all buzzy and excitable. Some running around the same cone, trying to find your threading bugs for you but as long as your cones don't have cracks you will be fine.

When you hear Ruby programmers arguing about that there are no static methods in Ruby, what they are saying is that Ruby is a 4D language and the person they are arguing with only knows 3D languages. It's just like the old arguments that prompted 2D experienced people to say that we could do anything in C that you could do in C++. Yes, I used to argue that one back in the day. Fundamentally true only because it's also true that you can build a house with matchsticks if you really, really wanted to.

Ruby offers far more than just it's 4D features. Open classes, modules and closures are different ways to describe static, 3D concepts. A language becomes 4D when it can vary it's behavior at runtime. This isn't a new concept on it's own. I used to write basic programs that added code as it ran 20 years ago but this is more than this simple concept.

When we look at programming we talk less about the detailed syntax of how features are coded and more at the best constructs that survive change and optimize re-usability. We don't have many strategies defining how to mutate code as it runs to augment the runtime model that is executing.

The best proof that I don't know what I am doing in 4D is to look at the invisible cloak. I think this shape needs to change to better describe the scoped change that a piece of behavior might adopt.

I wonder what 5D means?