Shrek 2: As good as the first Design Eye for the Usability Guy
May 20

Consilidating scripts with Groovy (Merging .sh/.pl/main()/etc to .groovy)

Groovy, Tech Add comments

One small side effect of embedding groovy into a project is that I have noticed the cleanup of some scripts.

In the past I would often have:

  • Foo.java: This would have a main(…) to do something
  • foo.sh/.cmd/.pl: These would munge a few things, and then call java … Foo …

Now we just have Foo.groovy. The script will itself do some munging, and will just call into the Java packages which have business logic.

So fresh and so clean.

Well, it is a small thing… but still a pleasure :)

2 Responses to “Consilidating scripts with Groovy (Merging .sh/.pl/main()/etc to .groovy)”

  1. Dion Says:

    The point wasn’t that I couldn’t do this in the past. I *was* doing this in the past. It involved shell scripts and Java, and I would contend that it was a lot more clunky that the Groovy scripts that I now have.

    Your point about “adding a new language” on a large project is definitely a good one. You definitely have to make up your mind on that one for your particular project or company.

    However, I definitely think that:

    a) Saving keystrokes isnt’ a bad thing
    b) It isn’t actually about saving some keystrokes

    Developers write code. Code has bugs. I think that some agile languages apply nicely to certain problems. In a Groovy script that I wrote recently, the outcome was ~10 lines. Each line did something important. It was done in no time. If I had chosen Java for that task I *know* it would have taken a hell of a lot longer, and I would have been fighting verbosity that I just didn’t need in this case.

    Multiply this and it can save me a lot. The act of meta-programming itself take also allow me to do things that shrink a program in size and complexity.

    Of course, it is a personal thing… if you prefer Java, use Java :)

  2. Almost Anonymous Says:

    No one, you’re just found your first use for Groovy. All those little applications that you write for and support yourself. Or, like Dion says, hopefully Groovy can replace a few of those inevitable Perl scripts that pop up even in “enterprise applications” (or more likely, “enterprise operations”).

    If you have people developing “enterprise” Java applications, Groovy really shouldn’t be too hard to pick up (think about it, is Java’s syntax harder to learn or all of it’s class libraries… and since Groovy’s class libraries are Java’s class libraries…).

    I think it’s important not to force the issue, though. If you haven’t found a use for Groovy yet, don’t use it yet. At the very least, however, Groovy _is_ “a new toy to play with”. So if you have a sandpit and enjoy playing with those kinds of toys, Groovy is a lot of fun.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'