With Groovy, first do no harm

With Groovy, first do no harm

Since I joined the Groovy project I have tried to steer the group towards a mantra that I think will benefit all. With respect to Java, with Groovy, first do no harm. What does this mean?

Some of the things that have bothered me about Groovy are enumerated quite intelligently by this post. One can look at how to develop the Groovy language from two viewpoints and come up with quite different results. My preferred viewpoint is to start with Java and add compatible features that improve usability, reduce verbosity, and increase expressiveness. When I say “compatible” features, that is where the mantra “first do no harm” should come into play. Features or options that decrease the compatibility with Java syntax should only be added if there is absolutely no way around it. Optional features scare the hell out of me as well. Things like optional ;’s and optional ()’s imply vastly differing coding standards that will only lead to frustrating maintenance of the code and act as a barrier to readability. The other viewpoint, which I think is a real barrier to mainstream acceptance, is to develop Groovy as Ruby with a Java-like syntax. The vast majority of all developers (if it becomes mainstream) who will program in Groovy have never programmed in Ruby. Using Ruby as a starting point is probably the wrong way to go for this reason. The current feature set / optional syntax reflects its Ruby origins a bit too closely.

One week from today we will see if Groovy is accepted as a JSR. If it is accepted, which I think it will be, Groovy will be an extremely visible project. Without some core tenet I feel the project may lose direction and become a kitchen sink of random features. Every feature must be added with care and with the understanding of its effect on the Java programmers that will use the language.