CODEWITHSUNDEEP
javac++rubyclojuretype-systems
Hamza Yerlikaya
Hamza Yerlikaya

Reputation: 49329

From Static Typing to Dynamic Typing

I have always worked on statically typed languages (C/C++, Java). I have been playing with Clojure and I really like it.

One thing I am worried about is: say that I have a windows that takes 3 modules as arguments and along the way the requirements change and I need to pass another module to the function. I just change the function and the compiler complains everywhere I used it. But in Clojure it won't complain until the function is called. I can just do a regex search and replace but it seems there is a chance to miss a call and it will go unnoticed until that function is actually called. How do you guys deal with this?

Upvotes: 5

Views: 1203

Answers (8)

Ivan Pierre
Ivan Pierre

Reputation: 818

If you really need static typing, you can use https://github.com/clojure/core.typed and it's leiningen module to test static variable passing.

Upvotes: 0

Jim Downing
Jim Downing

Reputation: 1491

You're not completely without compiler support in Clojure. In the specific example you give, it's the arity of the function that changed, which would be picked up by compiling the Clojure code. I'm still making the strong -> dynamic typing transition and find this comforting!

Upvotes: 1

tomjen
tomjen

Reputation: 3889

You do the same thing you did if the method was part of a public interface that you weren't the only user of.

You add a new method with the extra module and and change the old one to call the new one with a suitable default.

Oh and if your program is that big, make sure you have good tests (test-is should make it simpler than Java)

Upvotes: 2

ndp
ndp

Reputation: 21996

Test coverage is definitely important. But a dynamically typed language will allow you to work in a different way. In a strongly typed language (like Java), a change in the interface needs to modify all the callers. In Ruby, you could do this-- but probably won't. Instead, you'll probably add flexibility to the method on one of a few ways. Namely:

  • you tend to have very few methods that take as many as three parameters in Ruby (as opposed to Java). Because you don't have strong typed interface of Java, you break the problem down into smaller pieces and steps. It's much more common to write methods that take just 1 parameter, and then refactor when it becomes more complex.
  • it's possible-- and common-- to leave the old behavior in place while adding more arguments. For example, if you have to add a third argument to a two argument method, you will set its default value to preserve the old behavior (and save you a refactor). If you are familiar with Javascript libraries like jQuery, they take advantage of this everywhere with "optional" arguments.
  • similar to optional arguments, methods can grow to take a flexible parameter list. With solid test coverage, you can quite easily add a new behavior to an existing method and safely know you haven't broken the existing code. In Rails, methods like "render" take a wide range of options.

Upvotes: 1

Edan Maor
Edan Maor

Reputation: 10052

The first thing I'd like to mention is that Bruce Eckel has written a very interesting article called Strong Typing vs Strong Testing (the link is down at the moment, unfortunately, but hopefully it will be up soon).

His idea is that when dealing with compiled languages, the compiler is just acting as the first, automatic step of automatic testing. When making the move to a dynamic language, you lose this first level of automatic testing. But in both cases, this first, automatic level is just one part of testing, and not even a very important part.

His point is that if you're developing programs properly, i.e. doing some form of tests and regression tests, the lack of a compiler will only force you to add some more, somewhat basic tests anyways, which is why it's no big loss.

So I guess the first answer I'd give you is, focus on your testing, something you should be doing anyway, and such changes shouldn't affect you too badly.

The second thing I'd like to mention is many dynamic languages that I've seen (for example, Python) have much better abilities to change what methods/classes do without breaking existing code.

For example, with Python, if your method used to accept two parameters but now requires a third one, you can always add a default parameter without breaking any existing code, but that you can now utilize. This is a very basic technique, but in Python's case (and I assume most other dynamic languages as well), these techniques can get much more interesting; since they're dynamic, you can pretty much change the implementation of functions for specific modules, change what variables mean, etc.

I'd suggest looking at which techniques Clojure has that allow similair things, and deciding if they apply in your situation.

Upvotes: 3

urmalp
urmalp

Reputation: 382

Tim Bray discusses it here,critique of which by Cedric is here,and a post on artima discussing it at length.

Upvotes: 0

Vitali
Vitali

Reputation: 3695

You lose some level of refactoring and type safety when you move to dynamic languages. The more information the compiler has, the more it can do at compile time for you.

Upvotes: 0

zgchurch
zgchurch

Reputation: 2322

This is one of the reasons automated testing/test driven development is even more important in dynamically typed languages. I haven't used Clojure (I mostly use Ruby), so unfortunately I can't recommend a specific testing framework.

Upvotes: 8

Related Questions