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 firstname.lastname@example.org.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Validate an E-Mail Address with PHP, the Right Way
- Technical Support Rep
- Senior Perl Developer
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?