StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The Unix philosophy of pipes and simple tools is for <em>text</em>. It is still relevant, but perhaps not as relevant as it used to be:</p> <ul> <li><p>We are seeing more tools whose output is not designed to be easily parseable by other programs.</p></li> <li><p>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.</p></li> <li><p>We are seeing more <em>interactivity</em>, whereas in Unix pipes information flows in one direction only.</p></li> </ul> <p>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:</p> <ul> <li><p>Remember your own program's output may be another program's input.</p></li> <li><p>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.</p></li> <li><p>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.</p></li> <li><p>Instead of writing a big program, consider writing several small programs connected with existing programs by shell pipelines. For example, a while back the <a href="http://blog.xkcd.com/2009/04/27/a-problem/" rel="noreferrer">xkcd blog</a> had a scary pipeline for finding anagrams in <code>/usr/share/dict/words</code>.</p></li> <li><p>Work up to shell scripts gradually by making your interactive shell one you can also script with. (I use <code>ksh</code> but any POSIX-compatible shell is a reasonable choice.)</p></li> </ul> <p>In conclusion there are really <strong>two highly relevant ways of reusing code</strong>:</p> <ul> <li><p>Write small programs that fit together well when connected by shell pipelines (Unix).</p></li> <li><p>Write small libraries that fit together well when connected by <code>import</code>, <code>#include</code>, <code>load</code>, <code>require</code>, or <code>use</code> (Ruby, C++ STL, <a href="http://www.cs.princeton.edu/software/cii/" rel="noreferrer">C Interfaces and Implementations</a>, and many others).</p></li> </ul> <p>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.</p> <p>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!</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload