Just some thoughts following a recent conversation I had. Don't we always want static types? If we can detect errors in our program, why not do it as early as possible? Sure. So when is "as early as possible"? I think the answer depends on what our program is - is it one monolithic piece or a component?
I have already blogged about the danger of numeric overflows. I recently came across this example in Java course materials (!!!):
public class Foo implements Comparable<Foo> {
private int number;
public int compareTo(Foo o) {
if (this == o) return 0;
return number - o.number;
}
}
How do you think Integer.MAX_VALUE compares to negative numbers? It will appear smaller. This reminds me of even worse case we encountered in a real codebase. Look at this:public class Foo implements Comparable<Foo> {
private long id;
//...
public int compareTo(Foo o) {
if (this == o) return 0;
return (int)(id - o.id);
}
public boolean equals(Object o) {
return o != null && (o instanceOf Foo) && compareTo((Foo)o) == 0;
}
}How do you think new Foo(8325671243L) and new Foo(25505540427L) compare? They are equal, but I will do it ala Weiqi Gao and leave you to find out why... :-)
After some interesting comments to my previous write-up I decided to make a follow-up post with some additional details.
public class Person {
private final Date birthDate;
//...
private static final Date BOOM_START;
private static final Date BOOM_END;
static {
Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
BOOM_START = gmtCal.getTime();
gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
BOOM_END = gmtCal.getTime();
}
public boolean isBabyBoomer() {
return birthDate.compareTo(BOOM_START) >= 0 &&
birthDate.compareTo(BOOM_END) < 0;
}
}
public class BabyBoom {
private static final BabyBoom boom = new BabyBoom();
private Date start = null;
private Date end = null;
private BabyBoom() {}
public static BabyBoom getInstance() {
if (boom.start == null || boom.end == null) {
Calendar gmtCal = Calendar.getInstance(TimeZone.getTimeZone("GMT"));
gmtCal.set(1946, Calendar.JANUARY, 1, 0, 0, 0);
boom.start = gmtCal.getTime();
gmtCal.set(1965, Calendar.JANUARY, 1, 0, 0, 0);
boom.end = gmtCal.getTime();
}
return boom;
}
public boolean contains(Date birthDate) {
return birthDate.compareTo(start) >= 0 && birthDate.compareTo(end) < 0;
}
}
public class Person {
private final Date birthDate;
//...
public boolean isBabyBoomer() {
BabyBoom boom = BabyBoom.getInstance();
return boom.contains(birthDate);
}
}
Java Practices call Cloneable/Object#clone API pathalogical and suggest to avoid it. I have to agree. Here's my little story.
public interface ReallyCloneable extends Cloneable {
public Object clone() _
}public interface ReallyCloneable extends Cloneable {
public Object clone() throws CloneNotSupportedException;
}public Object clone() throws CloneNotSupportedException {
return super.clone();
}try {
//call clone
} catch (CloneNotSupportedException e) {
//handle it... how???
}public Object clone() {
try {
return super.clone();
} catch (CloneNotSupportedException e) {
//hm...?
}
}public class CloneFailedException extends RuntimeException {
public CloneFailedException() {
super();
}
public CloneFailedException(CloneNotSupportedException e) {
super(e);
}
}public Object clone() {
try {
return super.clone();
} catch (CloneNotSupportedException e) {
throw new CloneFailedException(e);
}
}Do you feel that your programming language is too bloated? I do, and I know I am not alone.
The premise of this subject is that computers should adapt to the ways of people, and not the other way around.
Here's a thought. Why do Java Generics attract so much bad vibes? If we're talking about types again, gotta visit our old friends - ML, Haskell. They are doing fine, they've got it all figured out. Hindley-Milner etc., they've proved themselves to be right.
But them and Java, it's apples and oranges. So to bring them to the same arena with object oriented languages, let's see how are they doing on the front of extensibility? Well, there are some recent advancements, polymorphic variants in OCaml, extensible records in Haskell, but it's not like the other stuff they've figured out ages ago, there's a slight hint of hesitation here.
So having types and being object oriented at the same time - maybe it's just, hm, non-trivial. If Martin Odersky says it's hard for the compiler (and he's a genius!) - then it really must be. Now look at it as a reverse Turing test - if the machine can't figure it out, how the **** are we supposed to? Which means we need an escape route. If declaring the right type is hard, we need an easy way out.
Pre-generics Java didn't bother itself too much with complex static types, the trick was to fall back on the dynamic types whenever in doubt: arrays - ArrayStoreException, collections - ClassCastException. Some say it's broken. It's a hole in a fence, but it's a way out . "Oops"
Then Generics came and fixed the hole in the fence. But, without realizing, they violated the status-quo, the eco-system, they stepped on a butterfly. Suddenly, the brain hurts, and the only way out is dumping all the angle brackets and jumping over the fence. It's a "No Exit"!
What does Scala do? Ah! First of all Scala has a much more advanced type system to start with. But the real trick is implicits. If it's too hard to declare the right type, just imperatively describe the conversion. Done deal, here's your way out. It's pretty cool, but implicits have their share of bad vibes too. Can't live with them, can't live without them, I guess.
So how about implicits for Java 7? No, actually how about Scala for Java 7? It's been done before, you know...
What hasn't been said about static vs. dynamic types in programming languages? Read on at your own risk, because here I go again...
When you think of static types what comes to mind? Haskell? OCaml? Scala? Dear friend, you are better than most of us, but you have clicked the wrong URL. Peace. See you in another post...
Did you say Java? Still with me? Good. Listen, now when the others have gone, just between you and me, the guys from the previous paragraph - they're on to some good stuff. Check it out, you won't regret it. But don't quit your day job, not just yet. It's a bit complicated, but did you ever witness extreme programming methodology implemented in a big corporation? No? Then picture this: Elbonians take over Dilbert's firm and make everybody do XP. They even send pointy-haired boss to a Certified Scrum Master course. Get the outcome? It can only end like the implementation of Carl Marx's ideas in Russian countryside. I am trying to say - there are ideals, and there is reality. In reality, Haskell programs have bugs too.
So Java, you say. How do you feel about dynamic types? Cool? Get out of here. No really, it's no fun preaching to the converted. See you!
Oh no, heaven forbid, you won't touch them with a stick. You're my guy then. So let's rewind to Java 1.4 days, after all many Java developers still use 1.4 and many others look back at it with nostalgia. Are you one of them? Ok. So what about pre-generics collections, do you think they are statically typed? Hmmm... And what percentage of your code involves collections? So this code was not entirely statically checked. Now add all the reflection stuff...
But then of course came Generics. And suddenly Java is much more complex. How do I make my code compile, gee, wildcards, captures... ?! I am trying to get something done, hello!... It's easy of course to blame Generics implementation, but if we learn something from the folks whom I kindly asked to leave in the beginning, they'll tell you that finding correct static type for every element in your program is hard. They of course think that hard is good, they are noble men with ideals, they like overcoming challenges. But you and I, we're just trying to make a living. So we curse Sun and back off to an untyped collection. Hm, maybe we're just doing the right thing? Maybe sometimes we just know that our program is correct, but the compiler demands more and more typing and wastes our time?
Java 5 was all about improving type-checking. If pre-defined types were not enough, annotations came handy. Define your own and test it at compile-time or at run-time. Did it ever happen to you that there were so many annotations, that you couldn't see the code?
See, more types is not always a good thing. Unless you're very keen on intellectual challenges. James Gosling said this about Scala - functional programs will make your brain hurt, they are for calculus lovers. He's right. It's the kind of pain you feel in your muscles when you start working out, you know, that indicates they are still alive... So working out is good, but we can't afford doing it all day, ha?
Maybe the appeal of plain old Java was that it's a combination of static and dynamic checks? So it's not that all dynamic is evil, maybe it's a matter of how much and where?
Give dynamic types a break. Who knows, you may find eventually that they're good for some things.
Peace.
P.S. I've done some role playing here, just for the record. I do love Generics, even though they were hard to master. Annotations are overall very useful. Right now I don't do as much Java as I used to, and I do other fascinating languages (static and dynamic) as I, for long time, wanted to.
Posts
