Slashdot Mirror
What Is the Most Influential Programming Book?
First time accepted submitter AlexDomo writes "If you could go back in time and tell yourself to read a specific book at the beginning of your career as a developer, which book would it be? Since it was first posed back in 2008, this question has now become the second most popular question of all time on StackOverflow. The top 5 results are: Code Complete (2nd Edition), The Pragmatic Programmer: From Journeyman to Master, Structure and Interpretation of Computer Programs, The C Programming Language, and Introduction to Algorithms."
'nuff said
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Everyone knows it: Knuth's "The Art of Computer Programming"
Now get off my lawn!
Bent, folded, spindled, and mutilated.
by k and r
Is Fred Brook's "The Mythical Man-Month".
The correct order should be:
I am sure that The Art of Computer Programming Volume 5 by D.Knuth will be next on the list. I have seriously been counting the years to the estimated 2020.
I only regret that Gerry Sussman hasn't written more books and hasn't recorded more talks. I will buy everything he writes and I will listen to everything he says. Please, Gerry! If you read this then please drop everything you do and just start talking to the camera. I have watched your every talk and lecture that I could possibly find on the Internet many times - from the 1986 lectures at MIT to your lecture on mechanical watches. I seriously believe that everything you say should be recorded for future generations. I don't know anyone else who can talk about anything at all and I listen breathlessly like I was hypnotized. I'm sure that many people here could say the same. Let this be an open letter to Gerald Jay Sussman: Please write more books and please record more lectures for the sake of the future of computer science. And thank you for your outstanding contribution that you have made so far. It is something that has shaped literally generations of passionate enthusiasts of programming. Thank you.
Karma: Positive (probably because of superiour intellect)
John von Neumann: Theory of self-reproducing automata, 1966
There you are, staring at me again.
http://catb.org/~esr/writings/taoup/
...a stunned silence fell upon the hall.
The C Programming Language by Kernighan and Ritchie (popularly known as "K&R") is certainly, objectively (puns intended), and probably demonstrably, the most influential programming book. It was a strong, probably primary, influence on every one of the titles suggested in this story. Indeed, it is something like the "ur-text" of modern programming - the vast majority of all programming, since it was first published in 1978. It has influenced programs, programmers and programming books. The influence dependency tree of programming books revolves around K&R.
I say this despite (or perhaps as demonstrated by) the K&R block brace style, which I abhor. It saves a line to destroy column coherence. And despite popularizing the unitary "var++" (eg. in for() loops), rather than the semantically more consistent "++var". And a hundred other quirks Kernighan and Ritchie infected into programming (and programming books, and thereby programmers). The persistence of which is just part of the ample proof of K&R's paramount influence.
--
make install -not war
...so you can spot the BS and hysterical religion when some idiot consultant comes up with their new XXX driven development or Agile methodology, or tries to replace on perfectly good framework, set of design patterns or tools with a new one that promises to be the best thing since sliced bread.
But seriously I think it's important to start kids young. My first books were on Apple IIe BASIC. In those days BASIC was what a lot of kids had access to. I saw LOGO later. I wouldn't change that. I'd change the books and systems I tried to use as a teenager and young adult though - MFC and Windows coding was such a waste of time given where my career went. And I never got far.
Agree with the previous AC about Mythical Man Month. Love the classic idea of a manager who needs a baby to meet a 1 month deadline throwing 9 women at the problem instead of one woman for 9 months. But I think you can get the gist without reading a whole book about it.
K&R is iconic, but not a good beginner's book at all, and while it does cover some things in great depth it does leave plenty out and is well dated now. Worth reading, but not first. It's good for understanding how the guts of the machine work but as C has been in decline for some time some of today's new coders will likely never use it.
I've never actually read Code Complete, but it sounds like a good introduction to a lot of ideas if you've not done a degree.
These posts express my own personal views, not those of my employer
Dianetics.
I have mod points and I am not afraid to use them.
I never read any programming book that has helped me significantly. But I remember copying code from magazines on a TI-99 before I knew how to do multiplication. I just copied the code one line at a time, and it either ran or didn't. The best thing I could do was print rockets. I didn't understand anything until I was 12 and got the IF-THEN statement. Once I had that, I was able to write branching games similar to my Choose your Own Adventure Books. After that the world was wide open.
God spoke to me
In terms of success, people skills are more useful than programming skills.
Words to men, as air to birds.
The only CS book where 99% of the people touting it have never read it!
It may seem odd but I would say Godel Escher Bach. I can't really think of any other book that I would consider worth while reading at the start of my carear. (I am actually thinking of before my college education.)
No, not very influential outside the Mac community, not all that influential within it. But the as posed here in Slashdot, "if you could go back in time," this is the one, and not because of what it had to say about the Mac, but because it is the only book I've ever read that truly accepts the idea of debugging. Every other book carries the implied notion that you should concentrate on writing bug-free software, and that a good programmer really ought to be able to do it.
About half of the book was devoted to debugging, and it is my personal surmise that the book was originally entitled "How to Debug Macintosh Software" and that the publishers made him change it. Some might charge that the way Mac software was at the time--A5 worlds, very little RAM to spare, and somewhat finicky memory management--writing Mac software intrinsically required more debugging than other environments. It doesn't matter.
What matters was that this is the only book I read that honestly and truly embraced debugging as a fundamental and legitimate part of the software development process.
"How to Do Nothing," kids activities, back in print!
It's nice to see the almost complete absence of any titles reflecting current "flavor of the month" development techniques. About the closest it gets is "Design Patterns", which I've not got the highest opinion of (for reasons I'll explain in a footnote) but which at least codified some common best practices in a way that they could be taught, rather than learned by trial and error.
Always been a bit bemused by "Code Complete". Read it (well, the first edition), enjoyed it, and thought it contained a lot of good stuff, but at the time I was perplexed by it being a Microsoft Press book. Seemed kinda like the Pope penning the definitive case for atheism.
Somewhat comforted to see The Dragon Book in there, even if it is in its newer edition. Think I've still got that one around. That, and the Hennessy and Patterson book "Computer Architecture: A Quantitative Approach". My edition's horribly out of date, but so am I..
(*) Big problem with design patterns is that there's a tendency to take them as Holy Scripture of some sort, and/or to unnecessarily squeeze algorithms into a given design pattern. However, the problem there doesn't really lie with the book, but with the reader (or the teacher of the course, I guess). "Design Patterns" strikes me as something that should be read after a decent level of programming ability has been reached and not before - there's a level of expertise required to know when using a pattern that'll make maintenance of the software a joy for all who touch the code, and when to just wing it. Too many people immediately jump in and conclude that they must use a Visitor pattern on each Decorator, except where there's a Mediator involved, in which case it's necessary to employ the Churning Curds and The Knot Of Fame, before finally employing The Clinging Creeper to either a Flyweight object for the Proxy, or an Abstract Singleton. Then they code it, and you end up with an exponential number of classes, several mutually inclusive interfaces, and a system so flexible that you have to embed a dedicated parser to make any use of it beyond initiating a single object.
Honestly, those are terrible books. If nothing else the signal-to-noise ratio is extremely disproportionate. I mean there are nuggets of good information in the books, but a 1100+ page language tutorial is unnecessary. It would be a stretch to call the series programming books -- let alone "influential" programming books.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
The biggest problem with MMM is that software developers and architects are the only people who read it. Managers, especially "non technical" project managers have never heard of it, and won't bother to read it and they are the ones who would benefit from it the most.
No ASM programming?
Enjoy being useless when you need to work at the bare-metal level.
Also, enjoy being dog-ass slow and having boated code.
For a perfect example of why ASM rocks, see MenuetOS.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Starting Forth by Leo Brodie -- especially the "under the hood" chapter. Runner-up for me is the PostScript Language Tutorial and Cookbook. These books gave me whole news way of thinking about programming, which doesn't happen very often.
And yet, for others of us, it was our starting book back in the 80's.
More realistically I think for my generation in the UK, this was our starting book. But in mitigation, expecting six year olds to read Knuth might have been a bit much!
Agreed, a little known book for C++ from the ground up. Is an extremely well organized book "Starting Out With C++" by Gaddis. Dietel and Dietel C++ is manageable but its a thicket of information that makes it tough for some (I have gone through Deitel C++ and Dietel Java). There are a thousand books on C++ and probably a thousand squared number of paths to learning C++. Whatever your C++ journey, have fun!
The C classic is wonderful The C Programming Language Brian Kernighan and Dennis Ritchie.
Knuth is computer philosophy. Makes your soul shine. Treat it like philosophy, read it at leisure and think hard about every word on every page.
After years of programming I have to say the most influential book for me by far is "The Design of Everyday Things" by Donald Norman. In the end, you're designing a tool for someone... whether it's a end user or an api. The days of control-alt-delete are over... or at least they should be. Thinking about the user interface (whether it's mechanical, gui, api,or sdk) should not be something the programmer slaps on after the functionality is completed.
"Classic: a book which people praise, but don't read." - Mark Twain
I guess he meant it with regards to classic literature. It seems extendable to classics in other art fields, and classics in technical fields too I suppose
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
For anyone doing OS and BIOS level programming on the PC in the DOS days (and not writing games), the "Peter Norton Programmer's Guide to the IBM PC & PS/2" was a great book for understanding BIOS and DOS calls.
Peter Norton was one of the visionaries of the IBM PC software days and the DOS versions of the Norton Utilities were a godsend for things like repairing a damaged floppy disk or doing low-level hex editing.
It wasnt until Norton sold his company to Symantec that the Norton product line became the piece of junk it is today.
http://www.amazon.com/Dating-Design-Patterns-Solveig-Haugland/dp/0974312002/ref=sr_1_1?ie=UTF8&qid=1315193378&sr=8-1
_Dating_ Design Patterns.
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
Great book on design patterns, Design Patterns: Elements of Reusable Object-Oriented Software.
That book may be considered a classic but is one of the poorest presentations of material I've ever seen to recommend to a beginner. It works better as a reference but even then thinking in those terms has a tendency to make you over engineer every damn thing unless you actively apply the KISS principle. A lot of the patterns covered are best shown to newbies with concrete examples rather than in generic theoretical form.
These posts express my own personal views, not those of my employer
You're totally wrong about goto statements.
Bullshit. I have a PhD in computer science, and I wouldn't recommend TAOCP to anyone. Sure, it covers the material, but it covers it amazingly badly. Knuth manages to take simple concepts and make them incomprehensible. Read pretty much any textbook on theoretical computer science other than TAOCP and you'll learn a lot more.
I am TheRaven on Soylent News
The Gang of Four's book may be the most influential programming book, but it's probably done more harm than good. The patterns it describes fall into two categories: so painfully obvious that any programmer with more than a couple of months of experience should have invented them independently, or so obscure that you'll probably never find a real use for them. Unfortunately, once people have read it, they end up designing insanely overcomplicated systems that abuse patterns to death.
If you really want to understand design patterns, read some of Christopher Alexander's work, not the third-rate derivatives.
I am TheRaven on Soylent News
To be fair, I have turned to Knuth for reference on a few occasions when I needed a very detailed explanation of an algorithm and the background and reasoning behind that algorithm. The way I see it, TAOCP is something that should be used as a reference, for those cases where you need a lot of detail.
Palm trees and 8
I agree that most seasoned programmers have already used most of the design patterns themselves. The value of the book is to give names to those patterns, to aid in communicating design and intent within a team of programmers. The very act of labeling gives these things a concrete boundary instead of just nebulous knowledge mixed in inside programmers' heads. The boundaries established also allow analyzing the scope and robustness of the patterns in isolation.