Currently Reading: Groovy In Action

I'm about 75% through "Groovy In Action" and would recommend it as a great introduction to the power of scripting for Java developers. I'd also recommend reading "Programming Ruby" for a comparison to a similar, modern scripting language.

Main Thoughts:

In the corporate world I've been finding it a small uphill battle convincing talented Java developers that they should take scripting seriously. It will take a word-of-mouth campaign and probably better tools to get them on board. I suppose another way would be if someone came out with a "killer-app" written in Groovy.

Less code is less code (Or less code is like gold?)

Less code means less code to maintain and also less code to read through to understand what is going on. A main benefit of a higher level language is that the code you type has more to do with the objective and less to do with the boilerplate required to achieve that objective.

Put more succinctly: Groovy code is about an order of magnitude less than Java code performing a comparable function.

Less dependencies on Frameworks and Patterns

Getting proficient in a scripting language like Groovy will take less time than it takes to learn a new Java framework (JSF, Struts, Hibernate, etc) and may replace the need for one.

A good example of this is database persistence. In Java we have JDBC, EJB3, Hibernate, iBatis, Spring JDBC, etc. Some of these are pretty heavy frameworks that attempt to make database usage easier and less error-prone.

When you see an example of database usage from Groovy it really makes you wonder about why you'd want to jump to an external framework. The argument has often been that heavier frameworks like Hibernate take a lot of the work off your shoulders and reduce the amount of code needed. I've found that the size of the code just gets transferred to XML configuration and setup.

It seems very possible that with a language like Groovy you could have much of this power and security within the language itself, or at least with a much lighter support library.

If you could write your DAOs in Groovy I know Spring JDBC would be reduced down to a handful of technology-specific helper classes. Much of this API is resource handling, which is taken care of natively by Groovy's closures.

Design Patterns
A few years back at a conference, Dave Thomas (Pragmatic Programmers) made the comment that design patterns are a work around for deficiencies in a given programming language. It took some thinking for this idea to click but it makes so much sense. What is a design pattern other than simply boilerplate code for a concept not natively supported by the language you are using?

AOP/Visitor Pattern: Required in Java due to the lack of meta-programming that would allow interception of method calls.
Adaptor Pattern: Required in Java due to the lack of "duck typing" or "mix-ins"
Facade Pattern: Required in Java to hide usage complexity of heavy frameworks/APIs.

Side note: If you've done any tech hiring lately you'll notice how many resumes come in with "design patterns" on the technology list.