Tag Archives: ruby

What makes a language Dynamic?

I read an article the other day on coding horror that discusses size is the enemy of software development. One of the opinions from the article was:

If you’re starting a new project, consider using a dynamic language like Ruby, JavaScript, or Python. You may find you can write less code that means more. A lot of incredibly smart people like Steve present a compelling case that the grass really is greener on the dynamic side. At the very least, you’ll learn how the other half lives, and maybe remove some blinders you didn’t even know you were wearing.

I agree 100% with this statement. Where the confusion often comes in is what makes a dynamic language “dynamic”. Is it because of dynamic typing? Is it strong vs weak typing? What about the presence of a MOP?

A lot of the buzz around dynamic languages has been created by the Ruby community, particularly around the Rails application. As described in the previous quote, dynamic languages provide features that allow you to write less code that means more. What about Ruby on Rails allows developers to write less code? There is more provided there than dynamic typing alone can provide.

So what is the definition of a dynamic language? Graeme Rocher had a great session at grails exchange on “Dynamic Groovy – Meta Magic” where he addresses this issue in the introduction. He defines a dynamic language as a language with a Meta Object Protocol (MOP for short). A MOP is (definition from Meta Magic):

A mechanism that makes the semantics of a program extensible.

This definition is a bit vague but in a nutshell it allows classes to be dynamically modified at runtime. Typically these languages also provide language level ways to intercept method invocation and property access.

There are many languages that support dynamic typing like Visual Basic, BeanShell, Ruby, JavaScript and Groovy but not all of these have a MOP. According to Graeme the main languages that support a MOP are Groovy, Ruby, Small Talk and LISP.

I do agree that a dynamically typed language like JavaScript allows the programmer to write “less code that means more”. The point that I’m trying to make is that a language that is dynamically typed AND has a Meta Object Protocol allows the programmer to write even less code than one that just has dynamic typing.

The meta object protocol is what allows applications like Rails and Grails to create and extend domain classes at runtime.

For this reason, I would recommend that if you are starting a new project, consider using a dynamic language like Ruby or Groovy. A dynamically typed language with a Meta Object Protocol allows you to write less code that means more than a language with no Meta Object Protocol.

Grails is not Rails

I have been using Groovy for a little while now and am researching the possibility of using Grails for an upcoming project. At the time, I did not no much about Grails but I had dabbled with Rails a bit and got a feel for how it works.

The .NET community created a project called nant, the .NET port of ant. I’m also familiar with all of the various XUnit variants like JUnit for Java, NUnit for .NET, etc… I just figured Grails was a the Rails application for Ruby ported over to Groovy.

This was not the case at all. Both Rails and Grails are “coding by convention” web frameworks for the Ruby and Groovy languages respectively but they have very different design points. I was familiar with how ActiveRecord works in the Rails world and figured Grails would work the same. ActiveRecord takes a database schema and builds the Object model from the database. In Grails, Object Relational Mapping (GORM) instead using hibernate under the hood.

This article gives a really good summary of the differences in the design approach between Rails and Grails:

Ruby on Rails: RoR uses the bottom up approach where you define your model at the database schema level and RoR builds the model to match using naming conventions. You don’t even have to add the properties to your domain classes as RoR will add them based on the naming conventions of the db schema.

Grails: Grails uses the model-down approach where you define your model and it (or Hibernate technically) builds the schema for you. As I mentioned I don’t like this as a matter of taste since I don’t have as much control over the underlying model. To Grails’ credit, you can fine grain control the database schema by using Hibernate’s mapping, but what a pain.

http://thebull.macsimumweb.com/comparing-ruby-on-rails-to-grails

Agile Dynamic Languages for Java

There has been a lot of buzz about Ruby in recent days, particularly around Ruby on Rails. I love these Ruby on Rails vs. X commercials that www.railsenvy.com has created. Rails provides a much better framework for the “web backed by a database” problem than anything I have seen in the pure Java world. Java has become a very bloated language and even the so-called “lightweight” frameworks are large and clunky. Rails is a great alternative for most people.

But not for everyone. I work mostly with Java based server applications that do not fit the “web backed by a database” type of project. These applications could benefit from the Ruby language itself, but not much from Rails. I have looked into using JRuby as a way to leverage the strengths of the Ruby language on the Java platform.

JRuby is a Ruby interpreter written 100% in Java and therefore runs on the JVM. It allows you to have the benefits of Ruby but still be able to use existing Java code. My main issue with this implementation is that it does not inter operate well with Java. Code written for JRuby typically use the Ruby libraries which work distinctly different from their Java counterparts. This makes it difficult to create a hybrid application where both Ruby and Java is used.

This is about the time I found the Groovy project. Groovy is “an agile dynamic language for the Java Platform” (http://groovy.codehaus.org). It is a powerful dynamic language that has many of the sought after features of other languages like Ruby and Python. The key difference here is that Java is a first class citizen in Groovy. The Groovy libraries are built on top of Java, extending and modifying the core API. Groovy makes creating a hybrid Groovy/Java application possible and easy.

For those coming from a Java background, Groovy is very easy to learn. The syntax is very similar to Java with a twist. Semicolons are not required, getters and setters are not required for properties, code closures are available and metaprogramming is possible. If you are looking for Rails, there is Grails which is a web framework for Groovy.

So if you long to wet your feet in an agile dynamic language like Ruby but are stuck with supporting legacy Java applications, I would recommend giving Groovy a try.