James Duncan Davidson: Trying Something New
If you use Tomcat or Ant (and seriously, what Java developer doesn't?) then you're familiar with James Duncan Davidson's work. At Sun, he was instrumental in open sourcing these projects and donating them to the Apache Foundation. He also authored the first two versions of the Servlet API, as well as the Java API for XML Processing. After leaving Sun, he took up Mac OS X development, authoring Running Mac OS X Panther and co-authoring Running Mac OS X Tiger, Mac OS X Panther Hacks, Cocoa in a Nutshell, and Learning Cocoa with Objective-C, 2nd Edition.
1. Last we saw of you, you were the "Mac desktop apps in Cocoa" guy. Now I see on your blog that you're heavily into Rails. How did that happen?
I was poor and desperate and needed the cash. I'd just bought a new house and my mortgage payment was coming due--oh wait, you want me to be serious? Well, the truth of the matter was that some friends of mine and I have been wanting to work together for a while. And when the time was right and we did the technology evaluations for the project, Rails came up on top. And this was even before I'd used Rails or Ruby. But I wasn't about to let a little required learning keep me from doing the project. I've learned three, maybe four languages this year. I no longer believe in one language to bind them all. If I need to learn a new one to do something, I'll buckle down and learn it.
2. What got you looking at Rails?
Simplicity, mainly. The ease at which you can get things done. The application that I did the first project on was originally a Java-based web app. Everyone in the room knew that there had to be a better, faster, easier way. Ruby has always been a good language--and an interesting one to boot--so to see this framework built on top of it, well, it deserved attention.
3. Has Ruby's obscurity and Rails' newness been a problem with customers/clients?
Not really. In fact, right now, it's the other way around. There's too many potential jobs and not enough people that have really shipped real Ruby on Rails applications.
4. Why is Ruby so special? Couldn't Rails have been done in some other language? Couldn't it have been done in Java?
There are a few other languages in which you could have done Rails, or rather something like it. Java isn't one of them. Rails gets a certain je ne sais quoi from Ruby and to attempt to exactly duplicate it in another language would be both a loss to what Rails does and to that other language. But certainly the concepts can be well applied in other highly dynamic, dynamically typed languages.
I'm excited, actually, to see other projects implementing some of the ideas that have come out of Rails into other platforms. For example, Django gets a bit of static as a Python copy of Rails, but really, it is it's own beast and it'll be interesting to see how it grows.
Now, I've said that you can't do Rails in Java. That doesn't mean that you couldn't do something equally as cool in Java. The strengths of Java could be applied to a brand new framework in interesting and amazing ways. It's just that nobody has done that yet. Everybody has been too interested in chasing the J2EE cookie to rethink the problem in a drastic and dynamic way. But even if somebody does come up with a killer Java-based web framework that does as much as Rails, it certainly won't look or feel like Rails.
5. Well-designed Java apps survive feature creep pretty well--design your classes and packages well, and you're good for a long time. Can a team write a really big Ruby app? Will it be maintainable? Or is RoR meant for the small consulting gig?
Well-designed applications in any language can survive feature creep well. Badly designed applications in any language don't. There's also the matter of a definition of a really big application. The first Ruby on Rails app that I wrote was deployed into production with less than 5,000 lines of code. I've built the same caliber of application before in other languages and it took 50,000 lines of code. So defining big is a problem.
Can a team write a Ruby on Rails app that performs a large number of features, does it well, and is maintainable over time? Yes. No question. After working with Ruby on Rails for a while, I would be confident tackling any size web application problem with it. But, that's because I've spent some time with it and now have seen that it's possible to write a well-designed application.
That said, there are probably dozens of crap Ruby on Rails applications being written right now. Hundreds or thousands, maybe. If you don't know what you are doing, it doesn't matter what tool you use; you'll write a crap application.
6. So we're back to the web app. Could you use Ruby on the desktop, or are we forever doing our UIs in C#, Obj-C, or whatever the OS vendor blesses?
Well, one part of my life is back to the web app. It's a comfortable spot for me, as I've been doing web-based work since 1994. But I continue to work on desktop-based ideas and applications. And there's still a wide need for them. I don't want Office on the Web. And you certainly can't build something like an Aperture as a web app.
Could you use Ruby to build a compelling desktop application right now? No. The toolkits don't exist for it. But if the right toolkit were there--it's possible. There's nothing about the language that keeps it from being a good desktop application language. That said, I've found that the best way to take advantage of a platform, whether it's an operating system or a web application framework, is to be as native as possible to that platform. For my desktop work on the Mac, that still means writing with Objective-C and using Cocoa. For my web work with Rails, that means using Ruby. For system work, that means C and shell. There is no single answer in this discussion.
And I think that's the real win from the recent attention on Ruby on Rails and the breakaway from viewing the world with Java-colored glasses. It's not that Ruby on Rails is going to be the next Java. Far from it. It's that Ruby on Rails helps to break this idea that there is "One True Way." There's not. There are many different ways to solve a problem. And really, none of them is the clear-cut winner. There's just places where one solution has advantages.
It's like the structures that we work, eat, and live in. Some structures are best built with concrete and steel. Others with masonry. And yet others are best built with timber. Nobody has jumped up and said "All buildings must be built with bricks!" And there's a good reason for that. It'd be stupid. In a similar vein, not all web applications should be built with Ruby on Rails or Django or J2EE or Perl. There's a multitude of tools for any particular job. And there are new ones waiting to be discovered. The trick is determining the best one.
To bring this rant back to your question: in the web application space, it's easier for new frameworks to come along because you're not dealing with things like video cards and GUIs and the overall system in which the application runs. But unless you are willing to build your own framework, it's still a decision as to which one to use. It's the same way on the desktop. You could build your own framework and do whatever you want, but it's a harder proposition than to build a new framework for the Web.