The UNIX philosophy distilled (part -1)

This article series is in two parts — Significant and Insignificant theories

Significant Theorems

1. Small is beautiful.

The smaller ones have many advantages over the larger ones. Small things can be easily combined in a unique and convenient way

The idea of ​​a small program

• Small programs are easy to understand
• Small programs are easy to maintain
• Small programs are system resource-friendly
• Small programs are easy to combine with other tools

Software developers generally write huge programs.
This is based on the false idea of ​​ ” being able to respond to any contingency.”
Developers of huge and complex programs say, “The future is predictable, and not much different from the present.”
It is premised on selfish belief.
On the other hand, developers of small programs have given up on predicting the future from the beginning.
Their only prediction is that what is made tomorrow is different from what is being made today.
Even if you couldn’t predict it when you made it, a small program can deal with it immediately.
Let’s look to the future. The future will come sooner than you think.

2. Make each program do one thing well.

By focusing on one thing, you can eliminate unnecessary parts of the program.
Unnecessary parts slow down execution, make it unnecessarily complicated, and inflexible.

creeping featurism

Programmers may write simple applications.
But his Creative adds new features and new options.
You should always be aware if you really need that code.
• Does the program require user interaction? Can parameters be file read or arguments?
• Does the input data of the program need to be in a special format? Can’t it be transferred to another program?
• Does the output data of the program need to be in a special format? Can’t it be transferred to another program?
• Do I need to write a new program? Is it possible to combine other programs?

Small programs tend to be single-function, and single-function programs tend to be small.

3. Build a prototype as soon as possible.

Prototypes are important in any project.
Prototypes are generally treated as part of the overall design,
Prototyping on UNIX is an essential part of efficient design.

3.1) Software is not complete

Of course, there is always room for improvement in software, and the source code is not always kept in the best condition due to time constraints.
Most software is a compromise. It’s never finished, it’s just a release.
You must be aware that software and computers are constantly evolving.
The idea of ​​UNIX is also strong in the evolution of software.
If you divide the software into smaller and simpler parts,
It’s easy to adapt to future changes, and if you make the software easily portable, it will be available next year.
It can be easily operated even with a faster calculator.

3.2) Why software is “software”

Users can express what they want, and software engineers say that the features they currently need.
If you knew all the features you might need in the future, you wouldn’t need software.
All programs need to be written in ROM from the beginning. Unfortunately, there is no such perfect world.
It is the basis of the time to constantly receive reports on the progress after the release and make corrections to the corresponding course.
Everyone is always learning. Someone has a requirement for us, even if we assume we know everything
It will change.

3.3) First system, second system, third system

Humans can only make these three types of systems.
It may be that the system created by humans resembles humans.
Just as human beings start from youth, mature, and eventually grow old.
System design also includes young design, mature design, and dead design.

3.4) The cornered humans create the first system

The first system is a system created by one person or a small number of people, demonstrating their creativity while being chased by time.
Due to the time rush, there are some functions that are lacking, but there is no waste and it works efficiently.
It will be subject to various criticisms.
However, the person in question would say, “Oh, I know it’s a little dirty, but it’s useful!”
There is no time to do it “correctly”.
People who do not have the time to do it “correctly” concentrate on the important points and ignore the branches and leaves.
As a result, some details are planned for the next version
The concept of the first system stimulates the human imagination.
It will not be large at this stage.
As the team grows larger, communication and individuality conflicts occur.
Even if people are thrown in at this timing, territory can only be created here and there, and even the realization of the first system is in jeopardy.
It is the mythical man-month.

3.5) Second human system

But when the first system begins to succeed, many people come together.
Then, an “expert” creates a second system using ideas that have been proven useful by the first system.
The function of the second system is decided by a committee consisting of many participants who have noticed the first system.
As a result, too many people’s opinions (including those with proprietary technology syndromes) are taken in, resulting in a slow system with many functions but waste.
The second system, which many have come to expect, is sometimes commercially successful, but in fact it is not very useful.

3.6) Third human system

People who are “burned” in the second system build the third system.
Only the third system can finally build a useful system by incorporating the ideas found by the first system and the necessary functions found in the second system in a balanced manner.
The purpose of the system is well understood, so the risk is small.

At the decision-making stage, you can make a good budget and build a good schedule.
The designer of the third system is finally given time to do it “correctly”.

3.7) To build a third system efficiently

The UNIX way of thinking recommends quick trial production in order to build a third system as soon as possible.
It is not possible to create a third system directly.
1 Write a short functional specification (about 3–4 sheets)
2 Write software
3 Test and rewrite. Repeat this until you are satisfied.
4 Write detailed documentation (if needed)

4. Prioritize portability over efficiency

Software that is not limited to current hardware will be used in the future

The most efficient method is almost always non-portable

Software that is inseparable from hardware can only maintain its value while the hardware remains competitive.
Every time faster hardware replaces existing hardware, it has to be rewritten.

5. Use software leverage to your advantage.

Program reuse is a powerful idea that makes the most of software leverage.
UNIX developers have followed this idea and developed a large number of Applications in a relatively short period of time.

5.1) Proprietary technology syndrome

Contrary to popular belief, proprietary syndromes do not increase creativity. Even if you look at the work of others and insist that you can do better
That alone does not increase creativity.
Redesigning an existing Application from scratch is not a creation, even if it is an imitation.
Rather, avoiding this opens the door to a new and exciting design world.
Don’t give in to the temptation of “self-esteem.”

5.2) Automate everything

One way to leverage software leverage is to make your machine work harder.
It’s a waste of time for humans to do what computers can do manually.
Surprisingly, even in a modern engineer’s laboratory, when you step inside, a surprising number of skilled technicians do their daily work by hand.
Even if you know a good way, it’s hard to get rid of old habits. Is it possible that humans are overworked and computers are sleeping?

6. Use shell scripts to increase leverage and portability.

Shell scripts have the dual effect of leveraging software leverage and at the same time increasing portability.

7. Avoid captive user interfaces.

Some commands have a “user-bound” interface.
Once that command has been executed, no other command can be executed during execution.
While the command is running, the user will not be able to leave it.
This kind of thing is called a “binding” user interface.

To master the advanced technology chest circumference, some knowledge is required on the user side as well.
It seems that the smaller and more sophisticated things are, the more knowledge they need to use them.
It has the following features
・ Small things don’t fit well with humans.
・ Small things mean that even if they don’t get along well with humans, they get along well with each other.

Even in the world of computer software
Having many small programs and modules maximizes the ability to adapt to the environment.
Unfortunately, the smaller the module, the greater the problem of interface with the user.
As the number of modules increases, handling becomes more complicated.
There is a dilemma for software designers. Build from a number of small modules for maximum flexibility in your application.
However, on the other hand, the requirement to make software easy to use cannot be ignored. If there are too many modules, it will be difficult to handle.
UNIX uses a unique method to resolve this contradiction.
Most systems try to fill the growing gap between users and modules with software called “binding” user interfaces.
UNIX developers also admit that the gap is only widening.
However, instead of connecting users and modules with a large number of “spaghetti” cords, they try to gradually reduce the grooves into smaller chunks or layers.

Many UNIX users will display a simple Message indicating the required parameters and how to use them if the user enters the wrong parameters.
There are a little deeper reasons why UNIX users avoid binding user interfaces.
UNIX users need a way to interact with their comments.

Restraint programs assume users are human

The developers of binding programs assumes that there is a human in front of the keyboard.
When the computer is constrained by human limits and the system has to wait for user input,
It can only move as fast as a human sitting in front of a keyboard. In other words, it’s not fast at all.
The palliative program takes a “big thing is beautiful” approach
Constraint programs are difficult to combine with other programs.
Constraint user interface lacks scalability
Most importantly, the binding user interface cannot take advantage of the software leverage.

8. Design every program as a filter

The essence of software is to process data, not to generate it.
To get the most out of it, the program should be designed to act as a filter.

All programs accept some form of data as input and some form of data as output.
It is generally believed that applications create data, but in reality, applications do not have the ability to create data.
It takes imagination to create data.While computers can only create information from the original source of data
All Computers do is convert data from one form to another.

Thanks for reading. The quoted text in this article is taken from the book: Linux and the Unix Philosophy by Mike Gancarz

You can read the free e-book here.

Feel free to share your thoughts in the comments below.