Choosing a dynamic language to learn (Ruby/Groovy/Scala)

I've had Ruby sitting in my ToDo list for far too long. I mean, at least for a couple of years! It's been so long that in the time some fellows have made into the list as well, namely Groovy and Scala.

Finally, this year, I've decided that the time has come and that I have to invest some effort. Unfortunately, I know have to decide where.

I will start saying that all three candidates share the basic functionality that I'm looking for:

• Scripting
  I want an interpreted language that saves me time to come up with quick prototypes and hacks. I want a powerful OS tool beyond shell scripts. I may need to compile to bytecode later as well.
• Elegance and expressiveness
  I want to avoid boilerplate. I need dynamic typing and runtime inference. I want syntax sugar! I want easy to read DSLs.
• Closures
  They are a must. My only concern is readability but beyond that I cannot understand why Java does not have them yet.
• Mixins
  Inheritance on steroids.
• Go Functional
  Try to combine imperative style with some characteristics natural to functional programming. Less what and more how (descriptive style).

In the end, I want to be productive and those are the minimal requirements (nowadays). Beyond that, it's a matter of taste. Here's a little list of pros and cons of each. Take it with a grain of salt, this list is based on my personal preferences, many points will not be worth something to anyone but me:

• Ruby
  The first of the crop and the most popular for sure.
  • Pros
    • Refreshing (depart from C syntax)
    • Rails
    • Mature (since 1995)
    • Community
    • JRuby / SUN involvement (leverage the Java platform)
  • Cons
    • Too much hype
    • Lacks "enterprise" consideration (Threading? Scaling?)
    • Low ROI (see market penetration)
    • Is it loosing momentum?
• Groovy
  Enterprise capabilities along with cool productivity features
  • Pros
    • Tight Java / JVM integration
    • Extends JDK API(GDK)
    • Easyness / Learning curve
    • Out-of-the-box Spring integration
    • Grails
  • Cons
    • Performance
• Scala
  A general purpose (multi-paradigm) programming language
  • Pros
    • Interoperability with Java
    • Language features not retrofitted (ie Genericity)
    • Actors, concurrency and distributed programming
    • Implicit enrichment of a Java class
    • Statically typed with inference
  • Cons
    • Tooling
    • Not mainstream yet
    • Smaller community

In the end, I've chosen Groovy. I'm a geek, true. But I'm also a lazy developer and I like to apply my knowledge on day-by-day basis. For me that's easier in the Java camp (ie. with Spring).

I could choose JRuby then, but I'm not sure that's the correct path even though Sun's commitment (for example, with Netbeans and the compiler) seems pretty heavy.

Scala could be. Indeed it's improving (as the others) but it's not there yet. In the end, Scala seems more like a (future) Java replacement and that's not what I'm looking for right now.

A little bit more DWR and Spring MVC

I've blogged before about integrating Spring and DWR. This is just an update (though interesting) with some clarifications due to a request in the DWR mailing list.

Each new version of the Spring framework adds flexibility mainly by adding new features. This, in turn, can mean added complexity even though the additions are well thought and easy to apply. The complexity comes with the mix and match. In some way, it's like Java itself, it's not the added complexity of a new language feature, it's the integration with the rest of the language and the corner cases that appear. This is commonly a consequence of backward compatibility and the absence of deprecation.

Spring MVC 2.x has included new implementations of the classical Controller interface. Along with them new view resolvers and mappings were developed. These new controllers provide a new way of getting things done, for example, using annotations, but were designed to work side by side with the rest of the framework. This can lead to some confusion, easily, when some controllers are instantiated using component scan, others are declared in XML, some are mapped by annotations, others using convention over configuration and the views are injected or resolved by name and/or URL. Add DWR to the mix and things get scary for the less experienced developers.

I will start with an advice, do not mix different technologies if at all possible. This will force you to choose a path and commit to it but it will pay benefits in the long run. Less is more.

So what options are available? I will list the ones I consider the more intuitive. There are more combinations possible and even more options that I won't list (for example, declare the URL as the bean id).

1. Use XML to explicitly declare beans and mappings
   As always have been made. It's simple and expressive. Views can be handled by a InternalResourceViewResolver. The schema is highly integrated so DWR just becomes a couple of added lines in the related beans. The bad news, the unneeded boilerplate.
2. Convention over configuration
   Use ControllerClassNameHandlerMapping and DefaultRequestToViewNameTranslator. Declare your beans in XML. Add a specific mapper for DWR at the end of the chain (order = 2).
3. Annotations all the way
   They're concise and powerful because they're attached to the element. Do not mix with XML or get ready for the mandatory pandemonium that you have started. By the way, HandlerMappings are usually easier than HandlerAdapters. Unfortunately, currently DWR annotations are not tightly integrated (something to improve) so you need to fall back to the provided schema which seems counterintuitive.

And that's pretty much it. As I know that some people will still reject the advice and throw everything together, I have prepared a little sample project. It features four different controllers, three different mappings and a couple of view resolvers in addition to a DWR remoted bean. It's available here. Hope it helps.

The evilness of accessors

There are things in life that you take for granted. That is, you are so accustomed to them that you never question them. What for? Accessors (member functions that directly manipulate the value of fields) in the Java world is one of them.

The use of getters and setters is one of the first lessons to learn when working with Java, probably because the JavaBeans specification mandates their use. They help to increase robustness, enforce logic and hide implementation details. What's not to love? Well, something.. but maybe Java 7 will finally bring us properties...

During the weekend I read an interesting article titled Dishonest Programming. I'll quote one of the paragraphs:

Don't write a public accessor to a private member and tell me that member is still private. If an object is completely and utterly accessible from anywhere in the application, it's a global variable.

Everything was related to the following line of code (a line I've written a handful of times...):

setupModel.getOverrides().add(accountOverride);

Or a subtle variant:

for(Bean b: a.getBeans()) b.doC();

The Law of Demeter (Principle of Least Knowledge) clearly states that a method M of an object O may only invoke the methods of the following kinds of objects

• O itself
• M's parameters
• Any objects created/instantiated within M
• O's direct component objects

Right there I was puzzled. The principle seemed correct but its implications were awful! Imagine this class:

public class company {
   private List<Address> addresses;
   private Set<Account> accounts;
   private Map<Long, Employee> employees;
   ...
}

Can you determine the number of methods to add to the interface if you pretend to comply with the LoD? At least a couple of dozens for the collections (just java.util.List packs thirty approximately) and some more for the types.. On the other hand, the reasons exposed by the author (here) seemed valid:

• Violate encapsulation
• Tightly couple all three objects together
• Cripple modularity/type independence
• Deprive the parent class of the ability to guard, or even be aware of, the child data

First of all, as an architect I tend to agree with those reasons.

The first one is problematic though. Aren't public getters already breaking encapsulation? The moment they're available any other object can really interact with the supposedly private fields.

The second worries me greatly! This kind of code glues together objects that shouldn't be tied.

The fourth is problematic as well. PropertyChangeListeners already exist in Java but they're meant for peer-to-peer interactions not for parent/child invocations. If you're bypassing the object this way it's probably better to refactor.

At this stage, we have a problem. If the internal structure of an object is available (and so do the getters) it's difficult to avoid using it (or telling a programmer to avoid using it, if you prefer). I've come to the conclusion that creating proxy methods for cascade operations is the way to go, even if they are a lot!

There are two options then:

• Defaulting to a protected visibility
• Returning immutable objects

Both have pros ans cons. The first one may not work at all if the rest of the architecture expects public getters (some ORM frameworks or the EL in a JSP do, for example). The second one can be (somehow) confusing, tedious to implement for beans (for Collections is already done) and (depending on the implementation) even penalize the overall performance.

Finally, and I agree with the original author here, everything is a trade off and nothing should be written in stone. Just don't abuse the delegate strategy and try to conform to a best practice. We all know Java is verbose to the extreme and that this solution adds even more boilerplate (and that in 90% of the cases it won't matter) but if you stick to Java that's a nasty side effect you have to bear with. Just don't try to create shortcuts that punish good design.

Squashing boilerplate in Spring

Nobody can deny that the advent of IoC/DI frameworks, ORM tools and Web Services has brought robustness to the enterprise world. Programs are more clear and concise than ever before, at the cost of moving configuration from the source code to a specific realm, usually based on XML files. This, by itself, is not bad at all. In fact, is a Good Thing. Problems appear when the configuration is a language itself and grows so much that can be compared in size to the source code.

Here's a little guide that will help you to minimize the amount of config needed in a project

• Annotations are your friend!
  Easy one. From a dubious start, annotations are now considered a first class citizen. Even Spring developers encourage their use now. If you are using Java5+ try to move as much XML to annotations. It will help you in two ways: less code is needed and configuration is attached to the component directly (which makes reading code easier).
  
  In Hibernate/JPA nearly everything can be expressed with an annotation. Spring now offers annotations for bean creation(@Component...), managing life cycles(@PostConstruct...), wiring dependencies (@Resource...) and security (@Secured...). The MVC framework (in 2.5) also packs some more to help with controllers (@Controller...) and method and parameter mappings(@RequestMapping...).
  
  
• Leverage the latest version
  One of the areas that has evolved more positively from Spring 1.x, without doubt, is writing configuration XML. The second release of Spring brought a lot of syntax sugar in the form of additional schemes(jee, util,...) and simplified the dependency declaration. Spring 2.5 has brought the p namespace and component scanning. And above all, not only is XML configuration easier to write, it is now also extensible.
  
  
• Autowire
  Autowire has always been available and has been discouraged with passion as well. Detractors will tell you to skip the magic that happens behind the curtain. I cannot agree more. It was a common point of failure. And one difficult to debug.
  
  Nonetheless, the situation now has changed a little. The @Autowired annotation is already quite clear and it can be used in conjunction with @Qualifier to improve the understanding. I wouldn't autowire everything, don't get me wrong, but how many times do you have an interface with just a default implementation? Not all your beans can be candidate to be replaced by another strategy, do they?
  
  
• Convention over configuration
  A mantra for RoR developers. Probably they embraced it after writing some code in Java! Basically, avoid configuring something if there's a suitable default value already. And stick to defaults as much as possible. Maven does it for example, keep the standard directory structure and Maven can work with pretty little configuration overhead.
  
  Spring has always favored this kind of development as well. But in 2.x MVC new additions encourage it further(it's called sensible defaulting): ControllerClassNameHandlerMapping and DefaultRequestToViewNameTranslator. In case you haven't used them yet, they allow the dispatcher servlet to select a handler based on the class name of the controller and equally forward the result to a view. For example, IndexController and index.jsp would be invoked for http://.../index.htm without any configuration explicitly written.
  
  Of course, beware that there's again a lot of magic behind the curtain. At least document it somewhere (the project wiki comes to my mind). It won't cause you any troubles though (if you're not pushing the edges..), the controller and the view will be invoked or not
  
  
• Create a root application context
  Beans can be inherited from a parent application context in Spring. This means that any shared beans should be refactored there and later be referenced from any other context. Beans can be shared between web applications, EJBs and the like. More info is available here. Remember that Spring 2.5 offers the possibility of deploying application contexts as a JCA adapter for headless applications.
  
  
• Create abstract beans
  Probably you're already using abstract classes to encapsultae common functinality. Are you doing the same for beans? I'll copy Spring documentation here:

  A bean definition potentially contains a large amount of configuration information, including container specific information (i.e. initialization method, static factory method name, etc.) and constructor arguments and property values. A child bean definition is a bean definition which inherits configuration data from a parent definition. It is then able to override some values, or add others, as needed. Using parent and child bean definitions can potentially save a lot of typing. Effectively, this is a form of templating.

  If you're still in doubt imagine how many of your beans usually have a dependency on the persistence facade, the document repository, a cipher or a combination of them! A hierarchy of bean skeletons helps immensely (and not only in writing less code).
  
  
• Less is more
  If you've read Getting Real from 37 Signals (it's free and highly recommended!) you're familiar with the term. If you've read The Pragmatic Programmer you are intimate with the DRY (Don't Repeat Yourself!) principle by now. Maybe Martin Fowler Refactoring? Pick the example you like most, rest assured there are several. All point in the same direction, write less, more concise code. It'll be easier to read, to debug, to maintain and generally it'll work better. The moral is to abandon all complexity!