What if Programming Is Like LEGO?

Thu, Jul 9, 2020 ❝What if programming would be as easy as playing with LEGO-bricks?❞

Contents

TL;DR There is no point in searching for programming-like-LEGOs. PHP allows us to pretty much do the programming-like-LEGOs thing. It is insufficient in the long run. “LEGO-likes” leave a lot to semantics, therefore do not give us the level of control we need in software development.

Disclaimer I have little (recent 😁) experience in creating with LEGO. I may slip up in painting a picture of LEGO that is too limited or subtly incorrect. The intention is to work the best I can with the existing, common analogy. In addition, we are only considering the plain LEGO-pieces unless explicitly stated otherwise.

Introduction

One comparison is of creating a program as building with LEGO-pieces. There are many more articles discussing this, just search the internet a bit and you should find many more. The idea is that building something out of LEGO-pieces is so simple that anyone can do it, so why could programming not be equally simple in its application? Many articles go on to emphasize the immense complexity of programming compared to building with LEGO. (Note that the referred article compares it to organ transplants which makes more sense.)

Firstly, there is an implicit assumption that building with LEGO-pieces is a near-perfect experience. Secondly, there is this common understanding that we are “not there yet”, i.e. such a programming language does not yet exist. Thirdly, there is an implicit assumption that, when we get there, it is (almost exclusively) a positive experience.

This article takes the approach of evaluating the characteristics of LEGO from a perspective that is comparable with programming languages. This means that this comparison is not by anymeans perfect or complete. It is just a particular view, chosen for comparability. I am going to discuss the first two assumptions. I will also discuss the third one and reasons about why we might be chasing the mythical holy grail instead of a realistic, useful goal.

The current common understanding

So, how do people view LEGO-pieces? Here are a few properties that you might recognize:

1. It’s so simple that even a small child can use them.
2. Everything just fits together.
3. You can build all kinds of things using the same bricks.
4. The same bricks can be reused time and time again.
5. There are very few things that can go wrong.

So how does it compare to programming?

1. Programming languages have many different “building blocks”, i.e. types (both primitives and classes), methods, etc.
2. Programming requires many properties to match up in order to make it fit, i.e. types, parameters, return values, everything must match otherwise you get errors.
3. Each “building block” has a very specific (singular?) purpose and there is “little possibility for reuse”.
4. It is hard to envision the result beforehand. You need to execute the program to see the result.
5. Code cannot be reused due to the “gorilla holding the banana”-problem:

   “You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” – Joe Armstrong

In summary, programming has many more rules and consequences. Things aren’t as simple as stacking LEGO-blocks. We would like to imagine having these independent modular blocks, but we never really seem to reach that ideal.

So, is it an unattainable goal? Would LEGO-pieces - ruled by the laws of physics - really be many times simpler and better than programming, which lives mostly in its own universe?

Analyzing LEGO characteristics

To thoroughly understand LEGO-pieces, let’s evaluate their function and express it in syntax and semantics so we can compare it to programming languages.

Syntax

Syntax, for LEGO-pieces, is basically what makes them composable, stackable primarily. The pieces interact with a single interface: the set of notches with which we can attach them to other pieces.

1. Pieces all have the same type of interface: the notch, used for attaching them to other pieces.
2. Pieces have differently sized interface, i.e. number of notches. Some pieces are larger than others.
3. Pieces have different shapes and dimensions: pieces have to line up in all three dimensions to “interoperate”, i.e. compose.

Semantics

The function of the pieces are the remaining characteristics that we all so adore:

1. Representation: what does the piece represent? Is it a plain rectangular brick? Or is it a human-like piece? Does it look like a window?
   • color / painted-on texture
   • shape
2. Composition: what is the composite effect?
   • pieces interoperating: for example, the effects of physics when pieces are wrongly attached. But also the over-all shape: is it a house, or a sports car, or …?
   • aestetic quality: does it look nice? Attaching bricks of arbitrary colors in arbitrary order might not provide any satisfaction or look like anything recognizable.
3. Constrained: the plain LEGO-pieces are used to construct static representations. There is little possibility for dynamic behavior (machination/automation). LEGO Technic covers this area of semantics.

In conclusion

The human imagination plays a significant role. Pieces have little syntax and everything remaining is semantics. Pieces can easily be attached in such a way that the result is meaningless and ugly. Even if the pieces are composed in a way that is meaningful and aestetically pleasing, the construction can still be fragile. Think of many layers of bricks, each stacked exactly on the previous. The resulting wall can easily tumble. That is why houses have their layers of bricks shifted compared to the layer below.

All of these kinds of construction “best practices” are not enforced in any way by the pieces themselves, i.e. it is not part of the syntax. Similarly with the shape of the composite. Nothing in the LEGO-pieces themselves guides/forces the user towards certain shapes. The intended shape is completely a function of the composite, or better said, how it is interpreted.

Evaluating programming language characteristics

It would be a large and mostly useless exercise to evaluate all programming languages. Let’s instead analyze a single programming language with similar characteristics: PHP. To be clear, I am referring to the earlier versions of PHP - around the time of versions 4 and 5 - that did not have strict rules for classes.

Syntactic requirements:

• Simple interface: PHP is weakly typed, so anything can be interpreted as a string. Like LEGO-pieces, where everything that interacts is defined as a notch.
• Anything that matches the number of parameters can be used. So the “size of the interface” is easily adapted to.
• Classes provide many different “shapes”. (However, due to weak typing, everything is still freely interpretable.)

All in all, the number of syntactic constraints is limited. Anything remaining is expressed as semantics and up to the programmer to compose correctly, as is the case with the semantics of LEGO-pieces.

The reputation of such a programming language

So, a programming language that is comparable in easy-of-use to LEGO-pieces, already exists. Given the high regard of building with LEGO-pieces, one would expect PHP to be the holy grail of programming. This is, however, for the large majority of both programmers and use cases not so.

PHP in itself is simply too limited. Even large companies, such as Facebook, that started out using PHP ran into its limitations. Speed, constraints, control, memory usage, locality of (type) information. There are many aspects that are made more difficult due to the weak and dynamic nature of the language.

Smaller companies or companies with little stake in the programming language will eventually move to other languages that are better suited. Large companies will invest time and resources into tooling that helps them acquire the control that they need. Facebook decided to introduce similar language to PHP that introduced gradual typing.

Conclusion

PHP is used. Large companies such as Facebook built their platform on PHP. However, eventually more/stricter syntax is required. The “building with LEGO-pieces”-paradigm is no longer sufficient. Facebook is solving this piece-meal by introducing gradual typing to the PHP-language. Parts of the code can be typed for extra control. Large software applications are developed from the start in languages with stricter syntax. Of course, starting off with stricter languages also means trading off time for control. It takes more time to build in stricter languages.

Similar to how programming languages need more syntactic support to assist in complicated projects, LEGO has a separate product line LEGO Technic. Similarly, LEGO Technic has more extensive syntax in the form of gears, axels, with specific size requirements. No longer does any piece fit on any other piece. To enjoy a fully operational construction, one needs to correctly compose the various LEGO Technic-pieces. If not, one fails to transfer and consequently loses propagation of kinetic energy. For LEGO Technic, there are more syntactic requirements to be satisfied to achieve the right semantic value.