Tag Archives: rails

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.