I'm James Hague, a recovering programmer who has been designing video games since the 1980s. This is Why You Spent All that Time Learning to Program and Organizational Skills Beat Algorithmic Wizardry are good places to start.
Where are the comments?
Free Your Technical Aesthetic from the 1970s
In the early 1990s, I used Unix professionally for a few years. It wasn't the official Unix, nor was it Linux, but Sun's variant called SunOS. By "used" I mean I wrote commercial, embedded software entirely in a Unix environment. I edited 10,000+ line files in vi. Not vim. The original "one file loaded at a time" vi.
At the time, Unix felt clunky and old. I spent a lot of time in a library room down the hall, going through the shelves of manuals. It took me a long time to discover the
umask command for changing the default file permissions and to understand the difference between
.bash_profile and how to use
By way of comparison, on my home PC I used a third-party command shell called 4DOS (later 4NT, and it's still available for Windows 7 as TCC LE). It had a wonderful command line history mechanism: type part of a command, then press up-arrow. The bash bang-notation felt like some weird mainframe relic. 4DOS had a built-in, full-screen text file viewer. The Unix equivalent was the minimalist
less command. 4DOS help was colorful and pretty and hyperlinked. Documentation paged through as
man pages was several steps backward.
The Unix system nailed the core tech that consumer-level computers were way behind on: stability and responsiveness in a networked, multitasking environment. It was ugly, but reliable.
In 2006, I got back into using Unix again (aside from some day-job stuff with Linux ten years ago) in the guise of OS X on a MacBook. The
umask command is still there. Ditto for
.bash_profile and all the odd command line switches for
tar and the clunky bang-notation for history. I'm torn between wonderment that all those same quirks and design choices still live on...and shocked incredulity that all those same quirks and design choices live on.
Enough time has passed since the silly days of crazed Linux advocacy that I'm comfortable pointing out the three reasons Unix makes sense:
1. It works.
2. It's reliable.
3. It stays constant.
But don't--do not--ever, make the mistake of those benefits being a reason to use Unix as a basis for your technical or design aesthetic. Yes, there are some textbook cases where pipelining commands together is impressive, but that's a minor point. Yes, having a small tool for a specific job sometimes works, but it just as often doesn't. ("Those days are dead and gone and the eulogy was delivered by Perl," Rob Pike, 2004.) Use Unix-like systems because of the three benefits above, and simultaneously realize that it's a crusty old system from a bygone era. If you put it up on a pedestal as a thing of beauty, you lose all hope of breaking away from a sadly outdated programmer aesthetic.
(If you liked this, you might like My Road to Erlang.)