5 ms·

When programming books are wrong

50 points by cenny 5y ago

mahirsaid 5y ago
wow great site indeed my friend
- ncmncm 5y ago
  Respectfully disagree. Many of these books advocate habits that actually interfere with effective code development.
  - cush 5y ago
    Have you tried looking at the context in which the books were written and applying similar principles to your domain? Often, as time goes on, specific rules or patterns may stale and be less applicable, but the principles remain rock solid.
    - spc476 5y ago
      I don't buy that. The post quoted from _Clean Code_ by Uncle Bob: > The ideal number of arguments for a function is zero (niladic). Uncle Bob is an idiot for making this statement. Taken at face value, just where is the data for the function to operate on come from? With no parameters, it must come from data at an outer scope, usually a global, which is a bad idea. Within the context of the language Uncle Bob is blathering about, Java, each "function" has an implicit argument, which is the object itself. So even if Uncle Bob wanted a zero-argument function in Java, he's not getting one. The arguments are still coming from an outer scope. Just this one statement makes me less inclined to take anything he says seriously.
      - Jtsummers 5y ago
        You're going to judge a book and the man by a context-free quote? That's kind of stupid, you know that right?
        deleted 5y ago
        [deleted]
      - kleinsch 5y ago
        > Uncle Bob is an idiot for making this statement Bold claim for someone who didn't even read the whole quote in context. > The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification-- and they shouldn't be used anyway.
        Silhouette 5y ago
        To be fair it doesn't make any more sense even with the full context. It is just a silly thing to say and it was said without much of a supporting argument at all, never mind any real evidence for the validity of the claim. That is an unfortunately common problem with Clean Code and a lot of other work by Martin.
        Jach 5y ago
        People get such hate-boners for "Clean Code" specifically, it's weird. I once thought they might have had a point until I read the book and, while I found much to disagree with, it's actually not a bad book (I have more negative things to say about an oft-cited "counter" book, "A Philosophy of Software Design"). I think there's useful things to learn and consider in it, and even though I think you can do better by thinking for yourself, the average bar is so low among programmers that I think many would be improved by substituting their non-thinking flailing around for non-thinking dogmatic following of such books' rules of thumb. Working in such a dogmatic environment would be oppressive, though you at least have a framework to move beyond some of it. Presumably such environments exist and maybe that's a source of some hate, though I've more often seen oppressive environments that e.g. won't accept any Python commits which violate the changing PEP8 lint checks despite PEP8 itself allowing for differences of opinion. There's even more context that people should consider. From earlier in the same chapter: "The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes. I’ve written several nasty 3,000-line abominations. I’ve written scads of functions in the 100 to 300 line range. And I’ve written functions that were 20 to 30 lines long. What this experience has taught me, through long trial and error, is that functions should be very small." My relevant point here is that it's clearly not a book full of careful supporting arguments and cited research or really even hyper-specific non-fuzzy rules. It's a style guide for how to make "clean code", built from the author's experiences and idea of what "clean" means. Disagreement is natural, and often also based on nothing more than different experiences rather than careful arguments/research. It's also very contextual, as the book itself notes in places -- different languages, tooling, or emphasized programming paradigms will produce different ideas of what clean means. For the issue about function arguments, in the full context it's very clear that in Java we don't idiomatically interpret the implicit "this" to be an extra function argument as we do in idiomatic Python with its explicit "self". Immediately after the quoted sentence on number of arguments is this: "Consider, for instance, the StringBuffer in the example. We could have passed it around as an argument rather than making it an instance variable, but then our readers would have had to interpret it each time they saw it." That the bytecode for a method using an instance variable includes an "aload_0" instruction to load up "this" and "getfield" to get the instance variable value is an implementation detail. Would it have been better, from a purely functional perspective, to pass the StringBuffer around explicitly anyway? Maybe. Same maybe when it comes to unit testing concerns. Anyway, I don't see much complaining when function bodies make use of implicit built-ins like + or - or sin() or PI, instead of passing all such things as explicit arguments. That way leads to Enterprise FizzBuzz in the Java equivalent. Sure, data not part of the method body has to come from an "outer scope", but this is not "usually a global" but an instance var, and in the very worst is a package-namespaced var. Is it a great sin to lift something into an instance variable? No, not in Java. And even for true 0-arg functions (static methods), the data can come from the method body itself. This is naturally part of the style advocated throughout the book, where you might have e.g. 10 lines of printing out some literal strings (perhaps a little help manual), you can extract those ten lines into a standalone 0-arg static method and the original method will be shorter and cleaner. Edit: one last thing for consideration, Linus has written in the kernel coding style guide "...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program." Is he an idiot for making such a statement? Is it a silly thing to say?
      - BeefWellington 5y ago
        > Uncle Bob is an idiot for making this statement. Taken at face value, just where is the data for the function to operate on come from? With no parameters, it must come from data at an outer scope, usually a global, which is a bad idea. Within the context of the language Uncle Bob is blathering about, Java, each "function" has an implicit argument, which is the object itself. So even if Uncle Bob wanted a zero-argument function in Java, he's not getting one. The arguments are still coming from an outer scope. You're kind of making the author's point for them here. The entire premise of OO languages is to colocate functionality with the structure of the relevant data for that functionality. If you write a function which takes zero arguments attached to the class Integer (perhaps toString), it does in fact have zero arguments. This makes it simpler to reason about in the context (key word from the point the author was making) of Java. In that context, it is self-evident that any method attached to a class that takes zero arguments is operating entirely on either the data within the class or static data available system-wide. The idea you're presenting is mostly pedantry and you've confused function arguments with data accessible to a function.
      - scheme271 5y ago
        The article itself addresses this in detail at the very beginning. Quoting it a bit: "This statement makes no sense in Haskell (or lambda calculus) since all functions take one argument, and functions with zero arguments are illegal. Does that mean that the ideal function can not exist in Haskell? No, this is an unfair judgment. Uncle Bob wrote this book with an OOP (Object-Oriented Programming) perspective with examples in Java. The point is that many arguments can be hard to use, understand, and can be a smell of too many dependencies. "
      - cush 5y ago
        A simple “no” would have sufficed.
  - c0npr 5y ago
    Even if you do not agree with the coding style they propose, it is still useful to know and helps understand others code (and the rationale behind it). It is true though not everything applies nicely.
  - cenny 5y ago
    What kind of habits do they advocate that interfere with writing good code? I would love to hear more about this opinion.
cenny 5y ago
The link was supposed to go to an article on the site (https://www.programmingbooks.dev/articles/book_is_wrong/ https://www.programmingbooks.dev/articles/book_is_wrong/)
- Jtsummers 5y ago
  HN adjusts submissions to use the canonical URL if present in the HTML. Check the source of the page and its canonical URL (on mobile and apparently you can't do view source in iPadOS' Safari).
  - erik_seaberg 5y ago
    You’re right, the page has <link rel="canonical" href="https://www.programmingbooks.dev"> which isn’t the canonical URL for the same content.
  - deleted 5y ago
    [deleted]
  - marcellus23 5y ago
    Tangential, check out Achoo for viewing inspecting the HTML source on iOS https://apps.apple.com/us/app/achoo-html-viewer-inspector/id1585833321 https://apps.apple.com/us/app/achoo-html-viewer-inspector/id...
blueside 5y ago
I think this is one of the better lists out there. I own almost all of the books in this list. But don't get your hopes up too much. I'm still a lousy programmer.
rg111 5y ago
This is a nice list. I will highly recommend The Little Schemer. You will change after reading this book. It is that good. This book made me truly undersy recursion. I understood recursion before, and used it to solve problems, but this is the book that totally scratched my surface and instilled recursion in it. Pragmatic Thinking and Learning is the first book of its kind that I ever read. I was surprised by the quality of it. It is a very nice book with scientific and actionable advice. Will recommend it, too. (Although there are some issues like oversimplified model of brain, divided into L and R mode, and in one place it preached different type of learners theory, which is now thoroughly discredited.) For an approachable programming book, i.e. book not CLRS, Skiena, or DPV, I will not recommend Grokking Algorithm. I will recommend A Common Sense Guide to Data Structure and Algorithm from PragProg Bookshelf. This is a much better and more complete book with exercises that are effective in learning the topics well.
- cenny 5y ago
  Thanks for the feedback and nice words! I will look into “A Common Sense Guide to Data Structure and Algorithm” and see if I agree with you. But yes, little schemer is so good, wished I read it earlier than I did.

50 points by cenny 5y ago

mahirsaid 5y ago

wow great site indeed my friend

ncmncm 5y ago
Respectfully disagree. Many of these books advocate habits that actually interfere with effective code development.
- cush 5y ago
  Have you tried looking at the context in which the books were written and applying similar principles to your domain? Often, as time goes on, specific rules or patterns may stale and be less applicable, but the principles remain rock solid.
  - spc476 5y ago
    I don't buy that. The post quoted from _Clean Code_ by Uncle Bob: > The ideal number of arguments for a function is zero (niladic). Uncle Bob is an idiot for making this statement. Taken at face value, just where is the data for the function to operate on come from? With no parameters, it must come from data at an outer scope, usually a global, which is a bad idea. Within the context of the language Uncle Bob is blathering about, Java, each "function" has an implicit argument, which is the object itself. So even if Uncle Bob wanted a zero-argument function in Java, he's not getting one. The arguments are still coming from an outer scope. Just this one statement makes me less inclined to take anything he says seriously.
    - Jtsummers 5y ago
      You're going to judge a book and the man by a context-free quote? That's kind of stupid, you know that right?
      - deleted 5y ago
        [deleted]
    - kleinsch 5y ago
      > Uncle Bob is an idiot for making this statement Bold claim for someone who didn't even read the whole quote in context. > The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification-- and they shouldn't be used anyway.
      - Silhouette 5y ago
        To be fair it doesn't make any more sense even with the full context. It is just a silly thing to say and it was said without much of a supporting argument at all, never mind any real evidence for the validity of the claim. That is an unfortunately common problem with Clean Code and a lot of other work by Martin.
        Jach 5y ago
        People get such hate-boners for "Clean Code" specifically, it's weird. I once thought they might have had a point until I read the book and, while I found much to disagree with, it's actually not a bad book (I have more negative things to say about an oft-cited "counter" book, "A Philosophy of Software Design"). I think there's useful things to learn and consider in it, and even though I think you can do better by thinking for yourself, the average bar is so low among programmers that I think many would be improved by substituting their non-thinking flailing around for non-thinking dogmatic following of such books' rules of thumb. Working in such a dogmatic environment would be oppressive, though you at least have a framework to move beyond some of it. Presumably such environments exist and maybe that's a source of some hate, though I've more often seen oppressive environments that e.g. won't accept any Python commits which violate the changing PEP8 lint checks despite PEP8 itself allowing for differences of opinion. There's even more context that people should consider. From earlier in the same chapter: "The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes. I’ve written several nasty 3,000-line abominations. I’ve written scads of functions in the 100 to 300 line range. And I’ve written functions that were 20 to 30 lines long. What this experience has taught me, through long trial and error, is that functions should be very small." My relevant point here is that it's clearly not a book full of careful supporting arguments and cited research or really even hyper-specific non-fuzzy rules. It's a style guide for how to make "clean code", built from the author's experiences and idea of what "clean" means. Disagreement is natural, and often also based on nothing more than different experiences rather than careful arguments/research. It's also very contextual, as the book itself notes in places -- different languages, tooling, or emphasized programming paradigms will produce different ideas of what clean means. For the issue about function arguments, in the full context it's very clear that in Java we don't idiomatically interpret the implicit "this" to be an extra function argument as we do in idiomatic Python with its explicit "self". Immediately after the quoted sentence on number of arguments is this: "Consider, for instance, the StringBuffer in the example. We could have passed it around as an argument rather than making it an instance variable, but then our readers would have had to interpret it each time they saw it." That the bytecode for a method using an instance variable includes an "aload_0" instruction to load up "this" and "getfield" to get the instance variable value is an implementation detail. Would it have been better, from a purely functional perspective, to pass the StringBuffer around explicitly anyway? Maybe. Same maybe when it comes to unit testing concerns. Anyway, I don't see much complaining when function bodies make use of implicit built-ins like + or - or sin() or PI, instead of passing all such things as explicit arguments. That way leads to Enterprise FizzBuzz in the Java equivalent. Sure, data not part of the method body has to come from an "outer scope", but this is not "usually a global" but an instance var, and in the very worst is a package-namespaced var. Is it a great sin to lift something into an instance variable? No, not in Java. And even for true 0-arg functions (static methods), the data can come from the method body itself. This is naturally part of the style advocated throughout the book, where you might have e.g. 10 lines of printing out some literal strings (perhaps a little help manual), you can extract those ten lines into a standalone 0-arg static method and the original method will be shorter and cleaner. Edit: one last thing for consideration, Linus has written in the kernel coding style guide "...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program." Is he an idiot for making such a statement? Is it a silly thing to say?
    - BeefWellington 5y ago
      > Uncle Bob is an idiot for making this statement. Taken at face value, just where is the data for the function to operate on come from? With no parameters, it must come from data at an outer scope, usually a global, which is a bad idea. Within the context of the language Uncle Bob is blathering about, Java, each "function" has an implicit argument, which is the object itself. So even if Uncle Bob wanted a zero-argument function in Java, he's not getting one. The arguments are still coming from an outer scope. You're kind of making the author's point for them here. The entire premise of OO languages is to colocate functionality with the structure of the relevant data for that functionality. If you write a function which takes zero arguments attached to the class Integer (perhaps toString), it does in fact have zero arguments. This makes it simpler to reason about in the context (key word from the point the author was making) of Java. In that context, it is self-evident that any method attached to a class that takes zero arguments is operating entirely on either the data within the class or static data available system-wide. The idea you're presenting is mostly pedantry and you've confused function arguments with data accessible to a function.
    - scheme271 5y ago
      The article itself addresses this in detail at the very beginning. Quoting it a bit: "This statement makes no sense in Haskell (or lambda calculus) since all functions take one argument, and functions with zero arguments are illegal. Does that mean that the ideal function can not exist in Haskell? No, this is an unfair judgment. Uncle Bob wrote this book with an OOP (Object-Oriented Programming) perspective with examples in Java. The point is that many arguments can be hard to use, understand, and can be a smell of too many dependencies. "
    - cush 5y ago
      A simple “no” would have sufficed.
- c0npr 5y ago
  Even if you do not agree with the coding style they propose, it is still useful to know and helps understand others code (and the rationale behind it). It is true though not everything applies nicely.
- cenny 5y ago
  What kind of habits do they advocate that interfere with writing good code? I would love to hear more about this opinion.

cenny 5y ago

The link was supposed to go to an article on the site (https://www.programmingbooks.dev/articles/book_is_wrong/ https://www.programmingbooks.dev/articles/book_is_wrong/)

Jtsummers 5y ago
HN adjusts submissions to use the canonical URL if present in the HTML. Check the source of the page and its canonical URL (on mobile and apparently you can't do view source in iPadOS' Safari).
- erik_seaberg 5y ago
  You’re right, the page has <link rel="canonical" href="https://www.programmingbooks.dev"> which isn’t the canonical URL for the same content.
- deleted 5y ago
  [deleted]
- marcellus23 5y ago
  Tangential, check out Achoo for viewing inspecting the HTML source on iOS https://apps.apple.com/us/app/achoo-html-viewer-inspector/id1585833321 https://apps.apple.com/us/app/achoo-html-viewer-inspector/id...

blueside 5y ago

I think this is one of the better lists out there. I own almost all of the books in this list. But don't get your hopes up too much. I'm still a lousy programmer.

rg111 5y ago

This is a nice list. I will highly recommend The Little Schemer. You will change after reading this book. It is that good. This book made me truly undersy recursion. I understood recursion before, and used it to solve problems, but this is the book that totally scratched my surface and instilled recursion in it. Pragmatic Thinking and Learning is the first book of its kind that I ever read. I was surprised by the quality of it. It is a very nice book with scientific and actionable advice. Will recommend it, too. (Although there are some issues like oversimplified model of brain, divided into L and R mode, and in one place it preached different type of learners theory, which is now thoroughly discredited.) For an approachable programming book, i.e. book not CLRS, Skiena, or DPV, I will not recommend Grokking Algorithm. I will recommend A Common Sense Guide to Data Structure and Algorithm from PragProg Bookshelf. This is a much better and more complete book with exercises that are effective in learning the topics well.

cenny 5y ago
Thanks for the feedback and nice words! I will look into “A Common Sense Guide to Data Structure and Algorithm” and see if I agree with you. But yes, little schemer is so good, wished I read it earlier than I did.