Can you have too much of “dynamic” in dynamic languages?

Question

In last few months I have been making a transition from Java to Groovy and I can appreciate many of the benefits it brings: less code, closures, builders, MOP that in the end makes framework like Grails possible, ease with mocking when writing tests etc.

However, I have been “accused” by my coworkers that my code is not groovy enough. Namely, I still declare types for my parameters and fields, tend to use inheritance and polymorphism instead of duck typing etc. It seems to me that in these situations it is not only dynamic vs. static, but also dynamic vs. object-oriented paradigm kind of dilemma. In those cases I still tend to prefer OO. I feel that OO paradigm has great value in its basic premise in allowing you to abstract and relate your code constructs to particular real-world concepts.

So, here are particular questions I need help with:

1. Should I declare types for my parameters, fields, etc?

2. Should I declare block of code as closure when simple method will do?

3. When should I use duck typing instead of polymorphic dynamic dispatch. For example, in groovy I can do animal."$action"() or def animal; animal.action() , instead of Animal animal = new Dog(); animal.action(). I can see the problem with first in the context of Open-Closed principle, but any other reasons to prefer OO style polymorphism?

4. When should I use interfaces in groovy (if ever)?

I am sure that there are some other similar dilemmas I failed to write down. I also think that these questions are valid not just for groovy, but for any other dynamic language. What is your opinion?

Answer 1

This isn't always a popular opinion, but I think that the more explicit and clear your code can be, the better.

I dislike constructs that leave you guessing just what's going on...

I worked for a year in Ruby and didn't like it at all. I'm not saying that it doesn't have places where it excels, I'm just saying that I really like to keep things clean and explicit and didn't feel that Ruby had that as a goal.

One thing I did figure out for sure--the amount of typing you do does not equate to overall development speed. It's true that a complicated code base with a lot of repeated code makes for very slow development, but simply reducing what you type without eliminating the duplication is useless, and typing longer, clearer, more explicit code is going to generally be faster (over the length of the project) than the same code written in a terse, less formal language.

If you don't believe that typing has no relation to development speed, next time you release a project count the number of lines of code and divide by the man-days spent (including debugging and testing). In other words, how much code was typed a day. You'll find the result to be a very small number--actually typing code is a very small part of any software project.

Answer 2

I think with Groovy you should favor the simplest way of doing something, and fall back on the groovier features only when the situation calls for it. (Like when writing macros or creating multimethods in Clojure, if you find yourself reaching for those tools a lot you should question yourself.) Your cautious approach seems fine to me, possibly your co-workers are a little intoxicated with their new-found power. (It wouldn't be the first time.)

The good thing about having a flexible language like Groovy is you can start off with the cautious approach like you favor knowing you have more powerful alternatives to fall back on when you need them. You know, "the simplest thing that could possibly work."

More specifically preferring duck typing over interfaces and not bothering with types on parameters seems like it could be a good thing, it may make it a lot easier to supply mocks to tests.