Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Books Media

Errata in Programming Books? 55

Posted by Cliff from the how-often-do-you-find-it dept.
WgT2 asks: "I recently have set my mind to learning to code PHP. Not being a programmer, yet, I went out and got myself a book on the subject from a very trusted, at least in my eyes, publisher (and they still still are). So far so good. However once I got down to trying the code out myself I have found too much errata for someone who has just scratched the surface in learning the ins and outs of programming. I was wondering just how common place Slashdot readers have found errata in the code examples of programming books they have purchased?"
This discussion has been archived. No new comments can be posted.

Errata in Programming Books? More

Errata in Programming Books?

Comments Filter:
  • The original K & R C guide was legendary for it's coding errors.

    Why don't they care?

    Bill

    Also the chapter on pointers sucked ass.

    • Publishers should hire college geeks to proof code

      The original K & R C guide was legendary for it's coding errors.

      Perhaps slashdot posters should hire college English majors to proofread their posts.

      Let's face it, we all make mistkaes, even K&R. But The C Programming Language, has been continuously read and referenced by newbie and experienced coders alike since 1978 -- for twenty-five years.

      Apparently it's legendary for more than just what you dismiss as "coding errors".
    • According to K & R, all of the code in The C Programming Language has been tested from the original text. However, the minimum wage printers often removed all or parts of punctuation marks and the such, thinking they were not originally intended to be on the printing plates.

      Also, K & R have an EXCELLENT errata page:
      http://cm.bell-labs.com/cm/cs/cbook/2ediffs .html

    • Publishers should hire college geeks to proof code

      I was once a student of Rob Pike [bell-labs.com] ,author of "The Unix Programming Environment with Brian Kernighan [bell-labs.com](the K in K & R). They were at the time writing The Practice of Programming [slashdot.org] again with Kernighan.

      The course notes for this subject were basically the chapters of the book. He asked all his students to read through the code examples and let him know if there were any problems. I don't know if we can claim all the credit (I found some errors in the ear

  • Frequently... (Score:5, Interesting)

    by stefanlasiewski ( 63134 ) <slashdotNO@SPAMstefanco.com> on Monday April 14, 2003 @09:12PM (#5732746) Homepage Journal
    Tough subjects, tight deadlines, and the profit-first additude lead to bad books.

    I recently purchased Learning Java [oreilly.com] from Oreilly. Usually I've had a good experience with Oreilly books, but this one was horrible. Several of the examples in the first chapter of the book didn't work because they had typos!

    Few things are more frustrating then debugging a "Hello World" program that doesn't work. I went over every character, bit by bit, and my program matched their text exactly. I couldn't find the damn bug. Was I so stupid that I couldn't see the obvious? No! I viewed the Online Errata, and found that a zillion other people were having similar problems with examples throughout the book! Typos galore!

    If there are too many mistakes in the book, then let the publisher note. Return the book, get your money back, send a note to the publishers, and buy an alternative book.

    • YMMV (Score:2)

      by gmajor ( 514414 )
      I had to learn Java quickly, and I used the same book. The programs I tried worked for me, although I did skip the programs in the first couple chapters.

      I absolutely love the book. Your mileage may vary.
    • I had a quick stint in the technical-book field and I can tell you, you are dead on the money!

      Much like the production process of films, TV, Music and Radio, book production is *COMPLETLEY* bankrupt. My own experience was, a well known publisher wanted to do a book on network programming and my friend and I were asked to submit a proposal. Long story short, they couldn't make up their mind -- they wanted a simple "network programming for dummies" type book, so we gave them that... Then that was too si

  • It's very common (Score:3, Informative)

    by Hanashi ( 93356 ) on Monday April 14, 2003 @09:16PM (#5732765) Homepage
    It's quite common to find errors in technical books. Some of them are simply typos, others are more complex. In the process of producing a book, the text goes through several hands. The author writes it, of course, then various editors all have their fingers in it. Generally they make it better (that's a plug, if my editors are reading 8-) but sometimes mistakes happen. Overall, writing a book is just such an enormous amount of work and there are so many people involved, mistakes are a given.

    Many (most?) books publish errata on their web pages or on their publisher's site. I've even got a few books that had printed errata folded up and stuck into the cover. I don't mind seeing a reasonable number of errors in a book, especially a very technically dense book, as long as I see that the author and/or publisher makes the errata sheets easily available. After all, we're all only human.

    • Indeed, especially on 'developing' languages like PHP. There's quite a bit of errata simply from syntax changes between when the book was published and 'current' version of the language. Most books will explicitly say "as of 3.14" or the such.

      btw: to learn PHP the best thing to do is to use their website. All of the functions are spelled out rather well.
  • I was wondering just how common place Slashdot readers have found errata in the code examples of programming books they have purchased?

    I'm not really the most commonplace of Slashdot users, but I usually find errata by looking on the book's website, or trying the code. I suspect the more common-place of slashdotters use the same strategy.

    --Dan

  • obligatory (Score:4, Interesting)

    by Satai ( 111172 ) on Monday April 14, 2003 @09:32PM (#5732826)
    Someone has to make a Knuth joke. I tried, couldn't come up with anything. Come on people!

    Here's his errata [stanford.edu].

    My favorite is the Random Number error [stanford.edu]. It took a while, but someone discovered that apparantly one of the portable random number generators behaves poorly during the first 2000 or so of each seed number. So, naturally, Dr. Knuth corrected it almost immediately.

    Never have I seen a man so humble that so amply deserved to be arrogant...
  • The graphics routines were handwritten in ASM.

    I learned more debugging the errors in the printed code than I did in reading the frigging book.

    Twisted, huh?

  • Thoughts from an O'Reilly Author (Score:4, Interesting)

    by Anonymous Coward on Monday April 14, 2003 @09:38PM (#5732859)
    The book I wrote had quite a bit of errata with some simple topics, and not much on the hard topics. I simply didn't spend enough time on the first half of the book, and I regret it.

    What really killed my time was adding more content to the book than initially planned. I should have left it all out, but at the time I thought I had the rest of the book nailed down. I should have spent more time reviewing, and getting more feedback from the reviewers.

    If any of you write a book, be sure to stick to the initial plan, and do no more. You might even want to cut out some of the content... don't just write to add more pages to the book. That is one thing I hate about Wrox books, imho, and I did a little bit of that myself :-(

    Of course, there are always second printings, and second editions to incorporate the fixes, but that doesn't fix the disappointment of finding the errors in your own book the first time around.
  • More often than not, it is the editors who are at blame rather than the authors. First off, my bride was a technical writer. I'm still not quite sure what that means, but as an English / Math double major without any coding experience, some of the results were quite comical. A while back she was fixing the Engrish descriptions, code fragments, sql scripts, and a mix of other stuff. She went back to the developer because they possibly misspelled pseudo as sudo. She had the sense to not 'spell check' the scripts, but another friend who wrote a Perl book said his editors were not quite as thoughtful.

  • One Recent Problem (Score:3, Informative)

    by TheWanderingHermit ( 513872 ) on Monday April 14, 2003 @10:22PM (#5733047)
    I haven't done any programming in over a decade. I recently had to start learning a lot of new information and bought several stacks of books. I found the O'Reilly books to be VERY helpful. In the past I always found Sam's to be informative and helpful as well, but I found Sam's MySQL in 24 Hours to be rather frustrating because of little errors here and there.

    Above and beyond the errors, I don't know if it's because the book is a "in 21 Days" format or not, but I've found it rather frustrating and useless in the long run because it does not work well as a reference book and it seems there is A LOT that has been left out.

    I will not likely buy another book in any "in 21 Days" or "in 24 Hours" or any similar format again. While they may provide a quick intro, it seems to be a week format if you plan to continue in the subject.
    • I will not likely buy another book in any "in 21 Days" or "in 24 Hours" or any similar format again. While they may provide a quick intro, it seems to be a week format if you plan to continue in the subject.

      I disagree. Isn't the "In 7 Days" format the week one?

  • Look to the publisher's site (Score:5, Informative)

    by babbage ( 61057 ) <cdeversNO@SPAMcis.usouthal.edu> on Monday April 14, 2003 @11:21PM (#5733249) Homepage Journal
    Most (all?) of the publishers today will have a web site dedicated to each title, and the better ones (all again?) will have an errata page somewhere in there. Look for it. Consider basing purchasing decisions on the presence & quality of that errata page:
    • If it has such a page, and it's short (all books will have at least some typos -- that's life), then you're in good shape.
    • If it looks like the errata page is updated often, that's also a good sign -- it means the publisher is paying attention. That may be even better.
    • If it has an errata page, and it's really long, then maybe the book is just sub-par: be careful here.
    • If it has no errata page, the publisher is lying, or hasn't gotten around to it yet: be careful here, too.

    I don't know which book you got, but O'Reilly's Programming PHP [oreilly.com] has its own confirmed [oreilly.com] and unconfirmed [oreilly.com] errata pages. If this is the book you've got, feel free to go over the corrections noted on these pages and jot them down in your copy -- I've done that with a couple of my books, and would have missed many of the glitches without that hint. If you see an error that isn't on this page, O'Reilly offers a error submission form [oreilly.com] that you can use for that book (and others of course) -- so use it! If the publisher doesn't find out about these mistakes, they aren't going to get fixed. A good publisher will offer revised printings -- not that that helps you once you've got a copy, but it will prevent other learners from having to hit the same obstacles you did. :-)

    You can't, unfortunately, expect books to be perfect & pristine. (Well, maybe Knuth's books, but everyone else has to deal with typos & thinkos :-). You can, however, and should expect the publisher to own up to their little mistakes and offer you corrections on their site. Go find that info and get the fixes into your copy and you'll be a happier camper.

    • my favourite thing is when the errata page has fixes to errors that aren't even IN the book. Ugh.

      A thought - it might be better to buy a book that is a second or later edition, rather than a first. My reasoning is that 1) the book was good enough (or at least sold well enough) to justify more than one edition, and 2) errors in the previous edition may be more likely to have been corrected in the subsequent edition(s).

      For sure, check that the book (and the edition you're looking at) has an errata page at t

  • Errata Schmerrata (Score:4, Insightful)

    by tres ( 151637 ) on Monday April 14, 2003 @11:42PM (#5733347) Homepage
    Errors in examples give you the responsibility of thinking about the code. You've got to understand what it is doing, rather than just mimicking the examples.

    Believe me, I've spent my fair share of time and frustration trying to debug bad examples. It took a long time to learn, but when I don't trust the author, I find that the errors are more challenging than frustrating.

    A couple of O'reilly books in particular, Steve Oualline's Practical C Programming and his Practical C++ Programming purposely have errors in the examples for just this reason.
    The difference is, Steve tells you that the errors are there. It's a good learning technique, and forces you to pay attention to the concepts rather than the examples.

    • "Errors in examples give you the responsibility of thinking about the code. You've got to understand what it is doing, rather than just mimicking the examples."

      It's a bad teacher that blames the student for not learning. For some people getting a correct example to function can be an achievement. After the mimicked code is functional, it can be used for experimentation (and learning).

      Also, putting in deliberate errors makes the book useless as a reference. If you can't quickly review a code fragment for

      • Re:Errata Schmerrata (Score:3, Interesting)

        by tres ( 151637 )
        I have two kinds of programming books on my shelves. One kind is an introductory book, the other is a reference. My reference books I use all the time. But the introductory books are darn near disposable. After reading them, they become paperweights. Don't get me wrong, they are a necessary part of learning, but after I've learned what they have to give, it's a rare case that I might pick them up again.

        The reference books I have are always a source of new information. These always seem to be much more accu

    • Ah, but the difference is in pointing stuff out. I'd feel great if a book says, "Look, here's a code snippet that's supposed to do X, but doesn't. Why? (Answers at page 123)". It's a sort of exercise really, and as you pointed out, a good learning technique as well.

      That's not what the poster is talking about here. That said, I've rarely found technical problems that weren't fixed by a quick Google search, especially in the Google Groups section.

    • There's some truth to what you've written, but you're looking at it from someone who is already a programmer. A total newbie who first encounters programming through an error-riddled introductory book could be put off from coding forever due to frustration. If you know nothing of programming and the hello world in your coding 101 book is fucked up, you just don't have the tools to figure out why at that point, and won't for a long while yet.
  • Errors in book happen all the time, but it seems like translation make it worse...

    I own a couple of coding books translated in french - it's even weirder. Sometimes the variables in the code get translated, sometimes the step-by-step explanations get out-of-sync and the variables change names, well you get the point.

    Do translators know they're translating code or are book businesses really hiring cheap labor?

    Then, after reading stacks and stacks of books and lines and lines of code that talk about array
    • Usually the Grad students try to get direction only to find the professor to busy to help. They eventually go with their best judgement. Also, since there are usually several grad students working on one book (Each pulls different chapters/sections to do, get things done faster), communication in the group is key to getting it done properly.
      The disappearing sentence is a good example of that. A translated page takes up more space than the untranslated version, so Student1 needs to talk to Student2 to me

  • Favorite statement (Score:3, Interesting)

    by michael_cain ( 66650 ) on Tuesday April 15, 2003 @12:49AM (#5733640) Journal
    Many years ago (pull it off of the "old textbook" shelf, copyright is... 1976, I am getting so old), Kernighan and Plauger wrote "Software Tools." One of my favorite statements made in the introduction is
    Every program in this book has been run and carefully tested, directly from the text itself, which is in machine-readable form.
    I suppose some of the code fragments can't be checked this way, but at least testing the bigger pieces of code can be automated. Of course, this assumes that at some point the files are turned over to the publisher who does not mess with them any more. Not a safe assumption -- I wrote an article for an IEEE journal and approved the "final" version, which was then mangled by another editor and sent to press. I spent weeks trying to explain to people that I could write better than that...
  • As a big reader (and reviewer) of technical books, they usually aren't much of a problem for me as material I already know can patch the code (and usually it's as basic as misspelling a keyword of something trivial like that).

    I've never once had to look up errata for the book because of coding errors (although for a couple of Wrox books that had pages and pages of code, I couldn't be bothered debugging the code and downloaded it).
  • Several years ago I bought Java for Dummies, the first edition of the book. I don't believe I ever made it past the 3rd Chapter or so because only about half of the Code Examples were working correctly. It was so bad, I dropped Java and went back to C and have only recently tried another attempt at Java. I even tried the CD that came with the book and several (although not as many) of the examples on that did not even work. I ended up throwing it all away and I haven't bought a Dummies book since.

    ->
  • I had a Pascal Text book in college, that was riddled with errors. Syntax, logic, bugs, overflows...the code samples were just nasty...

    The worst part is it was very appearent that the professor had no idea, since she just rattled off the same mistakes as part of the lecture.

    Luckly I had already had Pascal in high school with a good instructor...I flew through the class while others struggled due to the crappy book...
  • Personally I have come across few typing errors in books (then again I RARELY try any of the code they offer in books). I personally have several PHP books and if you are just starting to learn PHP please be aware that the language goes through like 4 updates a month or something like that. I remember when I first tried to learn PHP I attempted some of the code and it would not work. This was because from the time the book was published to the time I got it the PHP language had changed. Some of the defaults
  • I find that figuring out the errata beforehand really lends to a deeper understanding of the subject matter. It is a great way to "dialogue" with the text as opposed to passively absorbing it.

    And I always email the author if he asks for errors. That way he might mention me in the acknowledgements section and my googlekarma will skyrocket!
  • It is not just in programming books.

    This same thing is fairly common in cookbooks.

    Many of the recipes in cookbooks if you actually follow the directions and ingredient list exactly, would not come out right.

    So when your double fudge walnut chocolate upside down cake doesn't taste right it might not be your fault.

  • I've considered starting up an errata directory, where readers, authors, et c. could submit their errata to be compiled into one easy-to-search database. A useful idea?
  • I'm not really a coder or developer, although I know some perl. I believe this is rather a common occurance. The examples in books are there more or less to give a reference on how you should approach a problem rather than a real working example. I seem to remember reading a C++ book in college that actually said this in the front of the book.

    Hey, at least you are catching errors. You are better off than the people that did not catch them.

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close