The Cafes » Blogroll

In this illuminating post Stephen Colebourne demonstrates exactly why operator overloading is a bad idea. Now mind, you, he doesn’t think that’s what he’s doing. He actually believes he’s making the case for operator overloading. However the mistakes he makes are exactly the sort of mistakes likely to be made by almost anyone without at least an undergraduate degree in mathematics who tries to overload +, -, *, and especially /. If you don’t know the difference between a group, a ring, and a field, you have no business overloading operators.

Now I’m not saying that one has to take a course in abstract algebra before you can be a competent programmer. You don’t as long as the language you program in doesn’t support operator overloading (or as long as you’re wise enough not to use it if it does). However since most programmers are didn’t get beyond ODEs in college (if indeed they got that far–some of my comp sci friends struggled mightily with calculus and had to retake it repeatedly), one can’t responsibly design a language that requires mathematical sophistication in the 99th percentile for proper use. Probably one should stop with high school algebra.

Features that are guaranteed to be misused should be eliminated. In the specific case of operator overloading, I daresay, the feature will be misused far more often than it will be used properly. There are only about a dozen or so cases where operator overloading is called for, and only one is even remotely common. That one is complex arithmetic, and this single use case could be better handled by adding a complex type to the language. Arguably BigDecimal and BigInteger are a second and a third. The remaining cases are so incredibly esoteric that only a mathematician or an occasional physicist could possibly be interested in them. Can anyone name even one?

Perhaps the continuing confusion over the difference between checked and runtime exceptions in Java is because we haven’t named them properly. Mosts texts and teachers, including myself, have traditionally focused on how and when you handle the exceptions (compile time or runtime) rather than on what causes each. I propose a modification, not in code, but in terminology and teaching. Specifically I think we should should start calling checked exceptions “external exceptions” and runtime exceptions “internal exceptions”.
(more…)

Yet another hideous idea from the closures camp: removing checked exceptions from the language. Now they want to remove one of the features from Java that actually works to support their pet obfuscation.

According to Neal Gafter:

We did a Google search to see how many people have written in support of checked exceptions and how many people don’t like them. The discussion seems to be lopsided against checked exceptions, but on the other hand that may be due to the fact that checked exceptions are the status quo.

For his next Google search, let me just say, I like checked exceptions and I want to keep them. The people who object to checked exceptions mostly seem not to know the difference between checked and unchecked. Most importantly, they seem not to know when to use checked exceptions and when to use unchecked exceptions. A few libraries such as the Java USB API even get this exactly backwards. And I will admit, if you don’t know this crucial piece of information, then checked exceptions seem ugly and confusing.
(more…)

There’s a common but mistaken belief that proper user interface design requires lots of pictures and icons. In fact, it doesn’t. Many concepts and actions can be fully and best conveyed by text. While standard icons for directories and disks and the like can be helpful, custom icons for an application’s unique actions rarely are. The fact is, most icons are not self-explanatory; and if they’re not common enough to be standardized, they’re not common enough to be learned easily.

Nonetheless, many applications persist in creating pointless, incomprehensible toolbars. Icon design is hard. It is not something that just any art school graduate with mad Photoshop skills can accomplish. Icon design is about conveying an idea with pictures. not merely making a 32×32 bitmap look pretty. It’s hard enough coming up with a good icon for basic actions like cut and paste. Now try imagining one for “Analyze Module Dependencies” or “View Breakpoints”. There’s a reason Susan Kare gets the big bucks.

Lately, this trend seems to have seeped into menus, where text used to rule supreme. For instance, look at this File menu from IntelliJ IDEA 6.0:

Not only do the icons add nothing to the menu items. They actually make the menu harder to scan and read because the items are no longer left aligned.
(more…)

Peter von der Ahé and a few others are pushing type inference in Java 7. The goal is to not have to explicitly declare local variable types. Remi Forax offers this example:

  // print a frequency table of words
  public static void main(String[] args) {
    map := new HashMap<String, Integer>();
    for(word : args) {
      freq := map.get(word);
      map.put(word, (freq==null) ? 1 : freq+1);
    }
    System.out.println(map);
  }

(more…)