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.
If you read this book cover-to-cover (well, except for the hefty reference pages), you will be a JavaScript expert.
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.
Well whilst the author is here, and while I'm part way through the book, let me ask a couple of questions. I should preface this by saying that I think Javascript the Definitive Guide made me hate Javascript all the more, while Java in a Nutshell and Java Examples in a Nutshell seemed to exemplars of good programming books. So needless to say I've puzzled over David's writing over the last few years. Why do I have such mixed feelings about books by the same author? I still don't know but maybe the following questions will help. 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:-)
I was reading along today when I came to this: "Assignment to a constant that already exists causes Ruby to issue a warning. Ruby does execute the assignment, however, which means that constants are nor really constant." Now this is a bit of a surprising statement. Isn't this an elephant in the room? Shouldn't it get more of an explanation? 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.
A few pages further on, while discussing parallel assignment, we get this: "a,(b,(c,d)) = [1,[2,[3,4]]] # Parens: a=1; b=2;c=3;d=4". Now I can figure out what is happening and what the book is trying to explain. But at the same time the book seems to ignore a second elephant in the room. Why in the world would someone ever write just a difficult to comprehend statement? Is is a common Ruby idiom? If so might it not be wise to offer some explanation of why it's an idiom? 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.
And one last, sort of unrelated question: is anyone else disappointed by the drawings? When I read that the book would be illustrated by whytheluckystiff I thought that this would make a probably good book even better. But I find them very disappointing and far less visually interesting than what can be found on whytheluckystiff's web site. 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.
almiray,
As its title implies, this book is strongly focused on the language itself. It includes one (long!) chapter on the core platform, but it hardly touches on the standard library.
Since Ruby's testing frameworks are not part of the language or of the core API, I do not cover them. That doesn't mean that they're unimportant, just outside of the scope of this book. This is not a book about programming methodologies, or about web application development, or about design patterns. But it does cover the Ruby language in detail.
"Unreadable" is a pretty subjective opinion. If you didn't like JavaScript: The Definitive Guide, then you probably won't like The Ruby Programming Language, either. But many people do like my JavaScript book and consider it the definitive book on the language. I've tried to do the same for Ruby in this book.
This paper is published at a unrefereed repository for any old papers. It references the aleged paper in Foundation of Physics Letters, but it is not that paper. (Which I suspect is a hoax.)
Googling "Peter Lynds" reveals that someone is working hard in online forums to get that name out there. Smells very fishy
The new foundation gets $2M over 2 years from AOL.
Plus, Mitch Kapor kicks in $300K and becomes chair
of the foundation. AOL also continues to supply infrastruture and "domain names". (How generous!)
I'd say AOL wants to be rid of Mozilla. I wonder where this leaves Netscape? Is Netscape 7.1 the last browser release from this former browser company?
The book In The Absence of the Sacred by
Jerry Mander is a critique of technology, and includes a long chapter about computers. Somehwat dated (1991) but useful stuff from a philosophical angle.
Also, farmer/poet/essayist Wendell Berry wrote a short, widely ridiculed essay years back entitled "Why I am not Going to Buy a Computer". It contains interesting criteria for accepting new technological innovations. Google reveals an online version of the essay
here.
Its short and worth reading. You should really buy the whole excellent book: What Are People For?
Slashdot Mirror
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.
If you read this book cover-to-cover (well, except for the hefty reference pages), you will be a JavaScript expert.
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.
If it's "The Definitive Guide", how can there be a 6th edition? I mean, a first edition would suffice if it was truly definitive...
Mod the parent up. This is funny! :-)
I wish I could have stopped after the first edition!
almiray, As its title implies, this book is strongly focused on the language itself. It includes one (long!) chapter on the core platform, but it hardly touches on the standard library. Since Ruby's testing frameworks are not part of the language or of the core API, I do not cover them. That doesn't mean that they're unimportant, just outside of the scope of this book. This is not a book about programming methodologies, or about web application development, or about design patterns. But it does cover the Ruby language in detail.
"Unreadable" is a pretty subjective opinion. If you didn't like JavaScript: The Definitive Guide, then you probably won't like The Ruby Programming Language, either. But many people do like my JavaScript book and consider it the definitive book on the language. I've tried to do the same for Ruby in this book.
Thanks for the kind review Slashdot! Thanks, Brian!
You can browse the table of contents of the book and read the beginning of each section at O'Reilly's website.
You can find another review of the book at rubyinside.com
This paper is published at a unrefereed repository for any old papers. It references the aleged paper in Foundation of Physics Letters, but it is not that paper. (Which I suspect is a hoax.) Googling "Peter Lynds" reveals that someone is working hard in online forums to get that name out there. Smells very fishy
I'd say AOL wants to be rid of Mozilla. I wonder where this leaves Netscape? Is Netscape 7.1 the last browser release from this former browser company?
Also, farmer/poet/essayist Wendell Berry wrote a short, widely ridiculed essay years back entitled "Why I am not Going to Buy a Computer". It contains interesting criteria for accepting new technological innovations. Google reveals an online version of the essay here. Its short and worth reading. You should really buy the whole excellent book: What Are People For?