Sunday, February 01, 2009

Groovy and the MetaObject Protocol

Bill Grosso spoke to the January meeting of the SDForum Java SIG on the Groovy programming language. An important part of the discussion was the Metaobject Protocol. I will get to that after explaining what Groovy is. Also at the meeting, Chris Richardson spoke on GORM (Grails Object Relational Mapping) an object relational mapping layer for Groovy programs. I will discuss this at another time.

A couple of months ago I posted on the Scala programming language. Like Scala, Groovy has a Java like syntax and is compiled to the Java virtual machine. That means that it meets the Java criteria of compile once, run anywhere. Also it makes the full set of Java libraries available to the programmer. Unlike Scala, Groovy is a Dynamic language. While there is some discussion as to exactly what a Dynamic programming language is, a core principal is that in a Dynamic language data type is a property of a data item, whereas in a Strongly Typed language like Scala, the data type is a property of the variable that holds the data item.

In general, it is easier to start writing a program in a dynamic language as you do not need to make so many decisions up front, the program gets written more quickly, you can test out ideas and bits of the program interactively and the program tends to be smaller. On the other hand, large programming projects, particularly with many programmers, maintainability and refactoring suffers when a dynamic language is used. I have more to say about dynamic languages at another time.

In his talk, Bill argued that another advantage of a Dynamic language is that it allows for the Metaobject Protocol. Like anything else with meta in its name, the Metaobject Protocol concept is a little hard to pin down. I think of it as the mechanisms in a programming language that allow you to build frameworks, generalized algorithms and such stuff. Bill's argument is that the ability to build these things within the language is necessary and a good thing, and that the mutability of a dynamic language's type system is required to do it. After all the name Metaobject Protocol comes from Lisp, the most mutable of programming languages (apart from assembler).

I disagree with the last part of the argument. For example, the old joke goes Q: what happens when you put more than one java programmer in a room? A: you get a framework! Java is a strongly typed language and the object of more frameworks than all other programming languages put together. In fact I am always amazed at how Java, which is a relatively small language as well as being strongly typed can be used to build such extensible systems.

There is more to my objection than that. Sometimes boundaries on what you can do are a good thing, and a well structured programming language creates boundaries. During the talk, Bill gave as an example of the Metaobject Protocol, changing the inheritance rules for an object. Inheritance, particularly multiple inheritance, is a slippery and potentially ambiguous problem at the best of times and the ability to change inheritance on the fly is frankly scary. My first reaction to any project where any kind of inheritance rules are even an issue would mean that the class structure is far to complicated. Programmers should strive to create deep and complicated data structures rather than deep and complicated class structures.

To summarize, I believe that strongly typed languages are just as capable as dynamic languages for building the kinds of tools and frameworks as the Metaobject Protocol. Moreover, strong, clear types and rules prevent us from getting lost in a semantic swamp that can arise when our language system allows us to change things on the fly. Apart from that, Groovy seems like an nice enough language, and it is probably as good as the many other dynamic languages that are around now. Bill did mention that performance is noticeably slower than Java, as might be expected for a Dynamic language running on a platform optimized for the other type of language.

No comments: