A recent project I’ve been working on uses Grails, the Groovy-based Java web platform, patterned on Ruby on Rails.  Grails is a Java relational database to web stack built on the well established open source frameworks, Spring and Hibernate.  The design philosophy seems to be to take some of the best ideas from Rails and write DSLs (Domain Specific Languages) in Groovy to stitch everything together in a convention-over-configuration style.  It’s a great idea in principle, but I think they’ve taken it too far.  Here’s why.

It is too automagical.  Grails is touted as a productivity tool, because presumably less code needs to be written.  The developer can concentrate on writing the application and not on writing infrastructure such as Spring XML files or Hibernate mappings.  It’s true that if the conventions are followed, Grails usually behaves as expected.  And this is the first problem.  One must learn the conventions.  There is a learning curve, and so this ramp up time must be subtracted from the expected productivity increase.  Of course programmers usually get going as soon as they grasp the basics of a framework.  Danger lies here.  Because without a deeper understanding of the machinery, it is quite easy with a dynamic language such as Groovy to quickly lose one’s way and lose too much time debugging when things don’t work as expected.  And that’s only if you notice things that aren’t working as expected.  There is more to productivity than writing less code.

Active Record considered harmful

Briefly, in the active record design pattern, a domain class in an object-oriented language is mapped to a database table and contains fields corresponding to table columns.  The class often contains collections of other domain classes mapped to tables that have a foreign key reference.  This much is true even for basic Hibernate.  But in the active record pattern the domain class also contains all the methods for querying the database.  In Rails and Grails this means that in any layer of the application a database query can be made.  In the model/view/controller of Grails, the active record is the model, the view is a GSP tag file (similar to Java JSP), and controller classes handle processing of HTTP requests.  Grails has a service layer, as well, if you want to use it.  But nothing prevents a database operation from being done in a GSP, in a controller, in a domain class method, or in a service.  Only design discipline on the part of the developer can separate concerns like presentation, business logic and database operations.  My main beef with Active Record is that it’s too easy to write code that’s becomes hard to understand with respect to how it queries the database.  Grails makes it so easy to work with the database that programmers start to forget it’s there and begin to treat database calls as if they were simply local method calls.  It is easy to query up huge amounts of data and then only use a bit of it.  I’m talking about one line of code.

So, if it’s easy to write very inefficient database code, but this speeds up feature delivery, why is it so bad?  Everyone know that premature optimization can be a problem, too.  The problem, as I see it here, is that when it comes time to optimize, where do you look?  If you haven’t been focused on where in the code database queries are being made, it’s going to be a more difficult task.

Dependency issues

Like many out-of-the-box Java stacks, Grails brings along a lot of dependencies, both in terms of infrastructure like the versions of Spring and Hibernate and also in terms of Grails plugins.  I suppose since Rails has plugins that Grails had to have them.  A plugin is basically a Groovy DSL over some common Java library.  The upside is the ease of use of a DSL.  The downsides are that one must learn the DSL, and one is limited by the capabilities of the DSL, which may only support a subset of the library it wraps.  Moreover, plugins have bugs and they bring their own dependencies, both on Grails versions and on the versions of the supporting libraries.  That’s a lot of downsides to pay to get a groovy DSL.

Testing in Grails

Grails has DSLs and also classes to support testing.  If you have used JUnit TestCase or GroovyTestCase, will you be at home?  To some degree, yes.  Grails supports unit, integration and functional testing out of the box and you can add Spock (with a plugin, of course).  I found the Grails extensions for testing to be confusing.  As a programmer with extensive experience with unit testing and mocking libraries like JMock and Mockito, I did not find it simple to dive into the Grails testing mojo.  One thing that makes it difficult is again my nemesis, Active Record.  Since domain classes have a database dependency to them, they require a testing setup that uses an in-memory database.  Grails makes it easy to do, but not easy to understand what’s going on.

Conclusion

Grails brings with it a ‘world view’.  It is an opinionated framework that you must conform to.  The essential problem, in my view, is that a framework that has made it easy to do something has obscured and made it difficult to understand how it works.  It requires more time, even for experienced developers, to become steeped in its conventions, as well as its inner workings, before the productivity starts to roll.  And it carries a risk that inexperienced developers will make mistakes that could be costly down the road.  Like all powerful software tools, it takes mastering to make it the most effective.  I’m not convinced that the time I’d spend mastering Grails would ultimately pay off.  I would rather spend the time mastering alternatives.

One last point.  I think Groovy is an excellent VM language.  It, too, makes it easy to do something with the penalty that it obscures how it works.  But the problem in this case is confined to a language and not to a framework.  I don’t consider myself a master of Groovy yet, but I do find it worth the time to master.

Recently I had the pleasure of two sessions on programming concurrency on the Java VM by Dr. Venkat Subramaniam, at a No Fluff, Just Stuff conference.  The presentations were based on his recent book, Programming Concurrency on the JVM.  Two very different approaches to programming concurrency were presented:  the Actor paradigm, and Software Transactional Memory (STM).

Multiple-core CPUs are having a big impact on application programming, because they increase parallelism, which brings out concurrency bugs in programs that are not correctly written.  Writing correct programs in a concurrent environment is very difficult.  Java has supported concurrency from the beginning with threads and synchronization.  But unfortunately it is incredibly difficult to write programs in Java that will execute correctly in concurrent environments.  On the contrary, it is incredibly easy to write incorrect programs without knowing it.  Why?  First, the object-oriented paradigm is all based on state, and the language facilitates access to shared state by multiple threads.   There is no support in the compiler or the runtime to detect concurrency problems.  Moreover, it is hard to write automated tests that prove correctness under concurrency.  If you don’t believe this, Venkat’s amusing presentation will convince you.  Except for very simple cases we cannot know by inspecting code or by writing tests that our Java code is correct, as long as we rely on the primitive support of synchronization and try/wait.

There are surprisingly few good sources of information for working application developers wanting to do concurrency well.  One of the first to address the issue was Doug Lea’s book, Concurrent Programming in Java, first published in 1999 and now in it’s third edition.  Lea’s book lead to the java.util.concurrent library being added to Java in Java 5, which I have used to improve my concurrent programs.  Brian Goetz came out in 2006 with the essential book, Java Concurrency in Practice, which dives deep into the workings of the Java memory model and gives practical examples for using java.util.concurrent classes to write thread-safe code.  This solution works, but Venkat calls the approach ‘synchronize and suffer’ because of its difficulty.   I learned from Venkat that the Java concurrent library has become the ‘assembly language’ for a new generation of open source APIs, some of which he covers in his recent book.  Here are some resources.

• Scala has become popular for concurrent Java programming, in particular the Akka framework and its support for Actors.
• A book on Akka futures is available from the author, Mike Slinn.
• Clojure is a JVM language that features immutability and STM as first class language features.  Venkat demonstrated how to use clojure classes in Java source code to achieve STM in pure Java.
• The GPars framework (pronounced ‘jeepers’) provides concurrency support in Groovy.  GPars is now in 1.0 beta and supports both Actors and STM.

To sum up, it was never easy to do, and now it is becoming crucial to get concurrency right on the JVM.  Although it requires considerable study, fortunately the field is starting to produce the literature and the APIs that working programmers need to get the job done.

I was re-reading appendix B in Alistair Cockburn’s book, Agile Software Development, 2nd edition.  He has posted the entire appendix on his own blog.

Peter Naur thinks it important to consider the sort of activity that programming is.  Because if it is misconceived, we will not be as successful at it as we could be.

… the main point I want to make is that programming in this sense primarily must be the programmers’ building up knowledge of a certain kind, knowledge taken to be basically the programmers’ immediate possession…

Naur calls this kind of knowledge a ‘theory’, in the sense that the philosopher Gilbert Ryle used the term. A theory in this sense is a kind of tacit knowledge that a person can acquire, that – here is the strange part – cannot be expressed, i.e. cannot be put down as so many rules or principles.  However, one in possession of a theory about a program can, by working closely with others, induce them to acquire a similar theory, one that is serviceable for carrying on the development of a computer program in accord with the theory of it.

What does this mean for practice?  It is often recommended that a team of programmers who have developed a program remain closely connected with it throughout its life.  In Naur’s sense, they possess a theory of the program that other people cannot acquire by reading the program source code and any amount of documentation, no matter how well written.  There will be objection to this idea.  It once was, and still is in some quarters, a standard practice to hand over a program to a maintenance team after the program sees production.  The idea is that the original designers, presumably expert developers, should move on to new projects where their skill in, shall we say ‘theory building’, can best be utilized.  Meanwhile, the maintenance team, usually comprised of members with less skill and experience than the original developers, will take responsibility for program extensions and bug fixes.  A major point of Naur’s essay is that this is misguided.  Without a period of transition, where at least some of the original developers work on the maintenance team, the group picking up a program having only the source and documentation will be trying to ‘resuscitate’ a dead program, a program whose original development team has dispersed and the theory forgotten.  They will be attempting to build a new theory of the program and how it relates to the world.  And it is almost guaranteed they will get it wrong.  This is not a diatribe against documentation.  But it must be realized that the point of documentation is to be an aid to memory in the building of a theory of the program.  Using a document alone is not sufficient to acquire an adequate theory of the program.  Getting that requires speaking directly – and at length – with someone in possession of it.

You will have to digest the Naur essay and see if you agree or not.  I believe that Naur is right, and that a tacit knowledge, a theory of a program and its relation to the world (domain) is created by the programmer.  This is the real activity of what we call computer programming.  It is about gaining an understanding of a certain kind and becoming an expert in that program and its domain.  This turns the programmer, as person, into a value asset for the employer.  Naur concludes that as such, programmers should be recognized for what it is they actually do, which is to become knowledgeable.  This, and not the texts they produce as source code and documents, constitutes their real contribution.  This is why programmers should be kept together as working teams and kept working on software they have developed.  Because they are the ones in possession of the program’s theory and cannot give it easily over to others, but only over time in working with new team members.