Is Source Code a Set of Instructions or Messages?
日本語はこちら。
Through my career as an engineer, I've seen my fare share of programming code. There's various styles of coding or ways of structuring your code and none of them are exactly the same. But looking at them I see two camps that are very different from each other. One camp treats code as a set of instructions to the computer. The other camp treats code as a set of messages that describe what the computer should do.
In this post, I'd like to give some examples of each camp and talk about the differences between them.
1st Camp: Source Code as Instructions
The first camp treats code as exact instructions to the computer. The engineers who write code in this way think that they know what each step of the program should do and the code they write it in a style that reflects that.
An example of this is the following code:
const person = new Person();
person.name = "John";
person.age = 30;
:
person.sayHello();
As it's obvious from the code, the engineer is telling the computer each step:
Create a new person
Set the name of the person
Set the age of the person
Tell the person to say hello
2nd Camp: Source Code as Messages
The second camp treats code as messages of what the computer should do. The engineer writing this code thinks in terms of what a program should be doing.
So instead of the code in the previous section, they would write something like this:
const person = new Person("John", 30);
:
person.sayHello();
Here the engineer is telling the computer that:
A person should be created with a name and an age.
The person should say hello.
Comparison
There's many differences playing out here.
Explicit vs abstract: The former is more explicit. It's easy for the reader to see exactly what each step is doing. One engineer from this camp referred to it as "the code will tell you exactly what it does". The latter camp’s code will tell you what the "intention" of the program is and tends to be more abstract.
Imperative vs declarative: Because the former is giving exact instructions (i.e. the "how"), it's inherently imperative whereas the latter is indicating "what" the program should do which leads to a more declarative nature.
Target of the code: The former is written in terms of the computer and the latter is typically written with the reader (i.e. other engineers) in mind.
Personal Thoughts
Readers may obviously ask which is better so I'd like to give my personal thoughts on this.
If your development is in a team setting with others reading your code, it's usually better to err on the side of the 2nd camp, "Source Code as Messages".
The reason is because in a team setting with other engineers reading your code, you typically want to convey what your intent was. This lets the reader understand what your code is doing and lead to better quality and easier maintenance. The 2nd style which has the “what” intention in mind does a better job at that.
Another reason is around mental effort. The 1st camp has more details laid out in from of you and typically requires more mental effort to understand. Whereas the 2nd camp is more abstract with the details hidden behind classes/functions/methods making it easier for the reader.
It Depends
Any debate around programming styles, paradigms, frameworks, languages, etc is bound to be a heated one and most of the time the result is "it depends". The same rule applies for the two camps above as well. Depending on the problem domain, the skills of the engineers, the team, etc the "better" answer could go either way.
The key takeaway is to understand the circumstances you are in and make a conscious decision on which style you want to use.