4 ms·

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

by 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

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