[distcs]

I never understood these books. Who reads a 1000 page book to learn a programming language? I bought this particular book some 10 years ago hoping to "master" javascript. The book was so dull that I could not even get to the 3rd chapter. There are books about much more complex subjects that wrap up in < 400 pages. What's really the market of these doorstop books?

[sanitycheck]

There's a lot of value to having "everything in one place" during the learning process and later for reference, plus the convenient dead-tree format means bookmarks are instantly accessible. They're also written by competent people and edited by professionals. I'm a fan.

Of course when one's chosen tech is too new, and/or moving faster than the book publishing process then one is stuck with Stack Overflow, random blog posts and insufferable YouTube vids. Which all also go out of date within a year.

[andylynch]

It’s mostly gone now with the Web but having a go to book used to / can still be a really good reference. In the nineties ones like the Camel book for Perl were practically required reading in their fields.

[dspillett]

> I never understood these books.

How long have you been in the industry?

They don't make a lot of sense now, reference material is generally kept in electronic form, often online not locally, both because it saves resources (paper, space to store it) and because things change and online content is so much easier & cheaper to keep up to date. That and things change faster ATM in most tech fields.

But think back to the late 90s when many, even devs, had little more than a slow and expensive (per-minute phone call costs) dial-up connection that blocked other calls while active, and having a local resource that you could flick through to find details makes a lot more sense. Also not having convenient easily portable devices with which to store and read the information makes a huge difference. Even if you did have a laptop it was bulky and the screen was not particularly nice to read from. Heck, desktop screens were headache inducing compared to modern kit (imagine a goldfish-bowl like CRT, 14" diagonal, less because you shrunk the display to avoid the really rounded bit at the edge, 15" if you were lucky, 17" if you were rich, displaying at 640×480 or maybe 800×600 resolution (maybe 1280×1024, again: if rich), in 16 or 256 colour depth so no font smoothing, with a pretty low refresh rate) making reading the information from the book much more pleasant even if you did have a local online copy at your fingertips.

Those books tended to have three parts and you weren't expected to read them all cover to cover:

1. Fundamentals, which you would probably read fully unless you had a fair amount of relevant experience of similar languages/environments in which case you'd skim to pick out the key differences.

2. Specific parts in detail, which you would read some sections of but ignore others until you needed them later. This might include worked examples of using common parts of the standard library and so forth.

3. Reference detail. This might be half the book or more, maybe two thirds in some cases. This you would not read as such, you would use it like a dictionary or mini-encyclopedia. That is the part that makes least sense in the modern world.

If you want a really extreme example: I had a copy of the the MS's C/C++ compiler, the full documentation for included a printed reference to the Windows API of the time (Win 3.x era). IIRC that stack of books, piled on the floor, came up to noticeably more than half my height. The vast majority of that was tools and API reference material, though small chunks were intended for more end-to-end reading.

The huge books did seem to hang around beyond their really useful period. I don't think I bought a dead tree like that as late as 2010, so your “about 10 years ago” is probably when they were well past prime. Even in their prime there were some really terrible examples (poor tutorial sections, reference sections that were out of date before they were even published, and full of errors on top of that).

[ttfkam]

Yeah, a lot of younger folks don't get this. In 1995, the web wasn't like today, only slower. There were no web search engines, only catalog pages like Yahoo. Documentation was often so hard to come by, View Source really was your only option if you wanted to learn newer techniques. That AND it was slow: a 14.4 modem downloaded 1MB every 10 minutes under optimal conditions (no one called while you were connected).

CGI.pm was king.

[jasomill]

While the modern Internet has certainly changed how documentation is published, your suggested three-part breakdown seems as relevant today as it did when documentation was mostly delivered in print.

It's also worth pointing out that being able to skim comprehensive, reference-style documentation to get a general overview of a technology without getting bogged down in irrelevant-for-present-purposes detail is a useful skill to learn.

“As the art of reading (after a certain stage in one’s education) is the art of skipping, so the art of being wise is the art of knowing what to overlook.”

— William James[1]

[1] https://archive.org/details/theprinciplesofp00jameuoft/page/...

[dave333]

At the time there wasn't really a good search engine, Yahoo's hierarchy of interesting sites was just starting. No Slashdot and no Google to find it to see how to do things or fix particular problems. Not much OSS to take as an example. Online doc was dry and limited. Blogging only started in 1994 so not much out there yet. But as the web took off books quickly became almost irrelevant.

The framework obstacle course for developers took off. My particular path through it was POJS, YUI-ext, EXTJS, Dojo, jQuery, Backbone, Angular, React - probably about 2 years each give or take.

[pmontra]

They were also language references. What we are googling now was in those books back then. The second half of 90s was the tipping point between books and web docs. Books were at least 6 months behind the web docs and web technology moved faster than today. It was less wide in scope but it changed a lot. Think about the times when Javascript changed a lot in the early 2010s. It was something like that.

[afandian]

I have a dead-tree copy of the JVM Specification. I'm never going to need it, but it's a fascinating read and stands up well as a book.

https://docs.oracle.com/javase/specs/jvms/se17/jvms17.pdf

[teh_klev]

You could dip into sections of these books and pick and choose what you needed to learn. I don't think I ever read most of the three or four hundred books I bought in the period from 1985 to 2006 in a linear fashion. By 2006 I'd mostly switched to learning new stuff from online sources.

[joeframbach]

> Who reads a 1000 page book to learn a programming language?

Uh, I did, in 1999. My parents would drive me to Barnes and Nobles and I sat there and read the definitive guide cover to cover.