Firefox Faster than Internet Explorer

There's little doubt that Mozilla Firefox is a better browser than Microsoft Internet Explorer. It is easy to see how the tabbed browsing in Firefox make your life easier, as well its simplicity and better usability.
One thing that I wasn't sure of, though, was that Firefox is faster. Browsing speed can mean several different things, such as download time, how quickly the page is rendered, and so on. It is also quite difficult to quantify. But at least in one respect, Firefox is indeed much faster - scrolling. I've noticed that Internet Explorer seems to be quite sluggish when scrolling through a long page, so I tried to time just how sluggish is it. I opened a page containing about 190kb of text¹, held the "page down" key pressed, and measured how long it took for the browser to scroll through the whole document². The results were dramatic:

• Internet Explorer - 40 seconds
• Firefox - 3 seconds

So at least in one respect, Firefox is indeed much faster than Internet Explorer. Granted, on a faster computer the sluggishness of Internet Explorer may be less noticeable, but still it shows that something in its rendering engine scales very poorly.
¹ This is the page I used.
² Measured on a 800Mhz Pentium III.

Java API Pitfalls: Boolean.getBoolean(String)

Creating a public API is a task that should not be taken lightly. Any bad decision at this stage tends to become baked in, remaining there for posterity. One such lousy decision was made by an unnamed Sun engineer, eons ago when dinosaurs roamed the earth and the Java programming language was born.

I can imagine this developer thinking to himself "I really need a method that gets a boolean value from the system properties. Since this method returns a boolean, it obviously belongs in the Boolean class! Now let me think, should I call it getBooleanSystemProperty? Nah, that's way too long and I don't have an IDE with code completion. I'll just call it getBoolean - it's so much catchier and saves typing fourteen characters!".

And thus, the Boolean.getBoolean(String) method was born.

Cut to a few years later, a programmer needs to convert a String to a boolean value. Remembering that there's some static method in the Boolean class for this, she types "Boolean." and waits for the code completion popup to appear. Her eyes scan the list of method names, and stop at getBoolean. "This is it" she thinks, failing to notice that further down the list there's also a method called valueOf.

A few weeks pass until somebody notices that no matter what string value the program receives, it always treats it as "false". It takes another few hours to trace the cause of this bug to the innocent-looking call to getBoolean.

Now you may think that this story is fictitious, but I've seen this mistake being made at least twice. And the fault lies entirely with this method, which is located in the wrong class and has a name that does not convey its purpose accurately. If you don't believe me, just ask Glen Stampoultzis.

What surprises me the most is that Sun didn't choose to deprecate this method, as a way of admitting that they screwed up and flagging that it should not be used. And so, it remains a part of the core Java API, like a landmine waiting quietly to be stepped on by a poor victim.

Where Dynamically Typed Languages Fall Short

In the past, dynamically typed languages were considered to be more productive than statically typed ones, and I used to agree with that view. My past experience has shown me that Python, a dynamically typed language, is more productive than Java (statically typed). Somehow Python code feels more malleable and pliable, and making it do what you want is more hassle-free. For example, if you want a hashtable, you just write

map = ["R": "red", "B": "blue", "G": "green"]

instead of Java's tedious

HashMap map = new HashMap();
map.put("R", "red");
map.put("B", "blue");
map.put("G", "green");

I think the convenience of writing Python code can be attributed in equal amounts both to its elegant syntax, and to its dynamic types.

But now the landscape is changing. First, the introduction of the new Java language features in Java 5.0 makes Java code a lot more elegant. Second, and more important, is the appearance of really smart IDEs such as Eclipse. Zef Hemel has already noted that statically typed languages allow IDEs to offer features such as refactoring and code completion. But it goes even further than that.

When you open a Java source file in Eclipse, what you get is an extensively hyperlinked document. Ctrl+Click on any variable, method or class name brings you directly to its definition. Ctrl+G finds all the uses of the same. You can easily navigate to the superclass' implementation of any overridden method, or to all the subclasses that override it themselves.

These invaluable capabilities are made possible by the fact that the IDE knows everything, or more specifically - the type of every variable in the source code. And this is of course impossible in a dynamically typed language, since it's, well, dynamically typed. Consider the following Python function:

def func(x):
    x.doSomething()

The IDE has absolutely no way of knowing the type of x, and in fact it can be of any type that has a doSomething method. So inevitably, IDEs (and other tools) for statically typed languages can be much more advanced than IDEs for dynamically typed languages.

These advanced features - code completion, automatic refactoring and hyperlinked source code - greatly improve the developer's productivity, thereby closing the gap between dynamically and statically typed languages.