Better programs: Citations one should have heard of (part 1)

Better programs: Citations one should have heard of (part 1)

Part one: The years 1957 … 1999

Ever been confronted with name-dropping while being on a programming related discussion? This two-part series on Citations one should have heard of brings some light into the depth of name-dropping and why the background behind those terms helps you getting a better programmer. I arranged the bits and pieces in a chronological order at best knowledge. You find the second part of this series in Part 2 of my blog-post.


1957 - Arithmetic IF 1960 - KISS 1968 - Conway's law 1972 - Encapsulation 1973 - Actor model 1979 - Cohesion 1980 - Call by value-result 1981 - ACID 1983 - Real Programmers 1987 - Law of Demeter 1998 - CAP 1999 - DRY

1957 - The arithmetic IF statement

… The arithmetic IF statement is a three-way arithmetic conditional statement… Unlike the logical IF statements … the … [arithmetic IF] statement defines three different branches depending on whether the result of an expression is negative, zero, or positive …” (see Arithmetic IF)

IF (expression) negative,zero,positive

The arithmetic IF statement was first seen in 1957 as being part of the Fortran programming language. It is being said that it “makes programs more interesting”.


... and what do we learn from this? Delusion and confusion existed ever since the very beginning of modern computer science...

1960 - KISS

…KISS is an acronym for “Keep it simple, stupid” as a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided …” (see KISS principle)


... and what do we learn from this? Not the one who builds the complicated systems is the genius, KISS is genius. Also see KISS ...

1968 - Conway’s law (Melvin Conway)

When Melvin Conway came up with an observation in 1967 to become famous as Conway's law, information technology was far from being mainstream. Though his law is even more true some decades later:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” (see Conway’s law)


... and what do we learn from this? You ever wondered why the software systems your company develops and operates (for its own use) got stuck some decade ago? The code base, hard to understand, nearly impossible to maintain? With respect to conway's law: Look, listen, learn ...

1972 - Encapsulation in programming (David Parnas)

As of David Parnas, encapsulation is also known as information hiding: It hides implementation details of a component from the clients using it by providing a well defined protocol(interface) without revealing the component’s implementation.

… information hiding is the ability to prevent certain aspects of a class or software component from being accessible to its clients, using either programming language features (like private variables) or an explicit exporting policy …” (see Information hiding)

The purpose of encapsulation is to provide room for exchanging a component with another one which is speaking the same protocol and to provide room for changing the internal (non protocol affecting) implementation of a component.


... and what do we learn from this? Extensively using inversion of control breaks encapsulation by reflection. The contradicting techniques of encapsulation and reflection often are supported by modern programming languages at the same time...

1973 - Actor model (Carl Hewitt, Peter Bishop and Richard Steige)

The actor model was initially developed by Carl Hewitt, Peter Bishop and Richard Steige. Interestingly enough, its functioning was inspired by physics and it was to enable highly parallel computing by means of message passing:

… [the development of the actor model was ] … motivated by the prospect of highly parallel computing machines consisting of dozens, hundreds or even thousands of independent microprocessors, each with its own local memory and communications processor, communicating via a high-performance communications network …” (see Foundations of Actor Semantics)

With the actor model, everything is considered to be an actor (see akka’s actor systems). As of enabling highly parallel computing, actors may concurrently respond upon a incoming messages:


... and what do we learn from this? Are our microservices nothing more than just some exotic flavor of the actor model? Regarding the protocol: Shoudn't we use message passing then instead of RESTful services?

1979 - Cohesion (Edward Yourdon and Larry L. Constantine)

The term Cohesion states the degree on how strongly related the parts of a module are to each other.

… In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, cohesion measures the strength of relationship between pieces of functionality within a given module. For example, in highly cohesive systems functionality is strongly related …” (see Cohesion)


... and what do we learn from this? Get higher cohesion by eliminating utility classes with the utility-builder pattern.

1980 - Call by value-result (Ada)

Also known as call by copy-restore, call by value-result copies the modified formal parameter’s value passed to a function back to the caller’s variable:

… the actual parameter supplied by the caller is copied into the callee’s formal parameter; the function is run; and the (possibly modified) formal parameter is then copied back to the caller. This allows a function to modify the state of its caller …” (see Call By Value Result)

This technique of passing back a results is used by the Ada programming language (see Parameter passing).


... and what do we learn from this? Call by reference is not the only hack to change the state of a caller.

1981 - ACID (Jim Gray)

Jim Gray worked them out, the desirable properties for distributed database transactions, followed by Andreas Reuter and Theo Härder to give them the acronym ACID:


... and what do we learn from this? You can become famous by picking one other's findings and give them a cool acronym. Though it is not proven yet that giving a trivial observation a cool acronym makes you become famous as well (also see the SISO principle) ...

1983 - Real Programmers Don’t Use Pascal (Ed Post)

Originally written as a letter to the editor on the DATAMATION 7/83 magazine, Ed Post’s parody Real Programmers Don’t Use Pascal (Echte Programmierer meiden PASCAL) circulated widely through the Usenet.

His article reveals some bad habits and questionable attitudes of them self-proclaimed top coders and brings the “black or white, nothing inbetween” discussions to its essence, in a really humorous way. Remember them Atari versus Commodore discussions, followed by them Linux versus Windows, C++ versus Java, Java versus JavaScript and Apple versus the rest of the world flame wars?

… The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses


… Real Programmers can write five page long DO loops without getting confused … Real Programmers enjoy Arithmetic IF statements because they make the code more interesting … Real Programmers write self-modifying code, especially if it saves them 20 nanoseconds in the middle of a tight loop … Programmers don’t need comments: the code is obvious …


… As all Real Programmers know, the only useful data structure is the array. Strings, lists, structures, sets – these are all special cases of arrays and and can be treated that way just as easily without messing up your programing language with all sorts of complications. The worst thing about fancy data types is that you have to declare them


… the Real Programmer … tends to make things more challenging by working on some small but interesting part of the problem for the first nine weeks, then finishing the rest in the last week … This not only impresses his manager … but creates a convenient excuse for not doing the documentation

The above quotations I found remarkably amusing, bringing many discussions I experienced to the point.


... and what do we learn from Ed Post? Don't waste mine, yours and the time of others with those "black or white, nothing inbetween!" discussions ...

1987 - Law of Demeter

… don’t talk to strangers …” (see Law of Demeter)

The Law of Demeter was proposed as guideline in 1987 by the Northeastern University and states that objects are to communicate only with other objects in their direct neighborhood. The intention is to increase maintainability of software systems by reducing dependencies and therewith reducing coupling (as of desirable loose coupling).

  • Each unit should have only limited knowledge about other units: only units “closely” related to the current unit
  • Each unit should only talk to its friends; don’t talk to strangers
  • Only talk to your immediate friends

Being in compliance with the principle of information hiding, the Law of Demeter states that a given object should assume as little as possible about the structure or properties of anything else.

The below example illustrates breaking the Law of Demeter as the user of car should not know on how to start the car’s engine (being the stranger); instead it should just know of the car as being the direct neighbor (and on how to start the car itself).

car.engine.start(); // Breaking the law of Demeter

... and what do we learn from this? Mom was right! Don't talk to strangers!

1998 - The CAP theorem (Eric Brewer)

No, no, no, you can’t have everything! The CAP theorem says that in a distributed computing system you cannot have all at the same time. You got to decide which two of the three properties you want:

… the CAP theorem … states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees …” (see CAP theorem)

  • C - Consistency: All nodes see the same data at the same time
  • A - Availability: Every request receives a response about whether it succeeded or failed
  • P - Partition tolerance: The system continues to operate despite arbitrary partitioning due to network failures

... and what do we learn from the CAP theorem? Let's skip C and decide to be happy with eventual consistency ...

1999 - DRY (Andy Hunt and Dave Thomas)

Some people consider RY as the new DRY, especially with regards to the upcoming microservice architectures. I don’t belong to the RY school. Nevertheless, the acronym DRY was proclaimed by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer and stands for:

  • D - Don’t
  • R - Repeat
  • Y - Yourself

... and what do we learn from this? Be High 'n' Dry! Where is the HIGH principle? To stay DRY, did I mention the utility-builder pattern?

Follow-up

The years 2004 … 2016 are approached in Part 2 of this article series:


2004 - Strangler application 2005 - Ports and Adapters 2005 - SOLID 2006‎ - Viscosity 2014 - Microservice prerequisites 2016 - SISO

comments powered by Disqus