I have a passion for talking to people, identifying problems, and writing software. When I'm doing my job correctly, software is easy to use, easy to understand, and easy to write... in that order. Michael is a DZone MVB and is not an employee of DZone and has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Software is Design, How Ruby is Better for that Job than Java

06.10.2013
| 13484 views |
  • submit to reddit

As a long time java developer and ... well ... at this point also a long time ruby developer, I've found some things about the ruby language are much less bothersome than in java. Groovy takes an interesting middle road, but only gets about halfway in my mind. I'll leave the runtime differences and the dynamic/static compiled/interpreted debates for other forums and just focus on the Focus on this one irksome quirk.

Property Accessors are too verbose

Java Definition

class Car {
    private Color color;
    public Color getColor() {
        return color;
    }
    public void setColor(Color color) {
        this.color = color;
    }
}

and to use it:

Car car = new Car();
Color blue = car.getColor();
car.setColor(blue);

The whole getter setter thing is a pain to me. The bean pattern used by java is just overly verbose. For all the OO purists, I get it, we need to hide the private variables and put them behind methods to abstract away the inner structure, but I'm so weary of 3x lines of generated code to accomplish this.

Groovy (1/2 way there)

class Car {
    Color color;
}

or (if you need to override a behavior):

class Car {
    Color color;
    public void setColor(Color color) {
        println color
        this.color = color
    }
}

and to use the class (either approach) the syntax is much better:

car = new Car();
Color blue = car.color
car.color = blue

In the first groovy example above, the actual class implementation is identical to the java example. It is much cleaner and obviously easier to read because it's missing all the cognitive overhead of explicitly defined methods, parentheses, and other java doodads.

In the second example, we've added some code to print the color to the console in the setter and still written fewer lines of code. This both reduces our typing/typo load, plus reduces our "100 lines of getters and setters" overhead. So, good marks to Groovy for striking a middle ground and allowing developers to do the easy stuff the easy way and only imposing the java crazy syntax tax :) when it's necessary.

Ruby

class Car
    attr_accessor :color
end

and to override the set color method:

class Car
    attr_accessor: color

    def color= color
        puts color
        @color = color
    end
end

and to use it

car = Car.new
blue = car.color
car.color= blue

While perhaps a little implicit, one might think that there weren't any methods at all, it looks like you're just setting and getting values. The advantage of the ruby approach is that when you change the underlying implementation, you can still use the simple syntax much like looking at java properties, but when you NEED the complexity of hiding things behind a method... you can do this you still have method declarations that are symmetric with how you call them.

One thing I hear over and over on this regard from die hard java folks: "But mike I can just use a tool that will automatically generate all that boilerplate and even automatically refactor all the names, so this isn't an issue". I disagree, what they're really saying is that there is a workaround they feel "isn't a big deal" to minimize the impact of this wonkiness, but I feel this is a broken window that is a foundational problem with java based solutions.

For detractors, let me start by stating that is is my opinion that all programming is design. If you disagree, then we probably won't be able to come to an agreement on the following statement, which is: "The most important part of a programming language is its ability to convey ideas clearly, succinctly, and unambiguously to other developers". The problem with java (and many other languages) is that it isn't designed to convey ideas to developers, its design instead seems intent on conveying instructions to the computer than it does to convey ideas to other developers. The ruby approach, in this regard, is much better.

References

Published at DZone with permission of Michael Mainguy, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Edvin Syse replied on Mon, 2013/06/10 - 9:37am

To be fair, the Groovy equivalent without types (like your Ruby example) is:

class Car {
  def color
}

And to override the setter:

class Car {
  def color
  def setColor(color) {
    println color
    this.color = color
  }
}

matt inger replied on Mon, 2013/06/10 - 11:14am

So, you take 1 example of properties and that makes the whole language better?  

For some reason, oracle doesn't seem to think first class property support is worth having (as of yet).  But here's also been a lot of work on the property front to make things easier.  Project Lombok for instance.

Through the user of annotation processors, it simplifies the code you write from the verbose get/set methods to this.  While not perfect, it's a good step in the right direction.  It ends up generating the getters and setters at compile time for you.

@Getter @Setter private int foo = 10;

Bruno Borges replied on Mon, 2013/06/10 - 12:03pm

Java does not offer this from its core. But you can extend it using Annotation Processors.

One example is Project Lombok 

Tiago Cunha replied on Mon, 2013/06/10 - 12:06pm

We had to consider the performance of java that is better over the ruby and consider all the ecosystem of java... the many things that don't exist in ruby and in java you can do more easily... 

Yes, ruby is much more verbose friendly than java (maybe not in some aspects but in others would be...)

But if we put in a balance, we gonna see that java is even a better option than ruby for many kinds of system.

diego Visentin replied on Mon, 2013/06/10 - 12:52pm

If you like OOP and design-by-programming, then you'll find Smalltalk gorgeous

Peter Henderson replied on Mon, 2013/06/10 - 2:05pm

Scala for the win

Car {
  var colour = Colour.Blue3
}

val car = new Car()
val red = car.colour
car.colour = red

Mark Unknown replied on Mon, 2013/06/10 - 10:45pm

TCO is of utmost importance. Setters/Getters are a minor inconviennce.

In addition to Lombock - http://www.eclipse.org/xtend/.


Fabien Charlet replied on Mon, 2013/06/10 - 11:01pm

OMG ! Properties access is software design ? Really ? First of all, setting fields privates is just a convention. If you deeply love the "car.color = blue" writing, set your fields public and you'll write car.color = Color.blue. Problem solved. But, IMHO, when you have hundred of thousands lines of business code, you don't care of writing car.color = blue or car.setColor(Color.blue);

Andrew McVeigh replied on Wed, 2013/06/12 - 5:34am in response to: matt inger

We use lombok extensively on a very large gaming system. It sort of crept in, but when we got used to it we found it reduced much boilerplate. +1 from me!

Andrew McVeigh replied on Wed, 2013/06/12 - 5:36am in response to: Fabien Charlet

But, IMHO, when you have hundred of thousands lines of business code, you don't care of writing car.color = blue or car.setColor(Color.blue);

True, setters and getters are not software design. They are simply boilerplate. Perhaps "reducing boilerplate" would have been a better title?

Anyway, we introduced lombok into a very large system we were working on recently - so the setters and getters code basically went away. It had a remarkable impact on system quality, bizarrely enough. It literally reduced lots of DTO classes from hundreds of lines to dozens.

Mark Unknown replied on Wed, 2013/06/12 - 8:30am in response to: Andrew McVeigh

Andrew, I think we would agree that reducing boilerplate is good (I do). It is just not a good enough reason like one langauge vs another.

Mark Unknown replied on Wed, 2013/06/12 - 8:34am in response to: Andrew McVeigh

" It literally reduced lots of DTO classes from hundreds of lines to dozens." 

Now all that is left is to just to reduce DTOs.or replace/rename them with something that matches the usage (i.e. view objects) .;)  

Andrew McVeigh replied on Wed, 2013/06/12 - 9:08am in response to: Mark Unknown

Now all that is left is to just to reduce DTOs

Unfortunately java tends to need lots of dtos. interestingly a dynamic language like lua, groovy or ruby avoids a lot of the need for this IMO.


Mark Unknown replied on Wed, 2013/06/12 - 12:11pm in response to: Andrew McVeigh

"Unfortunately java tends to need lots of dto"

LOL. Ok. :) 

Note: I do have many "view" objects that in a sense are like database views in that they contain certain attributes from multiple domain objects. They are not DTOs (not by definition nor usage) and not every domain object needs one. They are also "read-only".  These would be needed for dynamic languages too.They might be easier to create with dynamic languages but more difficult to maintain.

Raging Infernoz replied on Sat, 2013/06/15 - 10:08pm

Code quibbles like this are trivial, considering all the benefits Java has over dynamic languages like Ruby e.g. Jobs, Security, vast library support, Maven, IDE support for refactoring, debugging, and profiling, static code checkers like PMD and FindBugs, an excellent VM etc.  Groovy is just a scripting language to me.

Patrick Conway replied on Wed, 2013/06/19 - 8:52am

nonsense


 public Class Car{

 public Colour colour;

}


Car car =new Car();

car.colour=Colour.BLUE;

Michael Mainguy replied on Wed, 2013/06/19 - 10:07am in response to: Patrick Conway

Using that example, how do we change the implementation to log the color when someone changes it?

Mark Unknown replied on Wed, 2013/06/19 - 8:17pm in response to: Michael Mainguy

Using good design, you should not hand code it. Use something like AOP and/or Annotations which should work with fields (i.e. http://www.onjava.com/pub/a/onjava/2004/08/25/aoa.html?page=2) just like one should with mutators or properities.

zel branco replied on Fri, 2013/06/21 - 11:46pm

My opinion Ruby or Groovy are dynamic language and dynamic language

have never been the top language. They can at best be  another perl or php.


Scala is very cryptic and does not look like Java . Complex language have never succeeded in past.

If Groovy gets more options like compile static etc, then its bound to replace Java.(or maybe Java 8 will come to the rescue)

 

Steave Lee replied on Tue, 2013/09/17 - 12:44am

 Thanks for such a great information.

But i think Java is best programming language..

----------------

heavy duty racks

matt inger replied on Tue, 2013/09/17 - 5:18pm in response to: Steave Lee

There is no "best" language.  There are lots of languages that are good for lots of things.  You happen to prefer java (as do i, though i'm getting to be a fan of scala).    A language is only a tool to write programs.

Raging Infernoz replied on Sat, 2013/09/21 - 6:27pm

As Nicholas Taleb points out in his book Anti-Fragile, the longer something has survived, the longer again it is likely to survive, and the younger something is the less long it is likely to survive.

Java has lasted a long time, has a large market share, and is still going strong, so has a much better chance to survive far longer than these still edge languages.

So long as Oracle can properly clean up years of stupid Sun technical debt in Java core code (not just reactive security fixes), and keeps adding useful features, in regular new versions, it will likely live on for decades, while Ruby and other edge languages will probably slowly fade away.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.