Dynamically-typed languages became popular in the 2000's decade in the same way visual programming became popular in the 1990's. Programmers and their managers discovered they were more "productive" with them up to a certain scale, so in corporate IT they started being used, especially for web programming where technical debt is generally left to be cleaned up by others. But the trend has reversed back to statically-typed languages over the past 5 years. (Tiobe used to show the trend reversal graph on its front page every month, but removed it recently.) Probably one or two dynamic languages will remain, perhaps PHP and Python, just as VB has lingered from the visual programming fad.

Regarding Groovy specifically... It's used for very small use cases, like gluing Java apps together, writing tests for Java objects, basically stuff that won't become a standalone app. Because of Groovy's MOP, it's used for Grails - I don't know much about Grails but its popularity seems to be coupled to Rails' decline. Gradle will be going polyglot soon enough - their Gradle 2 roadmap [1] says they're shifting control of the build from the "Gradle build language" to a configuration-on-demand build model.

[1] http://forums.gradle.org/gradle/topics/revolutionary_new_gra...

I had this problem coming from a C# background into Rails. I found myself wasting a lot of time doing the same things you're doing. Ultimately though the gains far outweighed any initial slowness. Of course this is most likely a result of Rails than plain old Ruby (dynamic language).

My takeaway is, don't get discouraged by the initial 3 months of wonkiness, it'll get better the more familiar you are with the language.

For larger codebases though, I vastly prefer strongly typed languages.

For what type of programming? Building an embedded system is very different from building a database engine is very different from building a webapp or computer game.

I've found that dynamic languages are significantly more productive for prototyping and green-field development, at the cost of being significantly less productive for maintaining large existing software systems. And they are significantly more productive for uses where the main data types are strings, tables, and dictionaries (eg. webapps, CRUDScreen reports, command-line scripts) than uses where you need significant structured data (eg. business logic, hardware design).

Usually this means that you will need to use both - a static language forms the underlying substrate for the program, but a dynamic language lets you script and manipulate those components easily to quickly try out new features.

The issue you describe is a learning-curve one, not one specific to dynamic languages. Once you get familiar with Gradle you'll memorize most of the elements that you need on a regular basis. If instead of learning one particular popular software package, though, you had to learn the whole innards of a complex proprietary application, dynamic languages wouldn't save you any time.

Thanks for your response.

I was writing a simple web service which also makes REST calls to other REST services which may or may not respond in JSON. Seems like a sweet spot use case for Grails.

After trying both ways, I find that types help a lot, helping me write correct code faster and modify the codebase with greater confidence. Currently I'm using Scala which I believe provides a good mix of expressiveness and type safety.

You should look at Scala. It really feels like the best of both worlds: strong, statically typed without the boilerplate.

Scala is what I was looking for when I found Groovy.

I'm more productive with Scala than I ever was with Java, and Scala is very strongly typed. Statically typed languages aren't always less productive than dynamic languages, but the straightjacket of a language known as Java is.

Scala books ordered! I have the original book written by Oderksy but it's pretty old a this point so I ordered 2 books from the in Action series and one on the Play framework.

Let's see how this works out. The only negatives I have heard about Scala are the binary compatibility issues with dependencies and Scala versions.

I had shied away from Scala before since I didn't see any clear dependency injection support (can't live without it) but seems like that has been solved with the Spring Scala module.

I've never used Scala, but a few weeks ago it was really hot outside so I walked into a book store to cool off. I noticed "Scala for the Impatient"[0] was sitting on the bookshelf and I was intrigued. I sat down with the book and about an hour and a half went by without looking up. I think it's a great book and a very interesting language. I might have explored Scala more if I wasn't already quite busy with Elixir[1].

0 - http://www.horstmann.com/scala/index.html

1 - http://elixir-lang.org/

I've been using scala-guice for dependency injection. Play supports DI for controllers.

> The only negatives I have heard about Scala are the binary compatibility issues with dependencies and Scala versions.

You might have heard people complaining, but it's kind of complaining at a very high level.

Scala's compatibility story is better than most other languages, it's just that a significant part of Scala developers come from Java, where people expect that _nothing_ _ever_ changes.

Scala is not like that, it has a deprecation policy which includes actually removing stuff.

> I had shied away from Scala before since I didn't see any clear dependency injection support (can't live without it) but seems like that has been solved with the Spring Scala module.

Not sure I'd call that idiomatic Scala. There are a few DI libraries in Scala, but I'd say that the language reduces the need for DI a lot. You can of course use everything from legacy Java stuff like Spring, Guice, CDI to Scala libraries like SubCut, MacWire or Scaldi.

I have actually never had problems with Eclipse. It's still my preferred IDE for JAVA but it doesn't have the same support for Groovy and Grails as IntelliJ. I personally feel the concept of IntelliJ being the superior IDE developed years ago when maybe Eclipse was still heavily being developed. At this point, I feel both are on par for Java development but not so much for other languages.