Ask HN: Nicknames for Computer Science Books?
47 comments
> The C Programming Language, Brian Kernighan and Dennis Ritchie, aka "The White Book"
I've always heard it referred to as "K&R".
I've always heard it referred to as "K&R".
Yeah. I've never heard it called "the white book".
Also there are a couple of other great books which are white eg Kernighan and Pike "The Unix Programming Environment" and "The practise of programming", and all of TCP/IP Illustrated. In fact pretty much any book I can think of published by Addison and Wesley is white.
Also there are a couple of other great books which are white eg Kernighan and Pike "The Unix Programming Environment" and "The practise of programming", and all of TCP/IP Illustrated. In fact pretty much any book I can think of published by Addison and Wesley is white.
Yes, I've also never heard it being given that nickname either at first. I found it at near-random when looking up "White Book" [0] on Wikipedia.
[0]: https://en.m.wikipedia.org/wiki/White_book
[0]: https://en.m.wikipedia.org/wiki/White_book
I have a copy that's a greeny blue color, 6th edition I think?
or, The C Bible
The Red Book also refers to the specification of audio CDs.
Most of these nicknames aren’t widely known. The Dragon Book is probably the most well-known.
Most of these nicknames aren’t widely known. The Dragon Book is probably the most well-known.
Structure and Interpretation of Computer Programs is usually referred to as SICP.
[deleted]
Yes, I've usually heard it as SICP, but apparently Wikipedia[0] cites "The New Hacker's Dictionary" as where it gets its name.
[0]: https://en.m.wikipedia.org/wiki/Structure_and_Interpretation...
[0]: https://en.m.wikipedia.org/wiki/Structure_and_Interpretation...
Knuth "The art of computer programming", aka TAOCP or just "Knuth" but I think that's unfair to his "Concrete Maths" book maybe.
Freidl "Mastering Regular Expressions" aka "The Owl Book"
Freidl "Mastering Regular Expressions" aka "The Owl Book"
TAoCP is "the three volumes" and I know that there are more than three volumes of it.
There's the "Rainbow Series" originally published by the US Department of Defense Computer Security Center:
Orange - DoD Trusted Computer System Evaluation Criteria Green - DoD Password Management Guideline Light Yellow - Guidance for Applying TCSEC in Specific Environments Yellow - Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements Tan - A Guide to Understanding Audit in Trusted Systems Bright Blue - Trusted Product Security Evaluation Program Neon Orange - Discretionary Access Control in Trusted Systems Teal Green - Glossary of Computer Security Terms Red - Trusted Network Interpretation Amber - Configuration Management in Trusted Systems Burgundy - A Guide to Understanding Design Documentation in Trusted Systems Dark Lavender - A Guide to Understanding Trusted Distribution in Trusted Systems Venice Blue - Computer Security Subsystem Interpretation of the TCSEC Aqua - A Guide to Understanding Security Modeling in Trusted Systems Red - Trusted Network Interpretation Environments Guideline (TNI) - Trusted Database Management System Interpretation [3] Pink - RAMP Program Document Pink - RAMP Program Document version 2 Purple - Guidelines for Formal Verification Systems Brown - Guide to Understanding Trusted Facility Management Yellow-Green - Guidelines for Writing Trusted Facility Manuals Light Blue - Identification and Authentication in Trusted Systems Light Blue - Object Reuse in Trusted Systems Blue - Trusted Product Evaluation Questionnaire Silver - Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX System Grey Silver - Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX (R) System Purple - Trusted Database Management System Interpretation of the TCSEC (TDI) Yellow - Trusted Recovery in Trusted Systems Bright Orange - Security Testing and Test Documentation in Trusted Systems Purple - Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements Purple - Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work Purple - Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Description Purple - Procurement of Trusted Systems: How to Evaluate a Bidder's Proposal Document Forest Green - Guide to Understanding Data Remanence in Automated Information Systems. Hot Peach - Writing the Security Features User's Guide for Trusted Systems Turquoise - Information System Security Officer Responsibilities for Automated Information Systems Violet - Assessing Controlled Access Protection Blue - Certification and Accreditation Concepts Light Pink - Covert Channel Analysis of Trusted Systems
Orange - DoD Trusted Computer System Evaluation Criteria Green - DoD Password Management Guideline Light Yellow - Guidance for Applying TCSEC in Specific Environments Yellow - Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements Tan - A Guide to Understanding Audit in Trusted Systems Bright Blue - Trusted Product Security Evaluation Program Neon Orange - Discretionary Access Control in Trusted Systems Teal Green - Glossary of Computer Security Terms Red - Trusted Network Interpretation Amber - Configuration Management in Trusted Systems Burgundy - A Guide to Understanding Design Documentation in Trusted Systems Dark Lavender - A Guide to Understanding Trusted Distribution in Trusted Systems Venice Blue - Computer Security Subsystem Interpretation of the TCSEC Aqua - A Guide to Understanding Security Modeling in Trusted Systems Red - Trusted Network Interpretation Environments Guideline (TNI) - Trusted Database Management System Interpretation [3] Pink - RAMP Program Document Pink - RAMP Program Document version 2 Purple - Guidelines for Formal Verification Systems Brown - Guide to Understanding Trusted Facility Management Yellow-Green - Guidelines for Writing Trusted Facility Manuals Light Blue - Identification and Authentication in Trusted Systems Light Blue - Object Reuse in Trusted Systems Blue - Trusted Product Evaluation Questionnaire Silver - Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX System Grey Silver - Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX (R) System Purple - Trusted Database Management System Interpretation of the TCSEC (TDI) Yellow - Trusted Recovery in Trusted Systems Bright Orange - Security Testing and Test Documentation in Trusted Systems Purple - Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements Purple - Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work Purple - Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Description Purple - Procurement of Trusted Systems: How to Evaluate a Bidder's Proposal Document Forest Green - Guide to Understanding Data Remanence in Automated Information Systems. Hot Peach - Writing the Security Features User's Guide for Trusted Systems Turquoise - Information System Security Officer Responsibilities for Automated Information Systems Violet - Assessing Controlled Access Protection Blue - Certification and Accreditation Concepts Light Pink - Covert Channel Analysis of Trusted Systems
Inside Macintosh, promotional edition: the phone book (because it matched phone books in page size, paper quality and thickness)
Database Management Systems, aka "The Cow Book"
Sendmail - "The Bat Book"
OMG all of the times I had to refer to that book count as amoung the worst times of my unix life. That is the Unix equivalent of a book of black magic that will forever curse your life once you dare to dip into it. Thank goodness I discovered qmail before too much damage was done.
Early in my career I came across an article that ended "If you want to make a lot of money as a consultant you could do a lot worse than rolling up your sleeves and getting a solid understanding of sendmail".
I'm so glad I was too busy to take that advice.
I'm so glad I was too busy to take that advice.
That makes me wonder how many Sendmail installs are still actually around and how much work there would be for a Sendmail guru in 2023.
I don't think there's many. A bunch of the very large sendmail installs that I know about went to qmail pretty much straight away and the ones that remained were mostly people where were concerned about the fact that djb hadn't been at all clear about the terms of the qmail license. When exim was released they pretty much all migrated. It wasn't that long after that when linux distros started shipping with postfix so you're talking an extreme minority of boxes (machines which haven't been upgraded for 20 years, probably don't run linux, probably don't run any very high-traffic mail installation).
The thing is the stuff that used to be total black magic on sendmail (address rewriting, setting routes up etc) is all pretty straightforward on any of those other mail systems, so I'm struggling to see why you would keep a sendmail install around. If someone called me in to help them with their sendmail, pretty much step 0 would be to uninstall sendmail, install a reasonable MTA and go from there.
The thing is the stuff that used to be total black magic on sendmail (address rewriting, setting routes up etc) is all pretty straightforward on any of those other mail systems, so I'm struggling to see why you would keep a sendmail install around. If someone called me in to help them with their sendmail, pretty much step 0 would be to uninstall sendmail, install a reasonable MTA and go from there.
Sendmail seems to be a weird state of limbo. On the one hand their homepage still lists Usenet as the place to go for support and questions. On the other hand their latest release is from June of the year.
I get the feeling that are maybe 5 huge sendmail users still out there somewhere that still pay for support contracts and that is just about enough to pay for someone to turn out regular updates. But beyond that they have reconciled themselves with the fact that they are never getting any new users.
I get the feeling that are maybe 5 huge sendmail users still out there somewhere that still pay for support contracts and that is just about enough to pay for someone to turn out regular updates. But beyond that they have reconciled themselves with the fact that they are never getting any new users.
Usenet never went anywhere. There's very little spam, no banner advertising, and a plethora of greybeards. You should try it :))
Usenet never went anywhere...You should try it :))
I virtually lived on Usenet between roughly 1996-2006 and hung around a bit for a couple more years after that. I can assure you that Usenet definitely went somewhere. Even by 2005 Usenet felt pretty deserted by everybody other than the warez scene.
I will concede however that I haven't logged onto an NNTP server for probably a decade, so perhaps Usenet has had a resurgence without anyone telling me.
I virtually lived on Usenet between roughly 1996-2006 and hung around a bit for a couple more years after that. I can assure you that Usenet definitely went somewhere. Even by 2005 Usenet felt pretty deserted by everybody other than the warez scene.
I will concede however that I haven't logged onto an NNTP server for probably a decade, so perhaps Usenet has had a resurgence without anyone telling me.
There’s an email client called “The Bat!” — I never made the connection.
Here is one:
Introduction to Algorithms - “CLRS”
Introduction to Algorithms - “CLRS”
I've read 9 of these books but had heard of the nicknames for only 2 of those - the Camel book and the Dragon book.
You've got the Camel Book for Perl, there's also the Llama Book, which is "Learning Perl".
Operating Systems Concepts, aka "The Dinosaur Book".
Design Patterns: Elements of Reusable Object-Oriented Software - "The gang of four book".
I've always just herad of that one as GoF or "Gang of Four". (curses be upon them etc etc).
(curses be upon them etc etc)
I always felt they got a bad rap. Most of the actual advice in the actual book was fine. However for some reason they get blamed for a lot of terrible 'advice' they never actually gave, often attributed to them by people who never actually read the book.
I always felt they got a bad rap. Most of the actual advice in the actual book was fine. However for some reason they get blamed for a lot of terrible 'advice' they never actually gave, often attributed to them by people who never actually read the book.
100% agreed. A lot of the patterns may feel heavy these days but I think that the majority have a place and are ingrained in our modern software. Without thinking about it much, we all use factories, singletons (yes, not always for the best), observers, builders, etc.
I think the bad rep comes from over use of these patterns that you see in mid 2000s Java2E "AbstractBeanFactoryBuilderBeanObserver" (hyperbole intended).
I think the bad rep comes from over use of these patterns that you see in mid 2000s Java2E "AbstractBeanFactoryBuilderBeanObserver" (hyperbole intended).
My fave that I ever saw in real production code involved Builder, factory and iterator with at least two of them repeated. So it was something like
AbstractWidgetBuilderFactoryBuilderIteratorFactory
...maybe with Facade thrown in there too somewhere although I could be exaggerating with that.
When you see a classname like that the only rational response is to shrug, look at your watch and wonder how long you still have to work before you can get a strong drink.
Honestly I agree the problem with the GoF is not the content of the book itself but the fact that there is a certain type of personality which is very prevalent in software development (let's call them "pokemon trainers") who when confronted with a classification like that just have to "catch them all" (or in this case get them into every program as often as possible).
As a field guide to spotting and understanding common idioms it's fine. The problem is it's like showing a lexicon of cliches to a creative writing night school class. You know from then on about 90% of the material you read is going to be "It was a dark and stormy night... etc etc".
I just can't really ever forgive them for unleashing that particular demon.
AbstractWidgetBuilderFactoryBuilderIteratorFactory
...maybe with Facade thrown in there too somewhere although I could be exaggerating with that.
When you see a classname like that the only rational response is to shrug, look at your watch and wonder how long you still have to work before you can get a strong drink.
Honestly I agree the problem with the GoF is not the content of the book itself but the fact that there is a certain type of personality which is very prevalent in software development (let's call them "pokemon trainers") who when confronted with a classification like that just have to "catch them all" (or in this case get them into every program as often as possible).
As a field guide to spotting and understanding common idioms it's fine. The problem is it's like showing a lexicon of cliches to a creative writing night school class. You know from then on about 90% of the material you read is going to be "It was a dark and stormy night... etc etc".
I just can't really ever forgive them for unleashing that particular demon.
"Quantum Computation and Quantum Information" by Michael Nielsen and Isaac Chuang -- "Mike and Ike"
Designing Data-Intensive Application, aka “The Boar Book” (kabanchik)
I mostly see it referred to as DDIA and most people know already what the acronyms means. I don’t know if an acronym counts for OP’s naming scheme though.
The consistent pattern I've noticed is that the books gain their nickname (usually) from the cover of the 1st Edition of the Book.
Acronyms can count too!
Acronyms can count too!
It's probably better if you provide a bit more context: "boar" is "kabanchik" in Russian
Phantom Phreak: You got those Crayola books?
Cereal Killer: Yeah, technicolor rainbow. Yeah. Green one.
Joey: What is that? Let me see? What are these?
Crash Override: International UNIX environments.
Cereal Killer: Luscious orange.
Crash Override: Computer security criteria... DoD standards.
Crash Override: The pink-shirt book... guide to IBM PCs. So-called due to the nasty pink shirt the guy wears on the cover.
Crash Override: Devil book, the UNIX bible.
Cereal Killer: What's that?
Crash Override: Dragon book, compiler design.
Cereal Killer: What's that?
Crash Override: The Red book. NSA-trusted networks. Otherwise known as 'The Ugly Red Book That Won't Fit On A Shelf'.
Cereal Killer: Yeah, technicolor rainbow. Yeah. Green one.
Joey: What is that? Let me see? What are these?
Crash Override: International UNIX environments.
Cereal Killer: Luscious orange.
Crash Override: Computer security criteria... DoD standards.
Crash Override: The pink-shirt book... guide to IBM PCs. So-called due to the nasty pink shirt the guy wears on the cover.
Crash Override: Devil book, the UNIX bible.
Cereal Killer: What's that?
Crash Override: Dragon book, compiler design.
Cereal Killer: What's that?
Crash Override: The Red book. NSA-trusted networks. Otherwise known as 'The Ugly Red Book That Won't Fit On A Shelf'.
The 2nd edition of Allen Holub's "Compiler Design in C" too was known as "Red Book".
https://www.abebooks.co.uk/9780131551510/Compiler-Design-Hol...
You mention "The Blue Book" of Smalltalk-80, but they were actually three of them: besides that one, the Green Book, a collection of implementation histories and such, and the Orange Book, a user guide to the original environment. And then came the Purple Book, which was originally a new edition of the Blue Book without part IV which became freely available.
I've never heard the compiler books being referenced as the color of the dragon: they were the Dragon Book and the New Dragon Book -- or, as time passed, the Original Dragon Book and the Dragon Book.
I've never heard the compiler books being referenced as the color of the dragon: they were the Dragon Book and the New Dragon Book -- or, as time passed, the Original Dragon Book and the Dragon Book.
Postscript also has red (reference manual), green (program design) and blue (tutorial and cookbook) books
From that scene in Hackers where they were listing off books with nicknames (ex. Compiler: Principles, Techniques and Tools, aka "The Dragon Book," I ended up being curious about what other books might also have the same treatment. This is the current list I have, scoured from places like Wikipedia, Amazon and other forums, but I wondered if anyone found anything else? (This is just for my own curiosity)
The AWK Programming Language, Alfred Aho, Peter Weinberger, Brian Kernighan, aka "The Gray Book"
The C Programming Language, Brian Kernighan and Dennis Ritchie, aka "The White Book"
Compilers: Principles, Techniques and Tools, aka "The Red/Purple Dragon Book"
Computer Architecture: A Quantitative Approach, aka "The Pillar Book"
The Design and Implementation of the FreeBSD Operating System, aka "The Devil Book"
Foundations of Computer Science, Aho, Alfred and Ullman, Jeffrey, aka "The Turtle Book"
Introduction to Automata Theory, aka "The Cinderella Book"
Lions' Commentary on UNIX, 6th Edition, aka "The Lions Book"
Modern Compiler Implementation in ML, aka "The Tiger Book"
Operating Systems: Three Easy Pieces, aka "The Comet Book"
The OpenGL Programming Guide, aka "The Red Book"
The Peter Norton Programmer's Guide to the IBM PC, aka "The Pink Shirt Book"
Principles of Compiler Design, aka "The Green Dragon Book"
Programming Perl, aka "The Camel Book"
Programming Ruby, aka "The Pickaxe Book"
Smalltalk-80: The Language and its Implementation, aka "The Blue Book"
Structure and Interpretation of Computer Programs, aka "The Wizard Book"
Unix Power Tools, aka "The Unix Book"