Thanks!

O'Reilly offers the book for sale in a variety of DRM-free ebook formats if you prefer to read it that way: http://oreilly.com/catalog/9780596805531/

My Ruby book is explicitly modelled after K&R. The JavaScript book is also, though not quite so obviously. If you just look at the first 300 pages, the comparison would be more apt. Try to imagine K&R expanded to cover all of the major libraries that C developers have to use today. That would come out at over 1100 pages, too.

After you get through the first 5 chapters, you can kind of pick and choose what to read. Most chapters are 30-50 pages, and you should be able to work through them in an hour or two. Chapter 6, for example, covers objects (including ES5 extensions) comprehensively in 35 pages, and you'd probably come away after reading it feeling like you learned enough to make it worth your time.

Thanks! That was my goal when writing it. It is about language mastery. Not so that you can answer quizzes about obscure corner cases, but so that you can program more effectively. Its like adding tools to your toolbox, and keeping them sharp.

Dojo and YUI are too big to cover in one chapter. I mention them, but do not cover them. jQuery is small enough to cover comprehensively in this book. And it is probably more popular than the larger alternatives, so I covered it. Many readers will find that chapter quite helpful. Those who don't want to use jQuery can skip the chapter. I don't use jQuery elsewhere in the book. (The jQuery material is also available in standalone form as jQuery Pocket Reference.) There is just one chapter on server-side JavaScript. Half covers Rhino and half covers Node. Just enough to give readers a taste of server-side programming. And the reference sections don't include reference material for Rhino or Node.

Mod the parent up. This is funny! :-) I wish I could have stopped after the first edition!

Have you read the JavaScript book recently? The 5th edition is an improvement over the fourth... It is different than Java in a Nutshell--simply because it is a "definitive guide" rather than a "nutshell". This Ruby book is probably more like my JavaScript book than my Java books, so if you end up liking it well enough, maybe you'll give the JavaScript book another chance :-)

Frankly, I don't know the reason that constants are not constant. I could have pressed Matz to enlighten us on this point, but I suspect that the answer is not a simple one and would have been difficult to explain. In earlier drafts of the book I did actually draw attention to these rough spots in the language because they did, indeed, seem strange to me. As I spent more time with Ruby, however, I came to appreciate it more, and re-reading my drafts I felt I was being unnecessarily critical of the language I was documenting. So, as you surmise, I was left just being matter-of-fact about it.

This is not a very common idiom, nor is it even very well known. The particular line of code you cite is, of course, extreme: I'm taking the destructuring parallel assignment syntax to an unreasonable level of nesting to test the reader's understanding of the concept. Its not a common idiom, but it is part of the language, so I document it. It actually seems pretty cool to me, not really an elephant in the room. In this case, were I writing a less formal book, I might have commented on how cool it is. In the same way, in a less formal book, I could have commented on how strange it is that constants can have their values changed.

Please keep in mind that we had to get these drawings through the internal bureaucracy at O'Reilly--we were asking a lot of the production and design teams to include them. I shouldn't speak for _why, but I think his goal for these drawings was to keep it mellow, and to be stylistically distinct from his work for the Poignant Guide.