Ask HN: Are dynamic languages more productive? | Hacker News Reader

Ask HN: Are dynamic languages more productive?

8 pointscanterburry13 comments

I've been a backend Java dev for the last 12+ years but am trying to get more productive by switching to a more "modern" dynamic language.

Recently however, I gave up in frustration trying Groovy + Grails + Gradle due to the amount of time I had to spend just figuring out the expected dynamic inputs to methods for libraries and components I was using. I.e. with a dynamic constructor I actually have to understand the structure of an entire component rather than just a method signature.

I gave up because I felt whatever savings I was reaping from the nice features of the language, I was loosing flipping back and forth between IDE and documentation, figuring out how a closure should be structured to serve as an input or what properties exist on some returned object. I even switched from Eclipse to IntelliJ since I heard Grails support was better.

Same thing with Gradle vs Maven. Since Maven uses a schema for it's configuration, I can quickly Ctrl + Space to the config element I need. Not so it seems with Gradle where I again had to flip back and forth to the docs. Maybe this is just an IDE support issue?

What am I doing wrong? Seems like this should be easier given how popular these languages have become.

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.

> 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'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.

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.

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.

Reply on news.ycombinator.com