Ask HN: Are dynamic languages more productive?

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.

There has been a battle in academic CS for years over this issue and there have been no conclusive results.

In practice, static languages run faster than dynamic languages and IDE tooling is better for static languages. Big advances have been made in dynamic language compilers, however, and there is big talk about better IDEs for dynamic languages although I don't buy it.

In my view a good IDE (IntelliJ, not Eclipse) is important for being productive in Java. A good IDE helps maximize the benefits of static languages. For instance, if you have an IDE you can do automated renaming and similar refactorings, something you probably will never do without the IDE or with a dynamic language.

One trouble is that people in the Open Source world often expect all GUI programs to suck compared to, say, vim. Thus there is a lot of tolerance for half-baked products like Eclipse. People don't expect IDEs to work, in fact they think they are a symptom of people having weak minds, so they keep using products that are broken. In particular, Eclipse is sick with pluginitis. It almost works if you get one of the prebuilt configurations but after a few plugins get installed it goes bad the way cheese goes bad.

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.

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.

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.

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.