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."

Comments

Deitel & Deitel

[bigjocker]

'nuff said

Re:Deitel & Deitel

[Jeremiah Cornelius]

Charles Petzold.

Programming Windows, First Edition
http://www.charlespetzold.com/pw5/ProgWinEditions.html

Sad. But TRUE!

Re:Deitel & Deitel

[lsolano]

Absolutely.

I'm not a programmer full time (not even part time :) ) but once, many years ago, I had to learn by myself how to program C, and I've got "C: How to program" and for me, it is the best book on programming I've ever read.

They way it teaches it just excellent. I do not mean the way it teaches C, I mean, the way it teaches how to program, what a programming language is, etc.

Re:Deitel & Deitel

[Pseudonym]

The first edition predates Win95 by... a lot. I remember reading it in 1988.

Petzold's problem is also its strength: It teaches the Windows API extremely well, but requires that you already be a good programmer with good taste, otherwise all the API isn't all you'll learn. You'll also learn a lot of bad habits.

Bah! Pretenders!

[leftover]

Everyone knows it: Knuth's "The Art of Computer Programming"

Now get off my lawn!

The C programming language

[drodal]

by  k and r

Re:The C programming language

[swinefc]

First edition, K&R. None of this ANSI standard stuff.

http://en.wikipedia.org/wiki/The_C_Programming_Language

Re:The C programming language

[mikewas]

Some of us keep both the Old Testament & the New Testament on our desks

Re:The C programming language

[sbraab]

I prefer to think of them as the King James and New International Version. Sometimes, though, you have to go back to the original TeX manuscripts and do your own rendering.

The One Book All Coders Should Read

[SpinningAround]

Is Fred Brook's "The Mythical Man-Month".

Re:The One Book All Coders Should Read

[sizzzzlerz]

I thought about this one as well but I decided not to post because TMMM is really about program management, not programming, per se. Still, it is a fabulous book that every engineer and manager should read, study, and practice.

Re:The One Book All Coders Should Read

[digitig]

That's the one I was going to suggest. Programming is about more than coding, and TMMM covers a lot of the stuff that a lot of programmers seem to lack.

Gang of Four

[intellitech]

Great book on design patterns, Design Patterns: Elements of Reusable Object-Oriented Software.

There's also this ruby-flavored version, and since I've been on a ruby kick for quite some time now, I devoured it within a couple of days. It's called Design Patterns in Ruby.

Hope somebody hasn't heard of these, they'll get a damn good read (or, two, if you take on both). Although for the majority of Slashdot, I'd be really surprised if this recommendation doesn't come from a million people. The original GoF made it around quite a bit.

Re:Gang of Four

[syousef]

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.

Re:Gang of Four

[TheRaven64]

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.

Re:Gang of Four

[De Lemming]

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.

That's why I always recommend Head First Design Patterns (O'Reilly) to everyone. It has a great practical approach to teaching patterns, e.g. by starting with real world bad code, showing what's wrong with it, and then refactoring to a design pattern.

Re:Gang of Four

[White Flame]

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.

Software Tools by Kernighan and Plauger, 1976

[Doctor-R]

This book shows how to build software tools to bootstrap from a crummy environment (FORTRAN on IBM 370) to a much more productive environment. Stop whining, get coding, build tools. Expounds on tool pipelines based on Unix pipes. .

The correct order

[Mensa Babe]

The correct order should be:

1. Structure and Interpretation of Computer Programs by H.Abelson and G.Sussman with J.Sussman
2. Structure and Interpretation of Classical Mechanics (sic!) by G.Sussman and J.Wisdom with M.Mayer
3. Operating Systems Design and Implementation by A.Tanenbaum and A.Woodhull
4. Modern Operating Systems by A.Tanenbaum
5. The Art of Computer Programming Volume 1 by D.Knuth
6. The Art of Computer Programming Volume 2 by D.Knuth
7. The Art of Computer Programming Volume 3 by D.Knuth
8. The Art of Computer Programming Volume 4 by D.Knuth

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.

Re:The correct order

[SuperKendall]

It's a good list but I feel like you shouldn't have operating system design over TAOCP, most programmers are operating at a level of abstraction these days over the base operating system in a way that makes that knowledge less valuable.

Re:The correct order

[fermion]

This list is large on theory and short on trade craft, like the list presented in the article is short on theory and not so long on trade craft.

For instance, the Pragmatic Programmer has some interesting topic, and has been promoted to death, but I found The Practice of Programming to be much more instructive. It might be because of Brian Kernighan, or my belief that Addison-Wesley puts out the most rigorous computer books(O'Reilly is quick and dirty), but I found it a much more compelling read.

Code Complete is a very important book in terms of trade craft, and was written at a time when MS was writing credible code. I, However, consider it part of a trilogy that includes Writing Solid Code. I can't remember the third MS book, but do recall the three giving me a very good idea of current programming principles when I got back into programming several years ago.

The C book is a good example of how to document a language and how to write a simple and effective language. However, the C++ book provides much more theory and design using a modern language. If one's interest is deep language, The C++ Programming Language: Special Edition is a hard book to beat.

For theory, a book that I seldom see recommended, but is deeply important as at least some programming is procedural, is Composite/Structural programming. Most mistakes still seem to come from the lack of segration between data and rules.

Also, given how basic TCP/IP, I am often concerned that book like TCP/IP Illustrated is not more widely cited. While other books may provide an overview, this is one books that has allowed me to debug deep TCP/IP issues.

As an aside, efficient OO programming dictates the use of Design Patterns. While many would consider the Gamma book the standard, design patterns are based on the pattern language for architecture. A Pattern Language by Alexander is an interesting tome well worth the read.

Most influential on me...

[Maljin Jolt]

John von Neumann: Theory of self-reproducing automata, 1966

Learning Perl

[ltcmus]

Great starter book for non-cs types.

The Art of Unix Programming

[egork]

http://catb.org/~esr/writings/taoup/

Re:The Art of Unix Programming

[TheRaven64]

Seconded. Great book. Quite a few of the things that it complains about are now obsolete (for example, the main complaint levelled at X11 is due to vendors supporting different sets of extensions, but this is largely irrelevant now that everyone uses the same X server without large sets of proprietary patches). Many of the other points are spot on. The ioctl() system call should have been the point at which they saw that the file is the wrong abstraction for most things.

Code Complete

[DoofusOfDeath]

This went a long way towards making me better at programming larger, non-academic-assignment programs.

K&R C

[Doc Ruby]

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.

Re:K&R C

[icebraining]

And why semicolons instead of periods?

I'd rather have neither; Python and Go got it right.

Re:K&R C

[imp]

for (i = 0; i++; i 10)

is semantically the same as

for (i = 0; ++i; i 10)

period.

This has what K&R has brought us. Of course, the reason for this preference is that PDP-11 had postincrement addressing mode as well as pre-decrement. So you'll see more --foo than foo-- in old time code. For simple ints like the above, of course it doesn't matter one wit. But for looks like:

while (*src++ = *dst++) ;

you get much better code on a pdp-11 than the nearly similar:

*src = *dst;
while (*++src = *++dst);

because the former's data movement is just two instructions, while the latter can be up to 6. Then again, this loop kinda disproves the usefulness of the ++foo that the parent to this reply expounded. There's really nothing more "logical" about it. it isn't until you find yourself in C++ land that you might think that (since operator ++ overloading is a lot easier with preincrement rather than post increment).

So there you have it. The main reason for foo++'s prevalence in K&R is due to the historical accidents of PDP-11 addressing modes and stack growing direction.

Re:K&R C

[mfnickster]

By judging the rest of his post on its merit. ("while (*src++ = *dst++) ;" is also missing an "=").

See, this is why C sucks and is wonderful at the same time.

There is no '=' missing. The assignment belongs in the conditional, and actually is the reason why it works.

In C, the value of an assignment statement is the value being assigned, so this expression copies the value at one location to another location (per the pointers src and dest) and increments both pointers. If the value is null (indicating the end of a string) the expression evaluates as false and the loop terminates.

The fact that you missed this, or perhaps didn't learn it while learning C, is an argument against this confusing kind of usage. Yes, it's efficient, but is it worth the trouble?

Re:K&R C

[AuMatar]

I'd like the multiple weeks of my life back that python has cost me because of their whitespace as braces style when coworkers decided to mix tabs and spaces. Python's decision would be fine *if* they had decided that we must use exactly 1 tab, or exactly 4 spaces, or any other choice. Allowing arbitrary amounts/types of whitespace along with giving it semantic meaning was the biggest mistake in the history of programming languages, and renders the result unusable.

Re:K&R C

[mooingyak]

"while (*src++ = *dst++) ;" is also missing an "=".

It has exactly as many "=" as it needs.

It's a way to code strcpy().

Re:K&R C

[kayumi]

Oh my god, I will go and hide for the rest of the month. I blame it all on python, lack of sleep and Fukushima. I have not used C for a year or two and now this happens. Damn. I must have caught this thinking-in-python disease.

Re:K&R C

[Doc Ruby]

Use your imagination. You know what columns are, and what coherence is. And what K&R does to columns when you use braces their way, saving a line.

Or are you a compiler?

Re:K&R C

[m50d]

As of v3 you can't mix tabs and spaces in the same file, which removes the "invisible bug" problem. Allowing an arbitrary number of spaces to indent a block is arguably too much flexibility, but since the indentation of each block has to be consistent I've never seen it render the code unclear.

Re:K&R C

[Rogerborg]

Oh, and don't forget the abomination:

int *foo;

...and its mutant offspring...

int foo, *bar;

IIRC, K later recanted and said that permissiveness (allowing "pointer to" to shack up with the symbol rather than type) was the biggest single mistake they made in the C syntax.

Re:K&R C

[icebraining]

Again, even in 2.X it was a matter of running python with -t or -tt. You just needed to RTFM.

Re:K&R C

[Doc Ruby]

I know better than K&R (did). Of course, I have the benefit of over 30 years programming after their book was published, starting only a year prior; they had only a decade or less experience when they published, among a vastly smaller society of peers to argue with.

I won't like any language that requires a text editor more complex than notepad to generate readable code. Certainly not one that requires a post-processing indenter.

Demon Haunted World, Carl Sagan

[syousef]

...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.

Z-80 Assembly manual

[msobkow]

The most influential programming book I owned was the first one I owned: The Z-80 Assembly manual. That got me started on real programming. The TRS-80 may not have been a great machine compared to what we have now, but it was a great bare-bones-metal learning tool.

It's one not on the list

[LynnwoodRooster]

It's "I, Robot" from Isaac Asimov. How many read that book early on and thought "I can do better than those three rules"...

Re:It's one not on the list

[Zironic]

Hmm? Almost all the stories are about stupid stuff that happens because some genius thought they would be better off if they modified the laws.

IBM System/360 Principles of Operation

[jacobsm]

The book that started it all.

the Most Influential Programming Book?

[MrShaggy]

Dianetics.

Re:the Most Influential Programming Book?

[ed1park]

How about the bible? *ducks* :)

For me it was: Choose your Own Adventure books

[GoodNewsJimDotCom]

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.

How To Win Friends And Influence People - Carnagie

[2TecTom]

In terms of success, people skills are more useful than programming skills.

Re:Bah! Pretenders!

[Anonymous Coward]

The only CS book where 99% of the people touting it have never read it!

Re:Bah! Pretenders!

[Anonymous Coward]

TAOCP is only useful for college students who want to look smart in the eyes of their clueless classmates.

In reality, it's terrible from a didactic standpoint. MIX is an impractical and verbose language, and an overall horrible way to explain algorithms to any audience. TAOCP is only interesting for the exercises, which most people will ignore for being too difficult to be solved during a casual read.

The only reason this book makes Top N lists is because people are intimidated by it, and peer pressure prevents them from treating it like the mess that it is.

Design Patterns

[craftycoder]

For me it is the Design Patterns by the so-called Gang of Four.
http://en.wikipedia.org/wiki/Design_Patterns

It may seem odd

[Arran4]

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.)

Knaster, "How to Write Macintosh Software"

[dpbsmith]

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.

Pleasantly Free of Trendy Process Related Titles

[awrc]

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.

No

[edalytical]

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.

Re:C++ version

[kulnor]

I would rather go with a classic here: The C Programming Language Brian Kernighan and Dennis Ritchie http://en.wikipedia.org/wiki/The_C_Programming_Language *K

Javascript for dummies

[Osgeld]

Apparently its the only book sold

Re:It is about programming

[JeremyMorgan]

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 Assembler?

[Khyber]

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.

Re:No Assembler?

[uop]

Assembly fan here.
Specifically, the Graphics Programming Black Book (Michael Abrash) was extremely influential in my case. Some of the self modifying code examples were true genius.

Starting Forth

[nkuitse]

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.

Norton, Duntemann, & Eckel

[RandCraw]

The books that first grounded me in the hard and software of computing were "Peter Norton's Guide to Programming the IBM PC", Jeff Duntemann's "Complete Turbo Pascal" and , and Bruce Eckel's "Using C++" and "Thinking in C++".

Each of these books are paragons of clear writing and thought, conveying much more than the rudiments of their topic -- the years of experience and practical perspective of each of the authors.

I began my software career reading these books (ca. 1985), eventually completing a formal MS in CS. Yet sometimes your greatest influences arise not from ivory towers but from the school of hard knocks.

The problem

[slapout]

The problem with choosing some of these books is that they won't make as much sense until you've had some programming experience.

BBC Micro User Guide

[williamhb]

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!

Re:No Indeed good sir

[JavaManJim]

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.

On a tangent but most important

[Serendip7]

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.

Algorithms+DataStructures=Programs; Wirth

[martyb]

Algorithms + Data Structures = Programs by Niklaus Wirth

I read this book back in the late 1970's. (I was still in High School where we had time-shared access to a PDP/11-70 running RSTS/E. Programming was in Basic-Plus. To put this in perspective, this was the same time frame as the TRS-80, TI 99/4A, and Commodore PET!) Our SysOp at SPHS saw my voracious appetite for all things computing and STRONGLY encouraged me to get and read this book. (Thanks Mike!) But enough with the background!

This book made an indelible impression on me. It introduced different approaches to tackle problems (algorithms) and different ways of organizing the information I had available (data structures). But, most importantly, it encouraged me to iterate between the Data and the Code to find a reasonably optimal synthesis of the two.

Prior to this, my experience with data structures had been limited to "scalars" (integers, floating point, and some character strings) and multi-dimensional arrays. It was a real eye-opener to be exposed to structured records as well as linked lists and trees!

Similarly, my coding experience was limited to combinations of the usual control structures of sequences, conditional statements, looping, and subroutines/functions. Did I ever struggle trying to understand recursion!

Then, toss in a generous helping of structured programming and step-wise refinement. This single work completely transformed my perspective on programming, its challenges, and its promises... I was hooked for good!

Amazon Link. Prentice-Hall 1975; ISBN 0-13-022418-9; 366 pages, 102 figures.

I later had the good fortune to read a number of the other books recommended here, K&R, TAOCP, Mythical Man Month, and I'd highly recommend those, as well. Nevertheless, I read Wirth's A+DS=P first, and it's made a world of difference in my life.

Re:Bah! Pretenders!

[KingAlanI]

"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

One underrated book...

[jonwil]

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.

Also in this regard...

[KingAlanI]

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.

Re:Bah! Pretenders!

[butalearner]

This does not make *any* sense, unless Knuth was trying to troll generations of students who were too insecure to admit they couldn't understand MIX.

So Knuth is kinda like the L. Ron Hubbard of Computer Science?

Re:Bah! Pretenders!

[Dails]

Ever looked at the assembly produced by a for loop? It uses jmp calls. jmp is the exact same thing as goto. If your professor is telling you that gotos are bad, they're either not very good professor or you're in a 100 level CS course where they don't want to confuse you too much.

Re:Bah! Pretenders!

[bonch]

You're totally wrong about goto statements.

Re:Bah! Pretenders!

[TheRaven64]

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.

Books?

[ledow]

I'm only a casual programmer - I've been doing it for the last 20+ years, I've used it in my career, there are schools still running on my code, and I've written any tool that I needed and couldn't find a decent utility for elsewhere. I don't consider it a serious pursuit for myself and write more games and one-off utilities than I do serious projects.

Listed in order, this is every physical "programming" book I've ever read in those 20+ years:

- ZX Spectrum BASIC manual
- INPUT series (from Marshal Cavendish)
- O'Reilly Java in a Nutshell (probably 2nd/3rd edition, I can't remember)
- O'Reilly Physics for Game Developers
- OpenGL Superbible, 4th edition

The first one got me programming all on its own. The second helped immensely and allowed me to get a rough grasp of things that I couldn't quite understand at that age. It also taught me how to break the problems down and generate code rather than just showing me how their code worked.

After those, I was writing games, utilities, network management tools, I removed the CD protection on my copies of Desert Strike using only MS DOS debug (but never distributed the code which was already out there anyway), contributing to open-source projects (everything from games to single-floppy-linux-distros), and basically able to write anything I needed given enough time and enthusiasm. Hell, I taught my own sixth-form (Year 12/13) classmates for two years because I understood programming better than my teachers.

Then, YEARS later, I read the Java book (because I was starting uni and they made a Java course compulsory and I just wanted a quick reference and that book was cheap - I never attended those programming lectures for two years after I'd got the hang of Java syntax in the first week, and passed them with flying colours - that was my first introduction to OO, even).

Again, YEARS after graduating, I read the physics one and didn't do a damn thing about it because I thought it was horrible, Windows- and even compiler-specific and physics was the only subject that I ever really "failed" (i.e. did terribly on, or actually failed) despite everyone telling me that I'd be good at it because I was good at maths. I binned it after a single reading - I knew exactly what it was trying to teach me but in terms of actually walking away knowing something, it was worthless.

And this year I read the OpenGL book because I thought I'd finally see what all the fuss was about (gaming for me is 2D - it's what I was brought up on, it's easier to program and do the art, and it's much less demanding and never really goes out of fashion - and I wanted to use OpenGL acceleration on my 2D games). That, admittedly, is one of the best "programming" books that I've ever read except they have a tendency to butcher previous versions for each iteration in order to keep it "up-to-date".

Now, I have a Maths & CS degree, I've run my own business in and worked in IT since graduating. I'm responsible for school systems and quite a bit of my own code makes that possible.

I've been exposed to Knuth, etc. but if you asked me what book I've give my younger-self, it would have to be the first two and the OpenGL one.

To me, learning programming isn't about the memorisation of coroutine techniques, but about the ability to formulate a problem into code and have the computer solve it. I don't think books can really teach that and I only use books, references and guides in order to learn the *syntax* of a language, or to learn about a particular technique (e.g. the matrix-operations that OpenGL performs are a wonderful insight into how something quite removed (conceptually) from computing can be formulated in a way which fits into a computing technique really well).

Until you actually sit and do it on a computer for a project you need yourself, you're just nodding along going "This is cool" with no knowledge of how practical is it to apply to a project (I've seen no end of people start a ten-line utility by writing flow-charts and a

I would never have read books like that...

[phozz bare]

The biggest problem with the question posed by this article is that even if I had a time machine and could meet myself when I started programming, I'd have a hard time selling "The C Programming Language" to my 5 year old self. Seriously, most of us started programming as kids, and we did it for fun. Reading long books is no fun, and CS theory is seriously no fun at all.

Personally I started with "Inside ATARI Basic" by Bill Carris. It was a very fun read and was definitely aimed at kids and beginner adults. Unfortunately my walk through the book came to a screeching halt when trying to understand what FOR and NEXT did. The book explained that FOR and NEXT are like the two parts of an Oreo cookie, and the code in between them was like the cream in the middle. Mmmmm, Oreo cookies. Yum! But what does it actually do? No explanation at all. At that point I gave up on BASIC and moved to LOGO. It was only 5 years later that it was explained to me that FOR-NEXT was a loop structure, which is what broke the barriers for me and allowed me to move from BASIC to Assembly, then (much later on) on to Java, C and C++.

But I digress. My main point here is that nobody starts programming by reading Knuth cover to cover and then digging in, and that most of the "must read" and influential books on the subject make no sense to the beginner.

3 Books ...

[angel'o'sphere]

I guess I learned the principles of programming from "Algorithms and Data Structures" by Niklaus Wirth.

I read "The Design and Evolution of C++" by Bjarne Stroustrup later, and buy understanding his design constraints and decissions he made I could forgive him for lot of the shit that I considerd a cluster fuck up in C++.

Most influenced I perhaps was by "Design Patterns. Elements of Reusable Object-Oriented Software" Erich Gamma, Richard Helm, Ralph E. Johnson and John Matthew Vlissides (+ 2005, R.I.P.)

I found it amazing to "name" larger "structures" in programming / design and/or architecture. I basically knew all those patterns because I was involved in oo framework development and research. But having some guys just grabbing them out of existing code, displaying them and giving them a name was very stunning for me.

Also the original edition of that book was excellent printed with sidenotes on the margines and graphical overviews in the inside of the book covers.

I guess I have roughly 50 computer science books ... which reminds me to get: "XUnit Test Patterns" by Gerard Meszaros, see: http://xunitpatterns.com/ This is an excellent book about Software Testing.

Re:Bah! Pretenders!

[angel'o'sphere]

If you already can program Knuth is surely worth reading. But if you are a beginner, then simply don't.

I really would not fancy a guy who is applying for a job and his example code consists of 30 lines where every variable just named with one letter. Even if he points out: oh but that is how Knuth does it ;D

Re:Bah! Pretenders!

[betterunixthanunix]

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.