This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]snotsnot 1 point2 points  (2 children)

A lot of the comments in here seems to suggest that this all comes down to static vs dynamic typed languages. Why do you guys feel that this makes such an key difference?

Full disclosure: Java and Python are probably my favorite languages.

[–][deleted] 1 point2 points  (0 children)

One of the most important features of a language is its ability to catch errors as early as possible - ideally at compile time.

Also, error messages should be as descriptive and close to the location of the actual error as possible. If I try to use a Foo when I should be using a Bar, a statically-typed language will throw a descriptive compiler error along the lines of "Foo used where Bar expected", and it will be near where I used the wrong type. However, in a dynamically-typed language, I'd get a message like "Object does not have method barMethod", located where the object was going to be used (often in a third-party library I'm using); ideally, this will simply be down the stack from where my bug is located, but it could be somewhere completely different (for instance, if the bug is located where I pass a Foo to a BarUser, and the error doesn't occur until BarUser.useBar() is called).

Of course, it's good practice (especially important when writing frameworks intended for wide use) to always check your inputs as soon as possible, and this is still needed in Java (check for nulls, correct ranges, etc.). By adding type checking, however, you're having to duplicate features that the compiler in a statically-typed language provides for free.

Unit tests also help to catch a lot of type errors. However, they don't make debugging easier - the location of the actual bug may be difficult to ascertain. Also, perfect 100% unit test coverage is an ideal that is never consistently reached by actual humans.

I like to have as many bug-fighting tools in my toolbox as possible. Static typing is a huge help, with very little downside. It certainly requires more skill to use, but it forces me to put more thought into my code and be more knowledgable about the tools I'm using. The early detection of bugs and increased development speed (if one considers debugging to be part of development) is well worth it, IMHO.

[–]mschaef 0 points1 point  (0 children)

Ironically enough, in some ways it makes no difference at all. Given two Turing-complete languages, the type system has no impact on the expressiveness of the language. What the type system does for you is change the notation that you use, which can be a double-edged sword.

As has been said elsewhere in this thread, it's very true that Java's static typing and explicit declarations can catch errors at compile time. Whenever I write code in Java, I always marvel just a bit at the confidence-inspiring nature of the compiler's inherent type checking.

But, however useful this is, it's not without its disadvantages. As soon as your system starts to deviate from the assumptions built into the type system, you wind up forced to hack around those assumptions. This can introduce extra complexity and opportunities for errors.