Unix philosophy vs SOLID (know your roots)
Nowadays there is almost no interview where SOLID is not mentioned, however, there are not so many interviews where Unix philosophy is touched. Why is that? Is it due to the time when we are living? Or this is the new modern way (to be honest SOLID is getting old as well).
Before digging deeper let's start with a reminder of what Unix philosophy stands for.
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
2. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
The above was written in 1978, it was a breakthrough and it actually laid the foundation of how we develop software today.
Let's check SOLID principles
The Single-responsibility principle: “There should never be more than one reason for a class to change.”In other words, every class should have only one responsibility.
The Open–closed principle: “Software entities … should be open for extension, but closed for modification.”
The Liskov substitution principle: “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”
The Interface segregation principle: “Many client-specific interfaces are better than one general-purpose interface.”
The Dependency inversion principle: “Depend upon abstractions, [not] concretions.”
SOLID principles were introduced in 2000.
So I have a question for you? Does it ring a bell after reading them one after another? It sounds familiar and logical, I would remind you that the Unix philosophy is the father of SOLID principles.
Let's compare
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
vs
The Single-responsibility principle: “There should never be more than one reason for a class to change.”In other words, every class should have only one responsibility.
The Open–closed principle: “Software entities … should be open for extension, but closed for modification.”
So we have to follow the principle that “You have one job” and be careful adding “modifications”.
Starting to look similar?
2. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
vs
The Liskov substitution principle: “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”
The Interface segregation principle: “Many client-specific interfaces are better than one general-purpose interface.”
The Dependency inversion principle: “Depend upon abstractions, [not] concretions.”
We know that words could be winded and one could find a connection if he seeks long enough in everything, but the above statements clearly show a connection between the two philosophies.
Let us continue…
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
A slight reminder that the Unix philosophy is from 1978 — SCRUM as a term originates from 1993 (first time noted in 1986).
Last point
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
One of the automation principles is USA — Understand (the process), Simplify and Automate. It means that the existing process shall first be thoroughly analyzed, then simplified to the greatest extent possible, and only after that — automated (if still required after simplification).
Back to the roots
We should not forget what Unix philosophy stands for because technology usually reinvents itself and goes back to its roots.
