Rails TakeFive - Five Questions with David Flanagan, Part 1

Welcome to the Rails TakeFive interview series, where we "sit down" with leading developers from the community and bring you their insights into all things Ruby + Rails. This week, we'd thought we'd mix it up a little with Campfire, and invite FiveRuns developer, Rubyist and Raconteur Adam Keys to join David Flanagan, noted programmer and author who recently teamed up with Matz to write The Ruby Programming Language.

David and Adam had so much to talk about, we'll break the interview into two parts. This week - Part one, on the book.

Adam K.	OK, here goes.
Adam K.	Obviously, you recently finished the new O'Reilly Ruby book. It's quite a tome. :)
Adam K.	How did you approach documenting Ruby given the plurality of implementations these days?
David F.	It actually first came out back in February, so not quite so recent. But thanks for calling it a tome. That's good, isn't it? :)
Adam K.	It's good! I've been doing Ruby for three years, but I still found useful ideas in it.
David F.	I stuck pretty closely to MRI and while learning about and documenting Ruby 1.9 I was working with daily SVN snapshots. I tried JRuby a few times, but since their goal is to be compatible with MRI, I just stuck with that implementation. (Also, when I was working in 2007, Rubinius wasn't really ready for primetime.)
David F.	I'm happy to hear that it is valuable to even someone with your experience.
Adam K.	JRuby is an interesting case. I noticed that, for instance, you noted JRuby has chosen not to implement continuations and you guide folks towards using fibers instead (even on Ruby 1.9). What's your opinion on JRuby choosing not to implement parts of the language that don't suit them?
David F.	In the case of continuations, my understanding is that it was actually impossible for JRuby to implement them and still run on the "bare metal" of the JVM. That is, in order to do continuations, they'd have to implement a Ruby virtual machine on top of the Java Virtual Machine, and that would have unacceptable performance impact. Charlie Nutter coordinated with the core Ruby developers on this. Obviously, perfect compatibility is the ideal. On the other hand, having multiple implementations helps to demonstrate what features of the language are problematic. I think that is what happened with continuations. (And fortunately, most of us will never have to work with continuations or fibers directly!)
Adam K.	I was unaware of that design goal, so that's good to know.
Adam K.	You've been hanging out a lot on the ruby-core list and even contributed a patch or two. I'm betting that background helped a lot when it came time to explain features like fibers. Yours was the first explanation of the topic that really clicked with me. What parts of Ruby did you find most challenging to explain?
David F.	Fibers and continuations certainly are tricky. But most developers don't need to use them, so I can kind of bury them at the end of a chapter with some kind of "you don't really need to read this now" note.
David F.	The notion of blocks works no naturally in Ruby that it isn't all that hard to explain. Things get trickier when I've got to explain blocks as closures. Things like explaining the & before a lambda or before the name of a method argument get tricky. Explaining how return, break, and next work when used in a block is tricky--I had to resort to diagrams (in Chapter 5) for that.
Adam K.	Yeah, blocks are almost as good as sliced bread, but I certainly fully grasp them when I started to use Ruby. Hopefully a lot of people will read you explanation and come away loving them, demanding them in every language they use in the future!
Adam K.	I recently spoke at OSCON about stealing ideas from other languages and using them in Ruby. One of those ideas was prototypal inheritance. Given your experience with JavaScript, what do you think about the idea of programming in the prototypal style with Ruby?
David F.	I do still hang out on ruby-core, though I'm participating less these days. I found that to really understand the language well enough to document I had to familiarize myself with the MRI source code. And once I'd done that, it was often easy enough to submit patches when I'd discovered a bug or had a feature request. After I did that a few times, Matz was kind enough to give me SVN commit access. My biggest contribution is the code for handling \u Unicode escapes in strings.
David F.	I'm not sure how JavaScript-style inheritance would mix with what Ruby already has going on. Having to explain eigenclasses (that's another tricky part to explain!) and a prototype chain might be too much.
David F.	On the other hand, ECMAScript 4 (aka JavaScript 2) is going to have class-based inheritance and prototype-based inheritance, so maybe it can be done. I'd say we wait and see how it works out in that language.
Adam K.	What about how programming with prototypes turns the idea of class-based inheritance around; how has that changed how you look at programming? Is there anything Rubyists could learn from there?
David F.	It's funny you should ask this: I've just been working on updating some example code in my JavaScript book where I try to simulate class-based inheritance in JavaScript. Now you're asking me to think about prototypes in Ruby :-)
Adam K.	It's all about turning one's brain inside out!
David F.	They are certainly very different models. I suppose that being exposed to JavaScript helped me to see that OO doesn't have to mean rigid class-based OO as it is done in C++ and Java (or as it is done less rigidly in Ruby).
David F.	Prototype-based inheritance seems to work just fine in JavaScript as it is typically used. JavaScript 2 is designed to support "programming in the large" and adds "real" classes. If I had to choose only one, I'd stick with class-based inheritance, I suppose.
Adam K.	When I was researching my talk, I found that the main challenge in programming with prototypes in Ruby is not typing the class keyword.
David F.	Ruby is already a multi-paradigm language, so it might be neat to have prototypes in there, too.
Adam K.	That's probably an area where BasicObject in Ruby 1.9 will come in handy.
Adam K.	So in researching the book, were you able to use the Ruby spec project that's grown out of Rubinius to resolve any ambiguities?
David F.	Ah... I think I'm beginning to see where you're going with this... Are you talking about defining a library that creates a class of objects with prototypes? Or integrating them more deeply into (some future version of) the language so that all objects have prototypes?
Adam K.	For me, it's just about learning a different paradigm. That said, I quite like how simple things are in Io and its uses of prototypes.
David F.	Yes, if nothing else, it is a good brain-stretching exercise to learn about prototypes!
David F.	I missed your question about RubySpec. I didn't use it much while researching the book. It wasn't really complete enough yet while I was in research mode to help me there. But having Matz as a co-author comes with the benefit of being able to pester him for clarifications about ambiguities!
Adam K.	To what extent was Matz involved in the book?
David F.	This book was originally going to be a second edition of Matz's _Ruby in a Nutshell_ book, but it outgrew that format, so we renamed it.
David F.	I did all the writing. Matz served as a resource and a reviewer.
Adam K.	That does sound pretty handy! ;)

David Flanagan is a computer programmer who spends most of his time writing about Ruby, JavaScript, and Java. His books with O'Reilly include The Ruby Programming Language, Java in a Nutshell, Java Examples in a Nutshell, JavaScript: The Definitive Guide, and JavaScript Pocket Reference. David has a degree in computer science and engineering from the Massachusetts Institute of Technology. He lives with his wife and children in the U.S. Pacific Northwest between the cities of Seattle, Washington and Vancouver, British Columbia. David has a blog at www.davidflanagan.com