March 2008 Archives

Throw J2EE from the Train

Chris Sepulveda recently wrote a great article discussing why he believes that Ruby and Rails will ultimately topple Java in the enterprise development space.

He’s not the only one. I’m often hearing Rubyists talk about how, once the Java community “crosses the chasm”, we’ll rule the world. I seem to recall that Smalltalkers had the same notion at one point…

And yet Chris drew an analogy that caught my eye: “Rails is not unlike other early-technulogies in this regard (consider Java in 1996-98).”

I often use a similar analogy when attempting to introduce Ruby and Rails to other Java old-timers: “Remember Java way back in 1997? Yeah, that’s Ruby right now” implying that fame, fortune, and glory await but a few years away for those who hop on those Rails now.

To an extent, the analogy holds. Between ‘96 and ‘98:

  • Java was slow as a dog. (Ruby: check)
  • Java was immature. There were few class libraries available. (Ruby: hrmm… let’s come back to this)
  • Sun/Java struck gold with J2EE v1.0 in ‘98-‘99. (Ruby: Rails - check)
    • Arguably, Java web development didn’t achieve “maturity” until early versions of Struts appeared on the scene and provided structure that was sorely lacking within the typical J2EE app pre-‘99 (Ruby: Rails - check, Merb as well)

However, I still have some reservations about this analogy. As of ‘98:

  • Java had been around for 3 years. As of today, Ruby has been around for 13 years. It wasn’t until recently with Rails that Ruby came out of the Sinai and found its land of Milk and Honey – maybe.
  • Java had Sun vigorously evangelizing Java like the snake oil of the millennium whereas Ruby, instead, has several small consulting firms and a vocal community of passionate developers (myself among them).
  • Java had a pittance of available libraries whereas there are a plethora of available Ruby libraries today.

Let’s face it: in the enterprise, more often than not, it’s not the engineers who pick the technologies: it’s the pointy-haired morons who wear ties to work every day, have stock in the company, a sizeable six-figure income, drive a BMW (bullshit on the inside), and pick technulogies that are “safe” (i.e., they cost lots of money – like Oracle or Microsoft) instead of technologies that can save money (like Linux or Ruby or other OSS).

Of course there are small pockets where sanity reign. One of Chris’ commenter’s henpecked Relevance’s Streamlined framework; however, Stu will tell you that they often submit two bids for their contracts: one to be implemented in Java and the other Ruby. Do I really need to tell you which bid most of his customers pick? What does Relevance use to implement many of their web apps? Stu told me that they built Streamlined to help them quickly develop web apps that, while they won’t win beauty contests for web design, handily get the job done and can be constructed in short order.

At the end of the day, to the enteprise, shouldn’t that be what matters? More value for less money? We engineers often tend to be idealists. If one technology does something better than another and can easily be adapted to play well with the technologies of the past, we deem it a winner. Sadly, the best ideas often lose despite technical merit.

Posted by evan on Mar 22, 2008

Passing Maps in Groovy (or "Groovy did what?!")

  class Robot 
  { 
    def type 
    def height 
    def width 

    def access(location, weight, fragile) 
    { 
      print "Received fragile? ${fragile}, weight: ${weight}, loc: ${location}" 
    } 
  } 

  robot = new Robot(type: 'arm', width: 10, height: 40) 
  println "${robot.type}, ${robot.height}, ${robot.width}" 
  robot.access(50, x: 30, y: 20, z: 10, true)

Republished from Venkat Subramaniam’s Programming Groovy (Beta, p. 39)

…outputs the following:

  arm, 40, 10
  Received loc: ["x":30, "y":20, "z":10], weight: 50, fragile? true

If you’re a Ruby programmer, the second line is going to look seriously bizarre. If you’re not, I’ll explain why. In Ruby, you can pass a Hash (think java.util.Map) inline in a method call with the following syntax:

  foo("param1", param2, :hash_key1 => val1, :hash_key2 => val2)

According to Groovy, when a Map is inlined as a argument to a function, by convention, it is the first parameter on the method. If it is not passed in as the first argument then it is coerced into becoming the first argument. The Ruby interpreter will error if you pass an inlined Hash as any argument other than the last. Forgive me but Groovy’s coercion of parameter ordering is just fucking weird.

Posted by evan on Mar 04, 2008