The Unix philosophy: Putting it all together

8.1 The Unix philosophy: Putting it all together

In the previous chapter we saw how the whole is often greater than the sum of its parts. This is especially true of the Unix philosophy itself: Each of its tenets hardly has the strength to stand on its own. Storing data in flat text files doesn't buy much unless you have the tools to manipulate it. The goal of portability over efficiency seems shallow without shell scripts and the C language to accomplish it. Writing a collection of small programs makes little sense if they cannot be used as filters.

The Unix philosophy is like a giant water slide at an amusement park. You cannot decide part way into the ride that you'd like to skip a few curves-you'll only wind up on the ground bruised and bleeding. As many have discovered the hard way, the Unix philosophy doesn't work if you employ it piecemeal.

Embraced together, however, the tenets of the Unix philosophy take on a broader, more powerful dimension. They interoperate and reinforce one another. Any criticism leveled at a lone tenet can be met by a response from another tenet. The old adage, "united we stand, divided we fall" rings true here.

Let's visit the Unix philosophy once more. This time, though, we will focus on the relationships among the tenets, the goal being to expose the synergy you get by using them together.

Small programs have definite advantages. They are easier to understand because people have less difficulty dealing with a small something than a large something. Their being easier to understand also means that they are easier to maintain. Therefore, they are more cost effective in the end. They also use fewer system resources. This enables them to be loaded, run, and then released quickly, yielding greater efficiency, an attribute that must often be sacrificed for the sake of greater portability. Finally, small programs combine easily with other tools. By themselves, they do little. In concert with a suite of other small programs, they enable programmers and-most importantly-users to create new applications rapidly.

Small programs should remain focused (i.e., they should do one thing well). It is more important to solve one problem than a slew of them in a single program. By dividing large complex problems into smaller ones, it becomes possible to conquer them a bit at a time. Programs that do one thing well can be reused in other applications with much less difficulty. Their abilities are well defined and not clouded by useless "cruft" that can obscure a program's functional definition.

Small programs that do one thing well avoid becoming large complex monoliths. Such monoliths often contain "spaghetti code" and are difficult to join with other applications. Small programs acknowledge that there is a tomorrow where today's functional capabilities will appear incomplete or, worse, obsolete. Whereas monolithic programs cover all known circumstances, small programs freely admit that software evolves. Software is never finished; it is only released.

Because the world's software is in a constant state of evolution, everyone is on a learning curve. No one can predict with absolute certainty the directions that the software world will take tomorrow. The best that one can do is build software that meets the needs of today with the built-in assumption that it will change in the future. Therefore, instead of spending weeks or months writing design specifications, developers should document an overview of the direction they plan to take and then get on with it.

Building a prototype early is an important step. It helps the designer get an application into the hands of others early so that progress toward the Third System begins sooner instead of later. Prototypes accelerate the rate at which you move into the future. They encourage you to make changes at first when things are still fluid instead of waiting until everything is cast in stone. They show you what will work and-most importantly-what won't.

Building prototypes is much easier if you construct them gradually using small programs that do one thing well. This allows you to add functions as you go along with minimal effort.

Remember that software isn't really built, however. It's grown. As software grows, it will undoubtedly become more valuable as it is ported to new hardware platforms. When new architectures come along, software that is portable can take advantage of them quickly. Therefore, when constructing prototypes, choose portability over efficiency. That which is portable survives. All else quickly becomes obsolete.

Portable data goes hand in hand with portable applications. Store data in flat text files whenever possible. Again, we cannot predict the future, so you cannot know all the places your data might eventually go. Do not be concerned that portable data is not very efficient. New hardware platforms just around the bend will move your data around considerably faster than even the fastest machine can today. Remember, too, that the use of portable data also simplifies the process of getting to the Third System, because the data is readable by humans at all stages of the process.

Portable software finds its way onto hardware platforms that you never dreamed of when you wrote it. In a sense, by writing portable software, you make a contribution to the wealth of software that has been written since the dawn of computing. Bear in mind that for whatever software you give to the world, you are also entitled to receive software as well. As your software travels, it will enhance the abilities of users to carry out their tasks.

The effects of nearly everything you do are compounded. Similarly, there are other programmers whose work is compounding. For you to take advantage of that leverage, shun the NIH syndrome entirely. Create new applications, but do not waste time rewriting what someone else has already written for you. The software that exists in the world today represents a great store of wealth. As you sow seeds in that realm, be sure to harvest that which is ripe for the taking-legally, of course.

To greater enhance software leverage in both directions, employ scripts and other higher-level abstractions whenever possible. They take advantage of the work that others have done for you. Scripts help compound the effects of their work on the world, while enabling you to do more with less effort.

Scripts can be constructed much more easily if you have a collection of small programs to work with. Those programs won't be much good, though, if they require a user to type into them directly. Therefore, avoid CUIs. Instead, think of all programs as filters. Programs do not create data. They only modify it. Make it easy for your programs to be used elsewhere.

Synergy. It's all about synergy.

Is that all? Well, yeah. Most Unix and Linux programs, by themselves, are nothing to write home about. You can always find a better word-processing program or a fancier e-mail program or a prettier view of a directory folder than you'll find on a Unix system. (However, some Linux GUI applications are fairly impressive in their own right.) Try to do something with text that the monolithic word processor wasn't designed to do,^[2] however, and you'll find that Unix is very, very capable.

Proponents of other operating systems claim that a particular operating system can do this or that better than Unix. That may be true in some instances. Even then, Unix (and Linux, as it matures) will likely be able to provide 90 percent of the solution in a fraction of the time it would take to write a new application. Furthermore, Unix can provide this 90-percent solution in virtually all cases, even in those situations where it seemingly would not be able to do so.

But hold on. We're getting ahead of ourselves here. If you want to learn how the Unix philosophy compares with other operating system philosophies, it's time to proceed to the next chapter.

^[2]If you've ever tried to modify a text string in a thousand documents according to dynamically changing business rules, then you understand one limitation of word processors. That takes a really good filter program. On the other hand, if you're trying to create the first version of a document, then a word processor makes a fine tool.