kernighan on tools

What do we want from our tools? First and fore- most is mechanical advantage: the tool must do some task better than people can, augmenting or replacing our own effort. Grep, which inds patterns of text, is the quintessential example of a good tool: it’s dead easy to use, and it searches faster and bet- ter than we can. Grep is actually an improvement on many of its successors. I’ve never igured out how to get Visual Studio or Eclipse to produce a compact list of all the places where a particular string oc- curs throughout a program. I’m sure experts will be happy to teach me, but that’s not much help when the experts are far away or the IDE isn’t installed.

That leads to the second criterion for a good tool: it should be available everywhere. It’s no help if SuperWhatever for Windows offers some won- derful feature but I’m working on Unix. The other direction is better because Unix command-line tools are readily available everywhere. One of the irst things I do on a new Windows machine is in- stall Cygwin so that I can get some work done. The universality of the old faithfuls makes them more useful than more powerful systems that are tied to a speciic environment or that are so big and com- plicated that it just takes too long to get started.

The third criterion for good tools is that they can be used in unexpected ways, the way we use a screwdriver to pry open a paint can and a hammer to close it up again. One of the most compelling advantages of the old Unix collection is that each one does some generic but focused task (search- ing, sorting, counting, comparing) but can be end- lessly combined with others to perform complicated ad hoc operations. The early Unix literature is full of examples of novel shell programs. Of course, the shell itself is a great example of a generic but focused tool: it concentrates on running programs and encapsulating frequent operations in scripts.

http://www.reddit.com/r/programming/comments/7rf9p/sometimes_the_old_ways_are_best_by_brian_kernighan/?sort=old