Bookshelf Classic: The Art of UNIX Programming
The Art of UNIX Programming isn't exactly a rule book. Rather, it explores the philosophy and culture behind UNIX -- its strengths, weaknesses, patterns, and associated tools. First published in 2004, it is still relevant today and essential reading for server side developers.
As for rules, in my career writing software, I may have broken two. The first was using threads. I felt a little panic when I read the section titled Threads -- threat or menace?
It was in the early days of threads, and I had already implemented a threaded server. Did I make a mistake? Could I have done a better job with UNIX processes and IPC? Raymond argued that the complexity of threads outweighed their advantages. Performance gains were lost to data locking and synchronization. Abstraction was compromised because you needed to know the internals to prevent deadlock. Threads were not portable.
These were all valid arguments, but today, threads are generally accepted and better understood. Used sparingly, performance gains are real. And a small degree of portability can be had as I wrote and published a simple pthread framework that worked for both Unix and Windows NT. See my post Bookshelf Classic: The Design and Evolution of C++.
The second rule I broke was the rule of repair:
Repair what you can -- but when you must fail, fail noisily and as soon as possible.
The idea was to be able to diagnose a problem easily and quickly, rather than continue running with potentially bad data. But from my time spent at the New York Stock Exchange, I learned failure was never an option. The systems had to stay up, and if something broke, limp toward 4pm, the end of the trading day. And if limping wasn't possible? Failover to a secondary site. And if the data or calculations were suspect? Reconcile the differences throughout the night from logs and data backups.
Prior to joining the NYSE, I used the assert macro in C fairly regularly. For example, I could use it to monitor a divisor and make sure it was never zero. If it somehow was, the assertion would no longer be true, and the macro would abort the program and leave a core dump. Once I was satisfied the program worked correctly, I would turn off the assert macro with the NDEBUG directive.
At the NYSE, I discovered they never used the assert macro because it was dangerous. While the assert macro can be turned off, we were a team of a dozen programmers and responsible for a handful of systems and subsystems. A stray assert macro left on was not outside the realm of possibility. The exchange simply could not stop and fail noisily.
When new programmers joined the team, some asked me why we didn't use the assert macro. I smiled and knew they were conscientious developers.
The characters on the cover of The Art of UNIX Programming are from Ioanna Salajan's Zen Comics. I'm a fan, and they made me like Raymond's book all the more. The panel below would have made a good epilogue to his book. I'll end my post with it, but feel free to read this way:
Disciple: Master, how do I take Linux with me when I travel?
Master: You carry it in your Raspberry Pi!
Comments