Glenn Vanderburg: diggin' Ruby
Glenn Vanderburg: diggin' Ruby
Join the DZone community and get the full member experience.Join For Free
Glenn Vanderburg, a well known speaker in the NFJS symposium tours, has been in the IT business for more than 20 years, with plenty of experience with several programming languages, also an early adopter of Ruby east side of the Pacific. Continue reading to learn about Glenn's point of view on Ruby, JRuby and Java. Enjoy!
[img_assist|nid=2516|title=|desc=|link=none|align=right|width=180|height=224]Andres Almiray: Glenn, can you tell us how you got into Ruby ?
Glenn Vanderburg: I live in the Dallas area, not too far from Dave Thomas. In mid-2001, we were both regulars at a monthly programmers' lunch at a nearby barbecue joint, and Dave mentioned that he and Andy were finishing up a book about Ruby. Later that year I went to the OOPSLA conference in Tampa, and it turned out that Programming Ruby was released there at the conference. As far as I'm aware, I bought the first copy that was ever sold.
Ruby was still a bit immature in those days, but I immediately liked it, and started finding ways to use it in my work. For a while it was in non-production roles (automation scripts, small code generators, and tests). But before long I was looking for ways to work in Ruby full-time, which finally happened in late 2005.
Andres: Is there a feature on Ruby you can't live without ?
Glenn: Definitely! For me it's the fact that classes in Ruby are simply objects, not fundamentally different from other objects in the language. The ability to manipulate them at runtime is a huge advantage.
For a while as a Java programmer I was a fan of aspect-oriented programming. But I soon learned that average programmers had difficulty with it. It required learning special APIs or even a special sublanguage, and required thinking about programming in a different way. In Ruby, with classes as real objects and the close relationship between methods and blocks, it's possible to do the same kind of powerful metaprogramming, using mostly the same kinds of programming facilities and techniques that you use for the rest of your development. And that makes metaprogramming accessible to every member of your team.
In most other languages, metaprogramming is seen as a specialized activity, but most Rubyists come to see it as just part of our refactoring toolkit, as another set of options when trying to remove duplication or encapsulate complexity.
Andres: Is there a feature from another language you'd like to see in Ruby ?
Glenn: This is a good question, but it's difficult to answer. Ruby already has features borrowed from nearly every language under the sun! What makes it work is that Matz has chosen features that work well together, and most people radically underestimate what a difficult, sensitive task that is. So while there are some features from other languages that I occasionally wish I had (Smalltalk's method naming syntax that makes the role of each parameter very clear, or Icon's goal-directed evaluation), they just wouldn't mesh well with the rest of Ruby.
The big thing is something like Lisp's powerful macros. I know Ruby's rich syntax makes that difficult, and I certainly wouldn't want to give up that syntax, but I'm hoping we can eventually have something like a real macro facility.
Andres: What about DSLs ?
Glenn: Well, Ruby-ish internal DSLs are just one way of applying metaprogramming to solving your problems. The DSLs in Ruby that get the most attention are probably the persistence declarations in Rails (has_many, validates_whatever, etc.). But the nice thing is that, while they're beautifully designed with a lot of taste, the implementation isn't really anything remarkable: they're just methods, defined on the class ActiveRecord::Base. Once you have blocks and classes as real, first-class objects in the language, things like that just become natural.
Andres: How do you see the landscape of web development now that Rails has established itself as a viable alternative ?
Glenn: Web development is still a pain, but it's not nearly as bad since Rails came along. (And that's true whether you're using Rails or not -- nearly every web framework has learned from Rails and adopted some of its ideas.)
I like to describe Rails as "more broad than deep." It's unusual in addressing so many pieces of the web development puzzle (HTML generation, request dispatching, persistence, deployment, testing, email interaction, web services, and more) in one framework. But unlike some frameworks that try to solve the problems they address to the nth degree, Rails solves the most commonly encountered 80% or so and leaves the rest up to you. Rails' abstractions leak like sieves -- on purpose -- so that you can take control and solve those edge cases yourselves.
And that turns out to be a fantastic approach to take. Web development is still changing, and there's still a lot we haven't completely figured out. The common 80% can be solved in a simple way, but to solve the remainder of the problem in a general way that everyone can use ends up being extremely complex (and you can see that complexity in some of the other web frameworks out there today). Rails' answer is to let individual projects solve those problems in specific, context-dependent ways, and that usually turns out to be pretty easy.
I suspect the time will come when the web as a platform will settle down, and we'll understand the task thoroughly enough that a 100% solution can be simple, comprehensible, and robust. But I think it's too early for that now, and I love the fact that Rails doesn't get in my way when I need to go deep and really get my hands dirty.
Andres: Is there something you miss from the Java world ?
Glenn: My instant reaction to this question was "not a thing!" That reaction shocked me; I was a huge fan of Java from the first time I touched it in early 1995 until just a few years ago. So before answering I tried to give it some really serious thought.
The truth is, there are some things I miss -- but I don't miss them as much as I would've expected just two or three years ago. All languages have flaws and weaknesses. It's not about finding a perfect language or platform; rather, it's about sensibly weighing advantages and disadvantages, strengths and weaknesses, risks and rewards, all in the context of the kinds of projects we're dealing with. Once in a while, I miss the implicit documentation that static typing gives you, although most of the time it's simply not an issue, and the strengths of dynamic typing make the tradeoff a no-brainer, in my opinion. But just today I was missing Java's rich, mature, cross-platform 2D graphics model. Your work with GraphicsBuilder in Groovy is a great example of why that's a strong feature of the Java platform. I hope someone in the Ruby community will follow your lead and build something similar atop SVG or Flash.
Andres: What are your thoughts on JRuby ?
Glenn: JRuby is a fantastic project. Charles, Tom, and Ola (and many other contributors, of course) have done a wonderful job with it. I'm a happy user of Matz' Ruby implementation, and haven't used JRuby on a real project yet -- but I have friends who are very happy users of JRuby, and I'm sure I'll have a project before too long for which JRuby is the most sensible solution.
I'm excited about all of the Ruby implementations: YARV, JRuby, Rubinius, and IronRuby. I think it's a great thing for any programming language to have multiple implementations, and it looks nearly certain that the Ruby community will be able to boast four independent implementations soon. The best part is that these teams are helping each other build a specification for the Ruby language and core libraries -- an *executable* specification that really describes the language definition. I don't see how that can be anything but a huge win for our community.
Andres: Do you have any words of advice for people starting up with Ruby ?
Glenn: First, it's well worth your money to buy a book. Ruby has a different philosophy from the languages most programmers are familiar with, and it's hard to make a such a large shift from examples and online tutorials. I'm a big fan of Dave Thomas' books (Programming Ruby and Agile Web Development with Rails) but there are other good ones as well.
Second, spend more than a couple days with Ruby. Learning a new programming language involves learning new ways of thinking about problems, and that doesn't come easy. No language is perfect, and at first you'll be most likely to notice a new language's flaws. It takes longer to appreciate the strengths, because you aren't used to using those features in your problem solving. Java programmers trying Ruby for the first time might start to feel comfortable with the basics after a day or two, but in most cases they'll still be writing Java-like code, just with a different syntax. When I'm learning a new language, I try to immerse myself until I reach the point where I look at my code and think, "Wow, it would be hard to figure out how to do this in my old language." That's when I know I'm starting to really get it.
Learning a new language or platform can be hard work, but it pays off like crazy, whether by opening up new opportunities or just by making you a better programmer where you already are. About a year ago, right after the iPhone was announced, I ran into a former colleague and naturally we began talking about the cool new device. At one point he said, "Yeah, but it doesn't support Java, so I can't do anything with it." That's only true if you think you can't learn anything new; it's a sad, self-limiting attitude to take. Whether you learn Ruby, Python, Scala, Groovy, or something else doesn't really matter. Just make time to learn something new every two or three years, and your career will be better for it.
Andres: Emacs, vi or TextMate ?
Glenn: Emacs! No, TextMate! No ... wait, what day is it?
I've been an Emacs guy for 20 years, and I still love Emacs and use it every day. But TextMate is wonderful as well; it's the first editor that's *ever* lured me away from Emacs on a regular basis (and that includes Eclipse and IDEA). It's beautiful, rich, and pragmatic, and for Rails development it can't be beat.
The short answer: both Emacs and TextMate make me smile every day, for very different reasons.
Glenn Vanderburg is Chief Scientist at Relevance. Relevance provides consulting, training, and development services for Ruby, Rails, and Ajax, among other things. Glenn has over 20 years of experience as a professional programmer, and is still finding new ways to build compelling, high-quality systems that make customers happy. He writes Ruby most of the week, but recently he's been spending Fridays learning Objective C and writing software for his iPhone.
Opinions expressed by DZone contributors are their own.