Getcha Program!

Writing good, useful programs that aren't excessively verbose and flabby isn't easy.

Inside and outside ballparks and arenas, there are always people vending programs. Most of the computing we do is the result of other folks' programs and of programs we tweak or rewrite. That's fairly obvious.

However, as I've written before, writing good, useful programs that aren't excessively verbose and flabby isn't easy. Despite a number of really splendid books (Fred Brooks', Knuth's three volumes, Kernighan and Plauger, Kernighan and Pike, Bentley), looking at code shows a lot of untidy, repetitious slovenly work.

I admit to taking old code, snipping a few lines, typing something in, and voil<\#224>--a new driver. Fast and sloppy.

Looking at the 40 million lines of Office 2000, I realize just where the difference between open source and Windows lies—perhaps where the chasm is.

I've pointed out that if you go to the BSD manuals, you can count the number of contributors to the CSRG's (Computer Systems Research Group) efforts over 15 years. It comes to about 600 individuals. In 1998, I heard Bill Gates refer to 2000 programmers in Redmond, WA. There are most likely far more now.

Good programs are written by individuals or small groups. Brian Kernighan told me that AWK was the most difficult thing he'd ever worked on, “because there were three of us.”

Take a bunch of bright programmers, assign them to teams, assign a product to each team, and put them to work. The results will be slightly inferior to what the most feeble-minded member of each team would have produced.

I was surprised when I read The Pragmatic Programmer by Hunt and Thomas (Addison-Wesley, 2000). It's a nicely done volume which is intended to take the programmer from a “requirement” to a real “product”. I must admit I'd always thought of this kind of thing as somewhat comic, but it may be that Hunt and Thomas have good ideas. The book is certainly worth reading.

With all this in mind, I started thinking about the tools I use every day: shells, sed, awk, grep, sort, pipe, etc.

There are several decent books on shell programming, but none covers even most of the available shells (sh, bash, csh, ksh, tcsh and zsh come to mind, and I know there are many more). Robbins' AWK volume is excellent and there was a book on sed a few years ago, but I know of none on grep (nor egrep, which searches using regular expressions). In fact, I know of nothing on zsh. In these cases, we are actually driven to read the on-line man pages.

Just how we get to tools in everyday use is, I think, instructive. I still use troff, for example.

In 1967, L.P. Deutsch and B.W. Lampson took the TECO (an editor) that was running on the PDP-1 at MIT and implemented it on the SDS 940 as QED (= Quick Editor). Ken Thompson took QED and rewrote it for CTSS (compatible time sharing system) on the IBM 7094. He and Dennis Ritchie wrote a version of it for the GE 635 at Bell Labs. Thompson then took that version to create ed in August 1969.

That allowed for editing, but what about printing? J.E. Saltzer had written runoff for CTSS. Bob Morris moved it to the 635, and called it roff. Ritchie rewrote that as rf for the PDP-7, before there was UNIX (it was an evolutionary dead end). At the same time, the summer of 1969, Doug McIlroy rewrote roff in BCPL (Basic Combined Programming Language by Martin Richards, 1966), extending and simplifying it at the same time. It was McIlroy's version that first Joe Ossanna and, after his death, Brian Kernighan turned into the troff we still use.

(By the way, TECO is also the ancestor of Emacs.)

Nearly a decade later, Ted Dolotta created the memorandum (-mm) macros, with a lot of input from John Mashey. Thereafter, Eric Allman wrote the BSD -me macros. I still use them.

No teams. No large groups. Just a lot of good programmers trying to make code into something truly useful. And the open way does that.

Peter H. Salus , the author of A Quarter Century of UNIX and Casting the Net, is an LJ contributing editor. He can be reached at peter@usenix.org.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState