Momentum Programming (MP)

According to Wikipedia: “Metaprogramming is a programming technique in which computer programs have the ability to treat other programs as their data. It means that a program can be designed to read, generate, analyze or transform other programs, and even modify itself while running.” Also, “One style of metaprogramming is to employ domain-specific languages (DSLs)”. Momentum Programming should be mainly understood as Generative Programming (GP) where “it describes the practice of writing programs that generate other programs as part of their execution.”

Inheritance and composition should actually be about programming of programming. This means that code is written once and duplication of semantically and logically same code is avoided by automating the process of generating the whole source code from parts. I know that few of you now complain that “but hey, polymorphism is the same thing”. Well, it is not. Let me introduce a new concept of “momentum programming” (MP):

Momentum programming describes all of the source code as multiple layers where the amount of manual labor (read programming) decreases as we get approach level 0. Of course, the same concept should be applied at systems scale too: e.g. build pipelines and delivery. Ideally, the higher the level we stop the manual labor at the more we experience quality and then we also might have a chance to actually achieve productive software generation! Let’s check one possible layering:

• Level 0: compiled source code (bytecode in Java)
• Level 1: source code that can be compiled (correct syntax)
• Level 2: first momentum level that generates level 1 source code: configuration phase, etc.
• Level N: (N-1)th level momentum level that generates level (N-1) source code

 

What each level does is that they generate source code and then distribute it by copying, replacing and modifying current source code at certain level. The goal is to generate level one source code that contains only whole objects which do not extend (inheritance) any classes or implement (composition) any interfaces. Let’s see an example of this:

// MP level 2: first meta-level
((x=3;))
j((x--)) = j((x--)) + ((x));

// MP level 1: generated source code
j3 = j2 + 1;

// MP level 0, Example from https://en.wikipedia.org/wiki/Java_bytecode 
0:   iconst_2
1:   istore_1
2:   iload_1
3:   sipush 1000
6:   if_icmpge 44
9:   iconst_2
10:  istore_2
11:  iload_2
12:  iload_1
13:  if_icmpge 31
16:  iload_1
17:  iload_2
18:  irem
19:  ifne 25
22:  goto 38
25:  iinc 2, 1
28:  goto 11
31:  getstatic #84;
34:  iload_1
35:  invokevirtual #85;
38:  iinc 1, 1
41:  goto 2
44:  return

How about the bold claim of “avoiding” inheritance and extending with generation, substitution and copying? The tools to achieve it are simple: cut, copy, paste, find and replace. Most of the work can even be done with regular expressions. What programmers should be worried about is the level one source code that will be visible via continuous pre-processing: but it is only for viewing purposes. As usual, errors at level one will cause errors during compilation.

Momentum programming is about writing less code by utilizing exponential techniques. It is also about writing only whole objects without traditional polymorphism or composition. Each class is it’s full independent representation. This helps getting rid of bad parts of the code: like where you do if-else checks with ‘instanceof’ in Java. IMHO, even the documentation should not be independent from the other classes – even if some of the methods, fields, etc. were the same. This makes any library or framework model more flat and leaves only real dependencies visible!

So polymorphism will be replaced by constructing whole objects. But when a class implements multiple interfaces, it becomes “composed of”. Although interfaces are very useful for taking advantage of composition, they should be replaced with MP too: because each interface should not be “implemented” separately but the implementation should be written once and copied when possible! This is actually already what JavaScript’s (or ECMAScript’s) “Object.assign” does – kind of. But even the “assign” is just an inefficient and synthetic technique for the developers to structure source code. Code should express what it does and be less about how it does…

Also, this way you can finally give up using “type casting” and replace it with Converters and Serializers. Think about it: it does not make sense to make type casts, but it it must be possible to convert objects to different types. For example, if an object is immutable (as they often are nowadays in distributed systems) it is not even possible to convert the type, because you are actually creating a new object – with a different type.

Finally, an important link with another post that touched the topic of generating code. To make software code automation easier we have to get rid of any strings and, in fact, any direct value assignation. Then we move these into a configuration phase that is at least at level two of the Momentum programming: in this phase the values are copied into their places (cf. ‘#define’ in the C programming language preprocessor).

The final goal is to describe the source code as “deep” level as possible, which also means that even configuration data must be part of the same process. Momentum programming can be understood also as exponential reduction (or expansion in the reverse direction) of the source code; someone could say that it is a form of textual compression. Interesting enough, there are related ideas like Kolmogorov complexity that is linked to general (artificial) intelligence, which points the direction for true automated software generation – and artificial intelligence singularity.

In Java, there is a technique called Reflection which allows you to introspect code at runtime. So for example, you can check all methods which have start with “get”. So in a way, reflection is one way of doing momentum programming, but it is the other end of it. In its clearest form MP is about writing code that produces code! And whenever reflection is used you really can’t see the resulting code, and for that reason I think MP should be a preferred choice. In summary,

Compile-time/Momentum programming <-- source code --> Runtime/Reflection

So we have Reflection but we are missing MP currently!