Forgot your password?
typodupeerror
Books Programming

What Is the Most Influential Programming Book? 624

Posted by samzenpus
from the best-of-class dept.
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."
This discussion has been archived. No new comments can be posted.

What Is the Most Influential Programming Book?

Comments Filter:
  • Deitel & Deitel (Score:4, Insightful)

    by bigjocker (113512) * on Sunday September 04, 2011 @07:47PM (#37304824) Homepage

    'nuff said

    • Re: (Score:3, Interesting)

      Charles Petzold.

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

      Sad. But TRUE!

      • by tha_mink (518151)
        Oooof. That hurts. That's
    • That would be my #1 choice. I've read most of the CS classics, and they're good. But I really *got* programming after reading Deitel's C++ textbook from cover-to-cover attempting at least half the exercises.

      Petzold's Programming Windows comes second place.

      Followed by Knuth's 2nd installation.

    • No (Score:5, Insightful)

      by edalytical (671270) on Sunday September 04, 2011 @09:38PM (#37305468)

      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.

      • by JavaManJim (946878) on Sunday September 04, 2011 @10:42PM (#37305750)

        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.

  • Bah! Pretenders! (Score:5, Informative)

    by leftover (210560) on Sunday September 04, 2011 @07:50PM (#37304844) Homepage

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

    Now get off my lawn!

    • by sconeu (64226)

      Damn straight. You beat me to it.

    • by Enry (630)

      Got the first three volumes as a HS graduation present from my parents. Don't use it as much as I should, but that's because I'm not a programmer anymore.

    • by Anonymous Coward on Sunday September 04, 2011 @08:44PM (#37305178)

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

      • Re:Bah! Pretenders! (Score:4, Interesting)

        by KingAlanI (1270538) on Sunday September 04, 2011 @11:20PM (#37305938) Homepage Journal

        "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

      • 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: (Score:2, Interesting)

      by 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 preve

  • by drodal (1285636) on Sunday September 04, 2011 @07:52PM (#37304864) Homepage
    by  k and r
  • by SpinningAround (449335) on Sunday September 04, 2011 @07:56PM (#37304870)

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

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

      • I thought about this one as well but I decided not to post because TMMM is really about program management, not programming, per se.

        It's about programming in the sense that it helps you recognize when you are entering a project that will spiral down, so you can avoid emotional attachment or get out if possible.

        And from the other angle if many developers have read it they can help steer the project away from that course early.

        • Re: (Score:3, Insightful)

          by JeremyMorgan (1428075)

          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.

    • by vux984 (928602)

      I've read it. It was also in the top 10 in the full article.

    • by digitig (1056110) on Sunday September 04, 2011 @09:03PM (#37305282)
      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.
  • Great book on design patterns, Design Patterns: Elements of Reusable Object-Oriented Software [wikipedia.org].

    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 [designpatternsinruby.com].

    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

    • by BitterOak (537666)

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

      I was going to mention Design Patterns too, but you beat me to it. I second the vote. Along with The C Programming Language and Advanced Programming in the UNIX Environment one of the best programming books I've ever read.

    • by tha_mink (518151)
      Yeah, this book changed my career. I think it's by far the best book in my software design collection. I've read it > 5 times, and I still pull it out from time to time and read a chapter or two.
    • Re:Gang of Four (Score:5, Insightful)

      by syousef (465911) on Monday September 05, 2011 @01:10AM (#37306314) Journal

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

      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 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 [amazon.co.uk] (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 (Score:5, Interesting)

      by TheRaven64 (641858) on Monday September 05, 2011 @05:06AM (#37306996) Journal

      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 (Score:4, Insightful)

        by White Flame (1074973) on Monday September 05, 2011 @05:59PM (#37311120)

        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.

  • 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 (Score:5, Interesting)

    by Mensa Babe (675349) * on Sunday September 04, 2011 @07:59PM (#37304894) Homepage Journal

    The correct order should be:

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

    I am sure that The Art of Computer Programming Volume 5 [stanford.edu] 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.

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

    • by fermion (181285)
      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 Co

  • by Maljin Jolt (746064) * on Sunday September 04, 2011 @07:59PM (#37304896) Journal

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

  • Great starter book for non-cs types.
    • by siddesu (698447)
      Actually, if you want to go with perl all the way, then it'll be three - Learning Perl, the first edition of Advanced Perl Programming and Mastering Algorithms in Perl. Or, picturewise, the llama book, the panther book and the wolf book. As good a start as any, perhaps, but in no way substitute for Knuth.
    • by 1729 (581437)

      A better one is The UNIX-HATERS Handbook (http://simson.net/ref/ugh.pdf). Until you realize how terrible[1] Unix is, any program you write is suspect.

      [1]: Yes, like most folks here, I use Unix-like systems almost exclusively. Donald A Norman sums it up well in the Foreward: "A horrible system, except that all the other commercial offerings are even worse."

      • 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.
  • by DoofusOfDeath (636671) on Sunday September 04, 2011 @08:07PM (#37304934)

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

  • The value of book largely depends on your skills at the time... "Code Complete" was pretty good, but you need to be already an adept programmer to see the value of its advice.

    I really wish I had read "Interprocess Communications in UNIX: The Nooks and Crannies (2nd Edition)" earlier. It's not the thickest book but it is the most information dense one I own. In today's environment of multicore and SMT CPUs, any programmer should have a deep understanding of IPC. An excellent partner to a good C book.

  • K&R C (Score:5, Insightful)

    by Doc Ruby (173196) on Sunday September 04, 2011 @08:07PM (#37304938) Homepage Journal

    The C Programming Language [wikipedia.org] 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 [wikipedia.org]" 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.

    • ...And despite popularizing the unitary "var++" (eg. in for() loops), rather than the semantically more consistent "++var" ... You do realise that ++var and var++ are both valid C and do different things, right?
      • by imp (7585)

        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 t

    • Re:K&R C (Score:4, Interesting)

      by Rogerborg (306625) on Monday September 05, 2011 @06:04AM (#37307176) Homepage

      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.

  • by syousef (465911) on Sunday September 04, 2011 @08:11PM (#37304956) Journal

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

    • by hibiki_r (649814)

      The gist of MMM is not anywhere near what you say. Even if we just wanted to cover that single chapter, the points is not just that you can't add more people to speed up a process, but that adding more people to a late project make the project go even later.

      And still you'd be missing at least two chapters that are at least equally as important:
      -There Is No Silver Bullet
      -Plan To Throw One Away

      Which are what makes Brook's little green book timeless, despite how badly some other chapters have aged. This is why

  • If I could go back in time that far, I wouldn't be worried about telling myself to read some book, I would tell myself to buy MSFT stock in 1981, and Apple stock in 1983, and sell short in October '87 etc

  • Next question?
  • K&R as far as long-lasting impact. But my sentimental favorite? Doug Cooper's "Oh! Pascal!" I still have a copy of it.

  • by msobkow (48369) on Sunday September 04, 2011 @08:16PM (#37304986) Homepage Journal

    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.

  • by LynnwoodRooster (966895) on Sunday September 04, 2011 @08:17PM (#37304992) Journal
    It's "I, Robot" from Isaac Asimov. How many read that book early on and thought "I can do better than those three rules"...
  • by jacobsm (661831) on Sunday September 04, 2011 @08:17PM (#37304996)

    The book that started it all.

    • Yeah, not the Ned Chapin horror. He's one of those people who can write and write and write and not communicate a single clear concept.
  • Strange. 10 years ago I used to get my news from slashdot first. Now, not so much anymore. This list is pretty exhaustive and has more backing than I expect you'd find anywhere else, including here: http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read [stackoverflow.com]
  • Namely, the C64 Programmer's Reference Guide, and more importantly, Machine Language for the C64 [...] by Jim Butterfield.

  • The one you read? As opposed to hollow out to keep a flask of scotch in it?
  • by GoodNewsJimDotCom (2244874) on Sunday September 04, 2011 @08:31PM (#37305104)
    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.
  • by 2TecTom (311314) on Sunday September 04, 2011 @08:33PM (#37305124) Homepage Journal

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

  • UNIX and Unix 4ever

  • Seriously, doing proofs taught me more about logic and algorithm and problem solving than anything else. But yeah, also K&R.
  • by craftycoder (1851452) on Sunday September 04, 2011 @08:53PM (#37305240)

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

  • It may seem odd (Score:5, Interesting)

    by Arran4 (242789) <slashdotNO@SPAMarran4.com> on Sunday September 04, 2011 @09:18PM (#37305370) Homepage
    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.)
  • by dpbsmith (263124) on Sunday September 04, 2011 @09:21PM (#37305384) Homepage

    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.

  • by awrc (12953) on Sunday September 04, 2011 @09:22PM (#37305386)

    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 Assembler? (Score:4, Interesting)

    by Khyber (864651) <techkitsune@gmail.com> on Sunday September 04, 2011 @10:01PM (#37305598) Homepage Journal

    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.

  • Starting Forth (Score:3, Insightful)

    by nkuitse (208997) on Sunday September 04, 2011 @10:14PM (#37305666) Homepage

    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.

  • by RandCraw (1047302) on Sunday September 04, 2011 @10:14PM (#37305668)

    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.

  • by slapout (93640) on Sunday September 04, 2011 @10:27PM (#37305702)

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

  • by Serendip7 (936348) on Sunday September 04, 2011 @10:44PM (#37305768)
    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.
  • by martyb (196687) on Sunday September 04, 2011 @11:01PM (#37305848)

    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 [amazon.com]. 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.

  • by jonwil (467024) on Sunday September 04, 2011 @11:27PM (#37305980)

    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.

  • by ledow (319597) on Monday September 05, 2011 @06:44AM (#37307278) Homepage

    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

  • by phozz bare (720522) on Monday September 05, 2011 @07:11AM (#37307364)
    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.
  • by angel'o'sphere (80593) on Monday September 05, 2011 @08:08AM (#37307530) Homepage Journal

    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/ [xunitpatterns.com] This is an excellent book about Software Testing.

Never put off till run-time what you can do at compile-time. -- D. Gries

Working...