

Ask HN: Are dynamic languages more productive? - canterburry

I&#x27;ve been a backend Java dev for the last 12+ years but am trying to get more productive by switching to a more &quot;modern&quot; dynamic language.<p>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.<p>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.<p>Same thing with Gradle vs Maven. Since Maven uses a schema for it&#x27;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?<p>What am I doing wrong? Seems like this should be easier given how popular these languages have become.
======
vorg
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...](http://forums.gradle.org/gradle/topics/revolutionary_new_gradle_features_on_the_2014_roadmap)

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

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

~~~
canterburry
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.

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

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

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

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

~~~
frowaway001
> 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.

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

~~~
canterburry
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.

