The Three Fundamental Laws of Computer Science, by Carlos Diego

The Russian-American writer Isaac Asimov was a prolific author of science fiction as well as of scientific works, among them “I, Robot” and the “Handbook of Robotics.” In his work, Asimov conceived the “Three Laws of Robotics”: rules, or principles, meant to keep robots under control and to limit their behavior. The three directives state:

First Law: A robot may not injure a human being or, through inaction, allow a human being to come to harm. Second Law: A robot must obey the orders given it by human beings, except where such orders would conflict with the First Law. Third Law: A robot must protect its own existence, as long as such protection does not conflict with the First or Second Law.

Isaac Asimov in 1965

In the classes I teach in the Computer Science undergraduate program at CESAR School, I always try to connect the practical, technical knowledge of each course with the essence of its foundations — to show why things are the way they are or, as Douglas Adams would put it, the meaning of “life, the universe and everything.” None of that business students love to call “a theory class.”

The dictionary describes theory as a “set of rules or laws, more or less systematized, applied to a specific area” or as “speculative, methodical and organized knowledge of a hypothetical and synthetic character.” In other words, we might say that theory belongs to the realm of the philosophical, of observation drawn from empirical experience — which should by no means be dismissed; quite the opposite. It is precisely the first step of the scientific process, as Dr. Richard Feynman so aptly put it in the documentary “The Fantastic Mr. Feynman” (available at https://www.youtube.com/watch?v=BHoPO4qrRGA):

“In general, we look for a new law by the following process. First, we guess it — we guess that this is the truth. Then we compute the consequences of the guess, to see whether it is right: if this law we guessed is right, we see what it would imply. Then we compare the computed results with nature, or with other experiments, comparing it directly with those observations to see whether it works.” Once, in a lecture on Software Engineering by the most distinguished Prof. Silvio Meira, he referred to a documentary titled “The Great Math Mistery,” about the differences between Engineering and Mathematics:

_… engineers are not paid to GET THINGS RIGHT. Engineers are paid to GET THINGS RIGHT… ENOUGH!

… in the world of ENGINEERING, the ELEGANCE of MATHEMATICS meets the CHAOS of REALITY… [and] the PRACTICAL RULES of everyday life.

MATHEMATICS deals with the domain of the ABSOLUTE, and ENGINEERING deals with the domain of the APPROXIMATE._ I immediately thought about how general — and by general I don’t mean something pejoratively generic, but broad and universal — this idea is: that engineering is a science that deals with the approximate. Fantastic! It is one of those conclusions that, had you reached it yourself, you would want to tell everyone about, even a stranger on the street.

That led me to wonder whether it would be possible to distill Computer Science into three fundamental rules. I didn’t want to settle for the dictionary, which defines Computing as “any type of arithmetic or non-arithmetic calculation that follows a well-defined model.” I wanted to go further! I wanted rules — premises — simple enough that, in any given scenario, one or all of their directives could somehow be tied to what computing is in its essence. Until, somewhere between one class and the next… Voilà! Eureka! I found what would become known to my students as “The Three Fundamental Laws of Computer Science, by Carlos Diego”!

P.S.: That paragraph may sound pretentious, but I promise that in the classroom this introduction is delivered in an ironic, tongue-in-cheek tone, often drawing a few smiles from a class that, up to that point, is more worried about what my exams will be like than about anything else. =)

Ready? Then here we go… The three fundamental laws of Computer Science are:

1. Conditional structures;
2. Abstraction;
3. Trade-off.

Law 1 — Conditional structures

In computer science, a selection structure (also called a conditional expression, conditional construct, or if-then-else function) is a control-flow branching structure found in programming languages that performs different actions or computations depending on whether a condition or selection is true or false, the expression being evaluated and reduced to a boolean value. In programming languages, we use English words to express a selection structure, such as if, else if and else. (Mark Summerfield (2013). Programação em Python 3. Alta Books)

There is not a single computing problem to which an algorithm — a logical structure — is not applied. And logic is, for the most part, conditional. We do something as a consequence of something else. Sound familiar? Action and reaction. Sound familiar? That is exactly the basis of Newton’s third law, which states that “for every action force there is a reaction force of equal magnitude and opposite direction.” Let’s rewrite Newton’s third law from an algorithmic perspective:

“… for every action force (IF), there arises a reaction force (ELSE IF) of equal magnitude but opposite direction (ELSE).”

Conditional structures are so powerful that some say they are the foundation of Artificial Intelligence (ironic, tongue-in-cheek tone)!

Law 2 — Abstraction

In Computer Science, abstraction refers to the “process of removing or generalizing physical, spatial or temporal details or attributes in the study of objects or systems in order to focus attention on details of greater importance; it is similar in nature to the process of generalization” (Timothy Colburn and Gary Shute (2007). Abstraction in Computer Science. Minds and Machines).

The process of abstraction may also be called modeling, and it is closely related to the concepts of theory and design. In computing, whenever a problem becomes common or generic enough to make sense across multiple scenarios within the same context, it becomes a candidate for abstraction.

Let’s go back in history a little… Since the most primordial of times — tell me that phrase doesn’t sound like the opening line of a samba school anthem — we have been building abstractions on top of abstractions in computing. In the beginning, we programmed directly on the hardware.

We then came to understand that certain tasks kept recurring — managing peripherals, persisting data, controlling concurrent tasks, for example. At that point we developed Operating Systems, an abstraction above the hardware layer whose role would be to manage everything common to most computational activities, such as managing memory, processing and disk — or what we know as the von Neumann Machine.

The von Neumann Architecture (after John von Neumann, pronounced NOY-mahn) is a computer architecture characterized by a digital machine’s ability to store its programs in the same memory space as its data, and thus to manipulate those programs. Source: https://pt.wikipedia.org/wiki/Arquitetura_de_von_Neumann

Illustration of the von Neumann Machine

And step by step, these abstractions were implemented, one on top of the other. Hardware, Operating Systems, Database Management Systems, Virtual Servers, Containers, Orchestrated Containers, Infrastructure as a Service, Platform as a Service, Software as a Service… Each new layer encapsulates a set of activities that, until then, would have had to be repeated with every new execution in every new instance of a context.

Illustration by Justin Coulston

Law 3 — Trade-off

The American economist Thomas Sowell, professor and author of many gems of economic thought, put it masterfully: “there are no solutions, there are only trade-offs.” Every decision we make solves one problem but creates another.

“There are no solutions, there are only trade-offs, and you try to get the best trade-off you can get; that’s all you can hope for. We cannot achieve a perfect outcome. Several paths can contribute to our common goal of increasing resilience to risk. But the desirability of these alternatives must be understood in terms of the trade-offs between their benefits and costs. We must weigh those trade-offs and choose the best.” A general statement. Simple, objective and profoundly on target. It could just as well apply to other fields — politics, for instance — though there its objectivity would be no match for good old patronage politics, which in the end changes color as the seasons change yet always produces the same results. But let us remember that we are talking about an exact science, and for computing this definition is perfect.

The trade-offs Sowell referred to are nothing other than the engineering approximations mentioned earlier. They embody the wisdom that no solution we create will cover every possibility, because that would simply be impossible. It is what, in the theory of computation, we define as an NP-hard problem.

_“In computational complexity theory, NP stands for Non-Deterministic Polynomial time and denotes the set of problems that are decidable in polynomial time by a non-deterministic Turing machine. An equivalent definition is the set of decision problems whose certificate can be verified in polynomial time by a deterministic Turing machine. NP-hard (also called NP-complex), in computational complexity theory, is a class of problems that are, informally, “at least as hard as the hardest problems in NP.” (Source: https://pt.wikipedia.org/wiki/NP-dif%C3%ADcil)_ In computer science, trade-offs are seen as a tool of exchange. A program can generally run faster if it uses more memory (a space-time trade-off). A practical example: when you compress an image, you can reduce transmission time at the expense of the computing time needed to compress and decompress it. Depending on the compression method — and on its efficiency — this may also involve trading away some image quality.

In sales, it is very common to hear that any deal rests on three principles — quality, price and time — but the customer can only pick two. A solution that delivered all three would be a unicorn — in other words, impossible.

When we build a computing solution, especially in software engineering, it is essential to establish up front what the drivers of our solution are. Civil aviation, for example, made a clear choice in favor of safety. Flying is far from a comfortable experience — unless you belong to the 0.001% of the population who can afford a first-class seat on Emirates. But it is an undeniably safe one. In other words, civil aviation deliberately chose safety as its main driver, even at the expense of comfort. Likewise, a software solution will rarely manage to excel in one respect without compromising another. As Prof. Silvio Meira — there he is again! — once put it: “Every ideal engineering solution is born undeniably unfeasible, because it would be too slow, too expensive or impossible to build with current technologies.” As my dear grandmother would say: “All that roundabouting (sic) just to say a bird in the hand is worth two in the bush.”

And so I close the first version of “The Three Fundamental Laws of Computer Science, by Carlos Diego,” after countless semesters of promising my dear students that one day I would sit down and write out what I so passionately describe in my classes. I close, though not without first applauding the hundreds — perhaps, after 13 years, thousands — of people I have had the honor of teaching and mentoring, who, semester after semester, kept urging me to write the laws down (“Really, write the laws down, professor! It makes sense… Mind the trade-off, professor!”, said some of the more enthusiastic ones). =)

I close by reaffirming how rewarded I feel to be able to teach, and the deep pleasure I take in discovering and understanding why things are the way they are. As for how much fun all of this is, in the words of the illustrious Dr. Richard Feynman:

“I don’t want prizes. I’ve already got the prize! The prize is the pleasure of finding the thing out, the kick in the discovery, the observation that other people use it. Those are the real things! The honors are unreal to me, I don’t believe in honors. Honors are epaulettes, honors are uniforms!”.

References

[1] D. Adams, O Guia do Mochileiro das Galáxias, 3rd ed. São Paulo: Arqueiro, 2004.

[2] I. Asimov, Eu, Robô. São Paulo: Aleph, 2014.

[3] T. R. Colburn and G. M. Shute, "Abstraction in Computer Science," Minds and Machines, vol. 17, no. 2, pp. 169-184, 2007. DOI: 10.1007/s11023-007-9061-8.

[4] R. P. Feynman, O Fantástico Sr. Feynman. Documentary. Available at:https://www.youtube.com/watch?v=BHoPO4qrRGA. Accessed: May 5, 2023.

[5] S. Meira, The Great Math Mystery. Documentary. PBS Nova, 2015.

[6] T. Sowell, A Conflict of Visions: Ideological Origins of Political Struggles, 2nd ed. New York: Basic Books, 2007.

[7] M. Summerfield, Programação em Python 3: Uma Abordagem Completa para Programadores. Rio de Janeiro: Alta Books, 2013.

[8] "Arquitetura de von Neumann," Wikipédia. Available at:https://pt.wikipedia.org/wiki/Arquitetura_de_von_Neumann. Accessed: May 5, 2023.

[9] "NP-difícil," Wikipédia. Available at:https://pt.wikipedia.org/wiki/NP-dif%C3%ADcil. Accessed: May 5, 2023.