Friday, November 10, 2006

Why is Bruce Eckel arguing about typing?

In his article entitled "How to argue about typing", Bruce Eckel presents another argument against the downsides of Java's Strongly typed system. So let's analyze a few of the things he is most certainly right about:
  • Checked Exceptions == Evil. No question.
  • The fact that something like Eclipse generates code for you should not be an excuse for static typing. Code generation means duplication. In terms of DRY you are still repeating yourself whether it is generated or not. This makes code longer and harder to read.
  • You shouldn't feel your system is more robust and "safer" because it uses static typing. This is a naive approach to development.
Ok, so that is the good stuff out the way. However, the problem I have with Bruce's article is that it again tries to turn the static vs. dynamic typing argument into, ummm.. an argument. Why are we arguing about this? In my view you should be picking the right tool for the job.

This is so fundamental. I mean both paradigms have their strengths and weaknesses, why does one rule out the other? Bruce's article implies the only benefit you get from static-typing is the knowledge that your application is checked at compile time for type safety, which represents a false sense of security anyway. Fundamentally, he says, all you're doing is testing, which you should have unit tests for anyway.

However, when I use Java I don't use it to feel "safe". I use it for the advanced code navigation, refactoring and analysis tools that you get in modern IDEs like Eclipse or IDEA. These tools are not just about generating code, they're about being able to easily maintain your codebase and allow it to scale in terms of complexity.

But, of course, Java is horribly verbose and is not suited to every task. In this sense I would say it is essential that every developer know both a dynamically typed and statically typed language so that you can use a blended approach to development. Getting the best of both worlds.

The thing is, in Agile one of the issues known to reduce productivity is task switching. If you are constantly switching between different programming environments that don't integrate seamlessly with each other you will become less productive. Fact. Also, if you can't easily integrate the two you will end up writing duplicate code for each platform, violating DRY.

This is the fundamental reason why I believe Groovy will be hugely successful. By integrating so tightly with Java and providing a seamless transition with the same APIs and object model it significantly reduces task switching and integration overhead.

My advice: Don't enter this debate. There is really nothing to argue about, choose the best tool for the job and use it. Sometimes that may be a statically typed language like Java, C# and so on other times it may be a dynamic language like Ruby, Groovy or Python. Choice is a good thing people.

4 comments:

Anonymous said...

If you have the option (tech insight, product oppertunity and mandate by management) surely go for the right tool for the job!

However in my experiences, this is rarely the norm. The words "Here we program in Java" coming from an authority acts as a law/standard which weighs heavier than everyday productivity and programmer happiness (which usually requires a succeedingly better medium of expression).

And didn't Java set out to achive exactly this, one language to rule them all? In the browser, on the server, on the desktop and in embedded devices.

Bruce Eckel has moved on from Java, as have indeed many other revolutionary "hacking personalities". I myself am at a frustrating Java lock-in and is trying to come togehter with the fact that the neat language/API I got to know as Java 1.2 with ~4000 classes is now a monster of ~16.000 classes and being patched up in various half-hearted ways.

translucent_eye said...

I agree with your thought that Groovy will become the dynamic language of choice because it allows you to skip the verbosity for a good deal of the tasks, but at the same time use and build on all of the tools and projects that have come out for java.

And lets not forget Grails....

Anonymous said...

Specifically:

'come from' (CTRL+SHIFT+H in mac bindings eclipse): Find all places in the entire project which might call on this code.

'follow' (CMD+CLICK): Where is this identifier defined/take me to this method or class description.

'auto-complete' (CTRL+SPACE): Given this expression, what kinda things can I do with this?

'javadoc popup (MOUSE-OVER): What's this method actually supposed to do?


These tools are invaluable. The all-objects-are-maps tactics used by e.g. Ruby, Python and Javascript make all of that fundamentally impossible to do right.

I hear a lot of python folk state that auto-complete 'sort of works', but how could it?

def someFunction(someParameter):
someParameter(press CTRL+SPACE here)

now what? There's no way to figure out what someParameter could be - halting problem being what it is.

I don't really get the care given to Bruce's arguments. Anyone who thinks static typing is there to help you avoid your local language's equivalent of the ClassCastException is clearly an idiot. I know that's harsh language, but, if you've used java for so many years, and you never realized the fancy stunts you can pull with all that typing information, you just Fail It.

Am I missing something?

Anonymous said...

The difference is that sure, you get something from static typing... but you can't always have it anyway and nobody seems to be interesting in providing a solution to these corner-cases in Java. I.e. a ton of markup, JDBC SQL or JPQL which is heavily used on any enterprise backend, is not type checked in any way, shape or form:

SELECT [Everything in the universe] from [Every possible tablename in the universe]

And what about the half-hearted implementation of generics? The type information is lost so good luck getting assistance from reflection/introspection on these.

The dynamic camp argues that a quick write-run-debug cycle (compared to having to wait for an app server, compilation etc.) and unittests achieves the same but faster. After all, people did program before we had these very fancy IDE's. I like the productivity of dynamic languages and have more trust in these (Groovy, Grails, F3 etc.) than Java itself on the JVM. Especially if the JRE is modualized down to a headless core and gets a package management system for the rest a la gems/cpan.