Is the Unix Philosophy Falling Out of Favor in the Ruby Community

Is the Unix Philosophy falling out of favor in the Ruby community?

The Unix philosophy of pipes and simple tools is for text. It is still relevant, but perhaps not as relevant as it used to be:

• We are seeing more tools whose output is not designed to be easily parseable by other programs.

• We are seeing much more XML, where there is no particular advantage to piping text through filters, and where regular expressions are a risky gamble.

• We are seeing more interactivity, whereas in Unix pipes information flows in one direction only.

But although the world has changed a little bit, I still agree with Korn's criticism. It is definitely poor design to create large, monolithic programs that cannot interoperate with other programs, no matter what the language. The rules are the same as they have always been:

• Remember your own program's output may be another program's input.

• If your program deals in a single kind of data (e.g., performance of code submitted by students, which is what I've been doing for the last week), make sure to use the same format for both input and output of that data.

• For interoperability with existing Unix tools, inputs and outputs should be ASCII and line-oriented. Many IETF Internet protocols (SMTP, NNTP, HTTP) are sterling examples.

• Instead of writing a big program, consider writing several small programs connected with existing programs by shell pipelines. For example, a while back the xkcd blog had a scary pipeline for finding anagrams in /usr/share/dict/words.

• Work up to shell scripts gradually by making your interactive shell one you can also script with. (I use ksh but any POSIX-compatible shell is a reasonable choice.)

In conclusion there are really two highly relevant ways of reusing code:

• Write small programs that fit together well when connected by shell pipelines (Unix).

• Write small libraries that fit together well when connected by import, #include, load, require, or use (Ruby, C++ STL, C Interfaces and Implementations, and many others).

In the first paradigm, dependency structure is simple (always linear) and therefore easy to understand, but you're more limited in what you can express. In the second paradigm, your dependency structure can be any acyclic graph—lots more expressive power, but that includes the power to create gratuitous complexity.

Both paradigms are still relevant and important; for any particular project, which one you pick has more to do with your clients and your starting point than with any intrinsic merit of the paradigm. And of course they are not mutually exclusive!

Seeking a true tool-chain

G'day,

In my experience, I have found that trying to come up with a "definitive" tool chain can cause problems.

One of the worst is that it tends to force people into the "everything looks like a nail" approach to projects. That is, You've done the work to select the tools you think are suitable and you now have your tool suite.

In my experience, it is very difficult to get people to change their "canonical set" of tools for other projects once that tool set has been selected and annointed as such.

I've been doing this for over twenty years now in a variety of projects that ranged from on-board submarine sonar simulators to air-traffic control display systems to helicopter control systems. Even within the same company, different projects need different tool sets to address the various problems that are going to be encountered.

You might think that once you've selected a tool for a particular purpose then you can re-use that tool for all projects, e.g. your selection of BugZilla for bug tracking. But what if there is no suitable SMTP server available because you've got a distributed team and your mail server is internal, locked down, secure, for example.

I'd suggest that it would be better to establish a suite of possible tools from which you can select your project's tool suite from. For example, adding Trac or FogBuzz as a possible bug tracking mechanism.

A lot of things can affect your choice of tools. Off the top of my head I've got:

• geographical distribution of teams,
• internal lock down, i.e. no public access, of servers e.g. email, source repository, test platform, etc,
• having to interface to some existing system because of a desire to reuse aspects of that system, e.g. previous teams had had VisualSourceSafe inflicted upon them,
• customer insistence on the use of a particular platform,
• the management team for a new project having requirements that differ from the previous management team for regular management type reports,
• etc.

Having a suite of possibilities minimises the effect of "trying to squeeze a square peg into a round hole".

Anyway, you might find that you're able to trim down your suite of possibilities after a while because you can demonstrate a successful approach and so get enough traction within the company for the support of doing things the way you've previously done them.

HTH

Why are most of the biggest open source projects in C?

C is very portable, much more than C++ was 10 years ago.

Also, C is very entrenched in the Unix tradition. Read more in 'The Art of Unix Programming', about Unix and OO in general, and about specific languages on unix (including C and C++).

I am looking for tips for learning Vim or Emacs the smart way

I would advise that checking out both is worth the time because of various reasons already covered by other answers or "Emacs vs vim vs XY" threads.

Still if you would have to pick one of them I'd go with vim because of one thing:

Availability

Vi(m) has the advantage that it is installed (not only available) by default on almost any *nix system. So no matter whether it is your system or someone else's or whether you are allowed to make changes to it or not, your favorite text editor and friend is there waiting for you.

Once you know vi(m) it feels awesome in those situations where you ssh into a machine and need to do something with text (navigating through a file, editing, whatever). You are going to feel like a King. I remember several times when I almost freaked out because nano or pico were not installed and I had to use "this ugly beast vi" which made unpredictable things when I started typing (because I wasn't in insert mode and didn't even know what that was) and when I was happy to have googled that ":wq!" gets me back out of hell. Now I can look back and smile about it.

I have the general feeling that vim
and emacs are not the kind of editor
you learn by "playing with it" though

Vim and Emacs are certainly editors that you "learn by doing".

Of course the question cries for including these highly scientific text editor learning curve graphs =)

Vim might be a bit harder in the beginning because its modal editing can feel quite unfamiliar at first. I think motivation is the key here. The article "Why, oh WHY, do those #?@! nutheads use vi?" explains the advantages quite well I think. In my opinion it really is worth to give it a try even while the learning curve might be steeper than with other editors and it sounds like you bring the necessary motivation.

Back to learning by doing.

Something I wish I would have done the first time:

Check out Vimtutor. It is an interactive tutorial which demonstrates the power of vim by showcasing it's basic commands and how they can be composed. Just type vimtutor in your terminal.

This helped me to really "get it" after trying to learn editing with vim several times in the past. The tutorial eases the learning curve dramatically as it explains the commands and makes you actually perform them so they become a habit. It really makes a difference compared to being frustrated because of feeling handicapped. Using vimtutor you also will see what the benefits of modal editing are and instead of fighting or ignoring it you are going to embrace it because you have experienced the advantages at first hand. I guess it would be pretty difficult to learn that all by oneself. So these 30 minutes are quite worth it.

---

Related Topics