handyfloss

Because FLOSS is handy, isn’t it?

Do one thing, do it well. Part I

Posted by isilanes on September 19, 2006

If one reviews the Unix philosophy, it is readily seen a huge different from Windows-land. With Windows, every single task has huge programs, with a colorful graphical interface, menues galore, icons, flashing lights and all functionality incorporated into point-and-click buttons, scrolling bars etc.

All this is advocated in the name of “user friendliness”, that is, making it easy for the user. However, there are two major drawbacks I can see (there can be others). First, in a technical aspect, each and every program is a mammoth. Second, the flexibility and usefulness of these programs actually gets degraded with this policy. I’ll address the first question in this post, the second one in another one.

The “mammoth-ness” of proprietary programs happens because, since they forbid sharing code and information among their developers, they tend (have) to be mostly self-contained. This is highly counterproductive, because instead of sharing resources, they have to be replicated.

Think of the following (silly) example: I have programs A, B and C, all of which can produce red circles. Since their source code is closed, each one of them has to implement a piece of code (library) to make “red circles”. Each time one of the three programs is installed, it carries its own redcircles library, with its bugs and problems (and hard disk and memory resource waste). See Figure 1.

bad

Figure 1: Each program has incorporated a redcircles module.

If these programs were Free, they could all share a common redcircles package, which could be developed by other people. See Figure 2. This would let the developer of each program concentrate on the particular things their program does. And also disk space would not be wasted installing that library for each new program that uses it. A new A, B or C instalation would only need the installer to know that the extra package redcircles has to be also installed (a “required” package), if it already isn’t.

good

Figure 2: All programs share an external redcircles library.

The development of the redcircles package would also be much more efficient, because developing and debugging a single package would be much easier than doing so for each program that uses it.

One Response to “Do one thing, do it well. Part I”

  1. […] Do one thing, do it well. Part II This post is the continuation of a previous one. In that first part I mentioned the “bells and whistles” of most Windows programs being even counterproductive, and getting in the way of the user. Here I will elaborate on that. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: