I don't know what you mean by "catch up with Java" but when I was getting acquainted with Java for the first time, I remember searching all over the place for a good in depth yet terse tutorial only to realize that the official docs and official tutorial were the best thing out there.

Personally I feel I know java from J2EE/2004-5 days After that I have been doing more non tech work then tech work. As a example I missed out on annotations, and everything after that. While I do know what annotations and generics etc do. I feel my knowledge has gaps because I learned it in bits and pieces (read I learnt about it in passing when I need to). As a result I feel the need to 'brush up' - basically looking to feel confident such that I have a good grip on Java as it is today. If you have any specific tips on how I can brush up, I am all ears.

It's driven partly by the economics of publishing technical books.

Technical books are often more expensive to develop; there may be more authors, technical editors, illustrators, etc. working on a technical book. A book may have only one or a few authors listed on the cover, but if you look at the acknowledgements page there may be a dozen or more people involved.

Technical books also typically have a smaller potential audience than other books; you can count the number of technical blockbusters on the fingers of one hand.

As a result, publishers must price technical books relatively high. In order to convince buyers that their book is worth the higher price, they make it longer. In the case of Java books, they throw in huge appendices that cost them very little in development cost. Most Java books include the interface specifications of the complete set of Java libraries; information which is widely available online.

Your best bet is to find a highly rated book, skim the first 50 or more pages to get past the parts where the author explains why his book is the best in the field, then stop reading when you hit the first appendix. I would also recommend buying the e-book version of the book; being able to electronically search through a technical book is hugely valuable.

The answer is quite simple: in a tutorial, or in a book covering technology X, there is necessarily more material, than what is found in the reference documentations and specifications of said technology X. That's because technical documentations are concise (if only to avoid inconsistencies).

Unfortunately, most technologies start with references that are already over 1000 pages! Check any standard or language reference, or framework reference. There are several frameworks with more than 1000 classes! imagine how many printed pages for the reference documatation! A book about those frameworks that wouldn't even be exhaustive could very well be over 10,000 or 100,000 pages.

Buyers evaluate a books price by it's length. That is they're more willing to pay $50 for a 500 page book than a 50 page book.

It's completely irrational, nevertheless it a behaviour that even completely rational people display.

Yes its the 'more is better' mentality. but its a crude one at best. When applied to text media its stupid because I would pay somebody to summarize things for me, instead we are paying people for long unsummarized content that will take more time to digest.

Also why are book prices so high considering I have read so many times on HN that the authors seldom make any money from royalties and publishers have a fixed cost (for the most part).

Nevertheless it's what practically everyone does.

Typically the biggest part of an individual books cost are the retailer margin and publisher profit.

It's also important to note that while the publisher profit margin on an individual book might be high, the publishers overall profit margin tends to be lower because the profits of successful books have to cover the costs of all the books that fail to break even.

I think its an interesting point. Its a volume rather than quality driven approach. Its a shame but I understand it has to be this way considering that quality in this case of a book and its content is a very subjective thing.

It is not irrational. Books, before all else, are primarily entertainment. Programming books don't so much compete with the web on content as on medium: Reading a book, for people who buy books, is more pleasurable than sitting at the keyboard.

You're absolutely right about this. I vastly prefer reading a technical book rather than piecing together information from online sources. I like just sitting back and being immersed in a subject. I enjoy that I get a complete and logical tour of a subject from a book. The length of a book is signal with regards to this (on any technical subject worth reading a book about at least).

What has that got to do with length ? - entertainment value isn't a function of length.

The economics of publishing are such that the authors choose to add every area they can on a given topic so that people won't reject their book for another on the basis of one missing item.

As others point out, it is also a crude proxy that buyers use to evaluate the worth of the book without reading the entire thing.

Of course, there are exceptions. One of the reasons that The C Programming Language by Kernighan and Ritchie is so popular is its conciseness.

I've been reading node.js books and they're around 300 pages.

I mean Java is a freaking huge language. Generics in Java alone is a giant book.

It depends on the tech I guess...

I somewhat respectfully disagree. Java as a programming language, conceptually is not huge. It does have a huge API library. However 'experts' should be able to make it concise - as in what is the object or goal of this lib/package. so the the reader knows 1) whats possible in java 2) if they need to dig deeper they know where to look.

I guess to me the idea is not to know everything, but to know whats possible and where to look.

Why is generics so huge? You can cover it in a chapter, possibly two.

Completely agree with your question. I think if the author can't explain it conceptually in a chapter or two may be the author dosnt know it really well or should employ a ghost writer

The most ridiculous example is the 5th edition of "Learning Python" by Mark Lutz. It's supposed to be an introduction to the Python language and it's almost 1600 pages long. The 1st edition was less than 400, the 2nd was 550, the 3rd was 750 and the 4th around 1200 pages.

It's a very nice book, don't get me wrong, but I think it's intimidating for a beginner.

Agreed. Forget the beginner, even for the person know works with it everyday, it can raise the question about how much they know and lot of it is noise. I can understand if the book is a desk reference - thats a different story. but to learn..come on. I think this thread is common in new papers too...nytimes wsj etc. all thier articles are like 4 pages, when the whole point is to be concise. I do understand that a 4 page article generates 4 times more ad revenue. "The smartest minds of our generation are trying to figure out how to display and get people to click on ads" - :(

Many books are written by multiple authors to reduce the latency to market so there is inherent repetition between the chapters along with the (non-)manditory boilerplate that should be replaced by open content.

More concise, better written content takes longer to write and revise. If I had more time, I would write a better response to you.

As usual, incentives are in the wrong place.

Stroustrup's The C++ Programming Language, 4th Edition is 1,368 pages long. It has a fair amount of repetition, but it makes sense because it gives an overview, then quickly gets more detailed as you go through the book.

Personally, I like that. But then, I love reading computer books.

Back in the days when physical bookshops mattered, you wanted a thick spine on the book to take up more shelf space, and give you more room for a bold title to attract the eye.

A friend who once worked at a bookstore once told me this. The way he put it was: publishers want their books to take up a lot of shelf space so there is less room for the competitors.

As an author, I can say that much of the length of my books/courses comes down to experience in the classroom from the previous teach/course or from feedback I get from students. A contrived example:

1) For product release 2.0 in 2000, I create a 2-day course and write a companion 300-pg book. I teach said course and students say, "Dang... not what I hoped for. It's too much intro and not enough stuff that I can use to accomplish"

2) Marketing/sales team comes to me and says, "We need more beef. The feedback is that people have trouble installing and configuring and, as a result, the rest of the book/course is tough. Also, we need to highlight these new features"

3) Version 3.0 of said software comes out and, to accommodate everything and everyone, the course becomes a 3-day adventure and the book is now 400 pages. The feedback this time is "Okay, now we're seeing trouble at the basics - we need more time spent on x and y"

4) Version 4.0 comes with a 4-day course and a 500-page book. The sales team pushes back and says, "No way we can sell a 4-day course. Make it 3-days. And by the way: don't remove any content!" Yikes - that's impossible. The compromise then is that I keep high-level content (overviews, introductions) to sections and move the content from the course to the book. I then have to expand the book by 100 pages (it's now a 600 page book).

5) Version 5.0 comes out in 2010 and it's a total re-design of the software. There are also completely new features that are very complex. Sales says, "Great job on the last course - don't change anything, just add the new features!" Hello 800 page book!

6) It's 2013 and now every pubs manager knows this cycle backwards and forwards. A new tech comes out and the pubs folks go ahead and tell the author, "Don't bother writing a succinct intro - go ahead and flesh it out. It needs to be at least 500 pages or else people are going to complain that it doesn't have enough meat and weight."

"But Scott, this is your problem. A better author could show in 200 pages what you took 800 pages to show!"

There's simply a minimum amount of time that it takes to teach a topic. It's all about "scope" - if the scope of the book is to teach you the basics to a programming language, it just can't be done in 200 pages for any sufficiently complex language. I think that the way to approach this is to (a) design design an actual in-person training course in which real human students will sit in a room with you, and your job is then to teach them a skill that they will have to take back to their job (which paid handsomely to send them). Given a 6.5 hour training day (9:00-4:30 with breaks, lunch = ~6.5 hours of training time), how many days of training is your course? A given day is probably 150-300 pages in a book. If you try to "Teach Java in 6.5 hours", it just doesn't work. You might need 3-5 days to learn the true basics of the language in such a way that you can "think in Java" (which is the basic starting point). Bam - 1000+ page book.

May be I am being a typical engineer, but looks like sales and marketing, as usual, work in a 'vacuum' and as a result the impact to the overall outcome can be somewhat negative. while the course might be successfull (read it made the money it set out to), its systemic effect is incentives are placed in the wrong place.

I feel more and more we are seeing the need for technical sales and technical marketing people, basically people who understand both sides.

None the less its an interesting problem. Would love to attempt to disupt it by providing real value.

I can say that, in my experience, the sales/marketing folks are never truly technical people; they are sales/marketing people who've been trained about the basics of the technology. However, every company I've worked with always has a technical person review important things like table of contents, chapter outlines, and such. And then there's almost always a technical editor. To what degree they "work" is dependent upon many factors though.

I think sales/marketing work, in this regard, as a response from their customer base. If people are saying, "Well, we would spend $30,000 to send eight people to this class if only it featured generics", then what do you think happens next? Big money talks. That's why so many mature products that have "new features" are often features that less than 1% of the companies would use - that 1% of user sales represents 20% of revenue (or something to that effect). It's fine to wax philosophical and debate, "What should a training course or book do?" However, the companies writing the big checks almost always determine what goes in and to what degree. It's hard to sell a training course using phrases like, "We'll teach you the things that you won't use in your real-world job!"