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 1983 - Our rich neighbour Xerox 1983 - The Spirit of C, Guiding Principles 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,positiveThe 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”.
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)
What do we learn from this?
Not the one who builds the complicated systems is the genius,
KISSis genius. Also seeKISS...
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)
What do we learn from this?
You ever wondered why the
software systemsyour 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 toconway'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.
What do we learn from this?
Extensively using
inversion of controlbreaksencapsulationbyreflection. The contradicting techniques ofencapsulationandreflectionoften are supported by modernprogramming languagesat 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 incoming messages:
Actorssendmessagesto oneself or to otheractorsActorscreate newactorsActorschange one’s own behavior
What do we learn from this?
Are our
microservicesnothing more than just some exotic flavor of theactor model? Regarding theprotocol: Shoudn't we usemessage passingthen instead ofRESTful 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)
-
High cohesion: Each code element (amethod, aclassor amodule) is responsible for exactly one well defined concern or functionality as of thesingle responsibility principle(see alsoSOLID).High cohesion→ Considered good -
Low cohesion: Withlow cohesiondifferent concerns are mixed in a single code element (amethod, aclassor amodule), causing functionality to be implemented multiple times as it cannot be reused.DRYis here to help you prevent it.Low cohesion→ Considered bad
What do we learn from this?
Get
higher cohesionby eliminatingutility classeswith theutility-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).
What do we learn from this?
Call by referenceis 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:
A- AtomicityC- ConsistencyI- IsolationD- Durability
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
SISOprinciple) ...
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 IFstatements 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.
What do we learn from this?
Don't waste mine, yours and the time of others with those "black or white, nothing inbetween!" discussions ...
1983 - The Spirit of C, Guiding Principles
Some time around the years 1983 through 1985, ANSI C was standardisized, with the committee concerned keeping the Spirit of C in their minds during the process of standardization. One of the spirit’s Guiding Principles1 maybe an anti thesis of framework magic currently happening everywhere:
“… Don’t prevent the programmer from doing what needs to be done …”
Regarding the magic of some frameworks (and even programming languages), I would like this principle to be taken more seriously:
- Do not rely without any need on mechanisms you do not understand, sooner or later you will be confronted with unexpected behavior.
- Make sure your code is self-explanatory [without the need of knowing ever changing magic semantics] so it stays portable, maintainable and debuggable.
- Customize your code for a specific case, keep things simple whilst not hiding what’s really happening, so for you not to miss or overlook anything.
What do we learn from this?
In framework magic we don't trust ...
1983 - Our rich neighbour Xerox
I came across this one at my company: Someone had taped a citation from Steve Jobs on one of the offices’ glass doors, stating something like:
“… Innovation distinguishes between a leader and a follower ...”
After a wile, someone else taped another citation from Bill Gates just below Steve Jobs’ citation, stating:
“… Well, Steve, I think there’s more than one way of looking at it. I think it’s more like we both had this rich neighbor named Xerox and I broke into his house to steal the TV set and found out that you had already stolen it …” (Bill Gates, 1983)
The background of this citation from Bill Gates was that Steve Jobs accused Bill Gates 1983 on Microsoft copycatting Apple’s graphical user interface. As the history of the graphical user interface is well documented, we all know that Apple ows Xerox on innovation and therewith is actually just a follower (read the whole story at Folklore.org: A Rich Neighbor Named Xerox).
What do we learn from this?
Not only repeating that "innovation distinguishes between a leader and a follower" often enough makes people believe you are innovative: Repeating just about anything often enough makes people believe that it is the truth ...
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 DemeterWhat 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 timeA- Availability: Every request receives a response about whether it succeeded or failedP- Partition tolerance: The system continues to operate despite arbitrary partitioning due to network failures
What do we learn from this?
Let's skip
Cand decide to be happy witheventual 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’tR- RepeatY- Yourself
What do we learn from this?
Be
High 'n' Dry! Where is theHIGHprinciple? To stayDRY, did I mention theutility-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 2005 - Poe’s law 2006 - Viscosity 2014 - Microservice prerequisites 2016 - SISO
-
See The Spirit of C (Andreas Zwinkau), also see STANDARD C: THE ANSI DEAFT GROWS UP [PC Mag] (Richard Hale Shaw), 13.09.1988, page 117 as well as C Primer Plus (Stephen Prata), page 18 ↩