KM: What are your thoughts about Rails, and do you have a favorite scripting language?

CM: It's interesting that you would ask this one ... I've been spending quite a bit of time looking at Rails, and other application architectures based on scripting languages, over the last few months.

About Rails in particular:

• I'm a big fan of the distributed view controller architectural approach, so I'm liking that aspect of Rails quite a lot.
• Convention over configuration has already been a powerful influence on thinking in the Java world, because it really does improve productivity. Rails leverages this idea all over the framework.
• Rails can do a lot of its magic by leveraging the capabilities of Ruby as a language—such as injecting the data of a controller into the view so that it can be accessed directly, instead of having to use binding expressions of some sort. That translates to not only less code in your applications, but also less conceptual weight on the developer having to remember to keep changes synchronized. That's going to be difficult to emulate in a strongly typed language like Java.
• Don't believe the people who tell you Rails is just a toy, based on the fact that the 15-minute demos just use the scaffolding. You really can build sophisticated apps pretty quickly. As the name implies, the scaffolding is there to help you during construction, and is typically not a part of the finished product.
• Don't believe the people who tell you Rails cannot deal with application maintenance over time, including things like database schema changes. The support for this is well thought out, especially in 1.2's migrations. And, the fact that you don't have to explicitly modify your model classes is quite nice.
• Don't believe people who tell you that Rails stops being effective when your database schema doesn't match Rails conventions. They can be overridden. At worst, you have to go implement explicit properties, which ends up looking like what you *always* have to use with ORM layers like JPA or Hibernate.
• All of the above being said, Rails has quirks and things you need to get used to. As DHH likes to say, Rails is opinionated ... if you're going to use it, going with the flow is going to save you lots of frustration. (The closest analogy I can think of in the Java world is how Maven is pretty opinionated about how project builds should work; it lets you do things differently, at the cost of having to continually tell Maven about it).
• In addition, there are some aspects of large scale applications that are not (yet?) addressed in Rails (robust support for localization, multiple database coordinated transactions, and so on). But I wish the Java world had more deployment support solutions like Capistrano, to better manage (say) 100 instances of my application in an automated way.

From a language favorite point of view, I've resisted scripting languages for a long time—I liked the comfort zone of strong typing, and getting help from the compiler in catching potential mistakes (plus niceties like code completion in tools). I also really like objects, so things like Java are appealing to me. That being said, the productivity gains you can get from using a scripting language correctly are impressive.

I've spent the most time recently looking at PHP, JavaScript, and Ruby. With PHP, I still shudder too much at how it tends to get (mis)used, although clearly people can be successful with it. For JavaScript, it's a real love/hate relationship ... love the flexibility, hate the debugging environment on the client :-). But the flexibility has a down side, too—when you can play games with prototypes and change the fundamental nature of Object, I start to shudder again.

Of the languages I have looked at, Ruby seems to capture a nice balance between flexibility and object orientation. The syntax is pretty quirky, and you can still do some "black magic" things that can mess you up, but it's much more constrained ... and it's easy to do the right things.

KM: What about Groovy and Grails?

CM: I haven't spent as much time on Groovy. The last time I looked at it seriously, they went and changed a bunch of the syntax :-). Now that the language is settling down some, it's definitely time to take a look again.

Groovy, since it runs on the VM, will have a nice capability to integrate with existing Java based server side functionality. This will be attractive to Java developers looking for a lighter weight way to build web front ends for application environments with sophisticated needs that Rails and similar frameworks (including Grails) don't yet support. I'm just not sure how attractive Groovy will be outside the existing Java developer base—yes, there are lots of Java developers, but there's a lot using other languages too. Will enough of them know Groovy even exists to make it a viable choice? Time will tell.

KM: So, would you say that Sun is focusing more on non-Java audiences these days?

CM: I would say we're adding additional audiences as targets. We've had really solid support for Java developers for quite a while (including, for example, the support for Java EE 5's new features in NetBeans 5.5), and we'll continue to improve that support in NetBeans 6, most notably in areas like the text editor, which is dramatically improving.

At the same time, there is an opportunity to make NetBeans an attractive developer platform for people who like technologies in addition to (or even instead of) Java. The fact that existing developers need to be fluent in additional technologies (such as Javascript if you are building webapps) is more true today than ever, and the advent of scripting languages hosted on the VM lets us offer some compelling benefits to those developers, such as access to business logic already coded in Java.

KM: How do you think all of these projects will influence Sun's tooling over the next year?

CM: One of the obvious lessons for Sun is that not all important languages have a name starting with "J" and ending in "a" :-). So, in addition to improving our support for Java development (the new editor in NetBeans 6 milestones is *way* better than what we've had before), we are going to be adding support for several popular scripting languages. The initial version of support for Ruby (and Rails) just showed up in the latest milestone, and has really been getting positive attention when we show it around to existing Ruby developers. You'll see similar improvements in editing and debugging support for JavaScript and PHP. For client side development, you'll see improving support for that as well, plus support for technologies like jMaki that improves ease of use for existing JavaScript widget libraries.

One interesting opportunity centers around languages that can run on top of the VM in the server, since such languages can typically call directly into Java objects. This enables a class of hybrid language applications, where the front end can be quickly built and maintained with a scripting language (for example Ruby using JRuby, or JavaScript using Phobos), while reusing the business logic and persistence tiers that might already be built in Java.

Page:   1   2  3   4