25 ms·

Bugs emerge. Tools change. How do you update code printed in a book? If a book can be written in such that it does not need to change, then by all means, care

by jmull 3y ago

Bugs emerge. Tools change. How do you update code printed in a book? If a book can be written in such that it does not need to change, then by all means, carefully proof and test all the code and hard code it into the book. But that's simply feasible in many cases. Better a book with some external resources than no book at all? (Oh, and let's set aside the cases where the links to external resources are done in a horrible, broken, poorly conceived way. That's frustrating, but it's not like a book with no external resources produced by those authors/editors wouldn't still be horrible, broken, and poorly conceived.)

lewispollard 3y ago
Print code in the book, and have a URL you can check for errata. That's how it always used to be done, anyway.
- jmull 3y ago
  Fine with me. (op would still object, though, because their issue is "The URLs always break. The libraries never load properly. A book should never depend on a URL")
kragen 3y ago
this is a fully general criticism of printing anything in a book; it's not an argument against printing code in books, but against books themselves
- jmull 3y ago
  I really don't think you read and understood my post. I thought I made it clear, but I'll try again: There are two cases. One, where a book can be written in a self-contained manner, without urls to external resources. As you can see, I am happy with this case (which means you really can't conclude I'm criticizing printing thins in a book.) And another case where it isn't feasible to write the book in a self-contained manner. In that case, the choice is between a book with urls to external resources or no book at all. OPs blanket stance against URLs in books is short-sighted because the only way it can be realized is to simply have fewer choices of books. Probably OP should argue that books should have as few urls to external resources as possible, and the subject of those urls should be inherently dynamic and fundamental to the book, and the book should include a credible plan for maintaining the external resources for the useful lifetime of the book (which could be a long time). Sorry, this may be too nuanced for the internet.
  - kragen 3y ago
    it's possible that you didn't understand my counterargument, since your clarification isn't relevant to it this logic doesn't draw any distinction between code and natural-language text; it's true that it's a somewhat restricted argument against printing things in books, because it doesn't argue against printing 'self-contained' things that 'don't need to change' in books. but it's an argument against printing natural-language text in books to exactly the same extent that it's an argument against printing code in books ironically, it works much better as an argument against printing urls in books than as an argument against printing code in books. c or c++ or java or perl or javascript printed 25 years ago still works fine, but most urls from 2 years ago are already broken. natural-language text written about the c++ or javascript code 25 years ago is somewhat more likely to have become incorrect than the code is python is an exception here, since it's been taken over by the sort of fashionistas who wouldn't be caught dead wearing last season's standard library, and are actively taking steps to sabotage backward compatibility

by jmull 3y ago

lewispollard 3y ago

Print code in the book, and have a URL you can check for errata. That's how it always used to be done, anyway.

jmull 3y ago
Fine with me. (op would still object, though, because their issue is "The URLs always break. The libraries never load properly. A book should never depend on a URL")

kragen 3y ago

this is a fully general criticism of printing anything in a book; it's not an argument against printing code in books, but against books themselves

jmull 3y ago
I really don't think you read and understood my post. I thought I made it clear, but I'll try again: There are two cases. One, where a book can be written in a self-contained manner, without urls to external resources. As you can see, I am happy with this case (which means you really can't conclude I'm criticizing printing thins in a book.) And another case where it isn't feasible to write the book in a self-contained manner. In that case, the choice is between a book with urls to external resources or no book at all. OPs blanket stance against URLs in books is short-sighted because the only way it can be realized is to simply have fewer choices of books. Probably OP should argue that books should have as few urls to external resources as possible, and the subject of those urls should be inherently dynamic and fundamental to the book, and the book should include a credible plan for maintaining the external resources for the useful lifetime of the book (which could be a long time). Sorry, this may be too nuanced for the internet.
- kragen 3y ago
  it's possible that you didn't understand my counterargument, since your clarification isn't relevant to it this logic doesn't draw any distinction between code and natural-language text; it's true that it's a somewhat restricted argument against printing things in books, because it doesn't argue against printing 'self-contained' things that 'don't need to change' in books. but it's an argument against printing natural-language text in books to exactly the same extent that it's an argument against printing code in books ironically, it works much better as an argument against printing urls in books than as an argument against printing code in books. c or c++ or java or perl or javascript printed 25 years ago still works fine, but most urls from 2 years ago are already broken. natural-language text written about the c++ or javascript code 25 years ago is somewhat more likely to have become incorrect than the code is python is an exception here, since it's been taken over by the sort of fashionistas who wouldn't be caught dead wearing last season's standard library, and are actively taking steps to sabotage backward compatibility