Static vs. Dynamic Typing

, Mar 15, 2006

A fair and balanced (well, not really) look at the static vs. dynamic typing schism.

I used to be a strong believer in static typing back when I was doing C++ programming. (That was actually something I did for a really long time — I was, in fact, somewhat religiously convinced there was a multitude of conceptual advantages C++ had over Smalltalk. Blame it on my youth.) Nowadays, the only advantage of static typing I still concede is the better support for IDEs and code completion, which you arguably would not need if you didn’t start with a verbose, unmanageable and ungrowable language in the first place.

On March 15, 2006 8:10 PM, Al Lang said:

“… which you arguably would not need if you didn’t start with a verbose, unmanageable and ungrowable language in the first place”

I find good IDE support and code completion utterly invaluable when working on a large codebase with which I’m not familiar. I’m not sure I’m ready to trade that off for a sexier programming language.

On March 15, 2006 11:01 PM, Stefan Tilkov said:

When I’m programming Java, I find I’m addicted to an IDE, and I don’t really care whether it’s IDEA or Eclipse - I just need something to help me navigate through the gazillions of classes that form the code base. I still believe that even though there may be many, many classes to navigate through, a more expressive language would be able to transport the same business logic in much fewer lines of code - which would reduce the need dramatically. Still, I don’t have any convincing numbers that tell me whether this is really true; it’s just a gut feeling based on playing around with more dynamic languages (specifically Ruby) recently.

On March 23, 2006 3:38 PM, Oliver Weise said:

Since I don’t know many dynamic languages well, I’m curious what you mean how a “more expressive language” can help us getting rid of complex APIs, which are the main cause why we need IDEs. Can you give a hint how ruby as a language might make work easier without the need for something like automatic method lookup (I would assume it has something to do with building “domain specific languages”) ?

I used to think that API complexity in Java is not so much a problem of the language itself but that

a) there are just so many different and complicated things you can do in java and

b) some API vendors very heavily tend to make APIs very abstract and complex to hit nearly 100% of all possible usage scenarios (which results in the fact that API usage will be significantly harder for the first 90%)

So any language would suffer this fate, that either is used for many tasks and/or is dominated by people with a certain abstraction fetish. Well, I would love to see that I’m wrong here. So maybe I should give Ruby a shot myself.

On March 23, 2006 11:35 PM, Stefan Tilkov said:

You assume correctly, the DSL approach is what I believe makes Ruby different from, say Python. If you take a closer look at Ruby on Rails (which you should), you can see a lot of examples.

In contrast, Java, J2EE and specifically EJB require so much ultimately meaningless syntax decorations that they’re a pain to use without appropriate supporting technology (generators and IDEs).