Recently, I came across a debate with a colleague of mine about the pros and cons of static and dynamic typing. His position was dynamic typing is generally bad because static typing provide you ways to handle type mistakes. Common example: I don’t call my function/method/whatever with values of the correct type. I pass a string where I should pass an integer, etc.

But my position is that focusing on types is focusing on a non-existing problem. Let me explain: what does really matter when one wants to check the type of an object? You don’t check the type of an object just for the sake of type-checking. That’d be utterly stupid. No, what one really wants to know when she or he type-checks is actually: is this operation possible on this object? I.e, mainly, can this method be called on this object?

But you know what? You don’t really need static typing to ensure this. There are several ways to handle the problem, from semi-static typing to dynamic typing. For instance, Go or OCamL use structural typing. The idea is: if my object has methods with the same name and signature than the the type I’m manipulating, then it’s ok, I can consider it to be of this type. Java solves this the stupid way: interfaces — the fuck I hate interfaces!.

But dynamic languages are clearly superior on this point: I give you duck-typing FTW. The type of the object is deduced from the context. I may or may not be able to pass it a message but it’s not the language’s job to tell me what I can or cannot do. Possibly, I even may try to call method on the object that wasn’t explicitely declared. You may think that it’s stupid. You are stupid. It’s not. That’s what I was saying in my notes on OOP: calling a method that doesn’t exist is not always a mistake. It can have some practical application. Like GORM’s dynamic finders. Cedric Champeau, one of Groovy’s core developpers wrote a wonderful article full of things you can do with a dynamic language that you cannot with a static one.

But there’s a problem: you may do nasty things with a dynamic language that you wouldn’t with a static one. Because it always checks all types all the time. And you may be tired one day. And you may pass a variable that you received from somewhere else. And you may not notice it wasn’t actually a string but it was an integer. And you pass it to the wrong method. Well… Shit happend, right?

Nope.

Ok, I admit that my colleague made a good point when he told me that static typing adds a security that dynamic typing doesn’t provide. The point is: fail now rather than later. And, as compilation happens before interpretation, then it sounds reasonnable to make the application fail at compile-time.

My answer to that concern was: well, we have unit-testing for that. Now, I understand that it wasn’t a good answer at all. Because let’s be realistic: the bigger your programm is, the lesser you are likely to cover 100% of your code with unit tests. And even then, you can’t assert that your unit tests correctly cover your code. Because… Well… Sometimes you fail. And nothing can prevent you to fail sometimes. I suppose us, developpers, have a lot of stories about tests we were so certain they tested our code the way we though that we would have been ready to put our hand in the fire… To realize that we actually tested shit.

So, yes. Better fail at compile-time than at interpretation-time. But you know what happens even before compilation or interpretation? Syntactic analysis of your fracking IDE. Aaaaaaaaaand… That’s why Python developpers don’t fail more than Java ones1.

You may say me that not everybody uses an IDE. Rly!? Oh, yes, you may hear about developpers saying that they are pure. They use emacs. They don’t use clickodromes.

There are probably very few things that I hate more than elitism. When I hear this kind of sentences, I feel the irrepressible desire to hit its author’s head so hard with a pipe that it would instantly vaporize. Refusing to easier your life with proper tools doesn’t make you a good developper. It just makes you a dickhead.

So except these morons, I think nobody would sanely develop Java code without Eclipse — eeww… — , NetBeans — wait… what!? — or the best IDE in the world: IntelliJ2. At least because it’s easier to manage Maven projects with an IDE.

And modern languages tend to take the path of some kind of dynamic typing. Even officially static-typed ones. C++ introduced the auto keyword. Scala and Kotlin have val and var keywords. C♯ has dynamic. And there are even ways to make dynamic programming in Java, through reflection, generic’s type erasure or invokedynamic instruction…

So what’s the point here? The point is that tools have changed. And ways to develop too. Modern languages tend to drop curly braces and semi-colons because modern parsers are smart enough to understand line breaks as end of statements. My point is that static typing is like curly-braces and semi-colons: it is a relic from the past and we don’t need it anymore.

  1. I’d even say Java developpers tend to fail more than Python ones. Actually, developping in Java is a kind of fail itself… Ok, I’m a tiny bit opiniated, here. ↩

  2. Ok, I’m a little bit opiniated… ↩