The Cafes » Blogroll

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…)

One consistent tendency I’ve noticed among undergraduate programmers is a persistent and incorrect belief that the number of lines of code is somehow tied to code efficiency. The thinking goes that the fewer lines they have, the faster the program will run. (Why they even care about speed at all is a story for another day.) For example, they get peeved when I write this:

int x;
int y;
int z;

instead of this:

int x, y, z;

The brighter ones may not be bothered by that, but this gets them all in a tizzy, nonetheless:

int low  = 1;
int high = 1;
for (int i = 0; i < 50; i++) {
  System.out.print(low);
  int temp = high;
  high = high + low;
  low = temp;
}

They want to see this

int low  = 1;
int high = 1;
int temp;
for (int i = 0; i < 50; i++) {
  System.out.print(low);
  temp = high;
  high = high + low;
  low = temp;
}

They love taking code out of a loop, even when the code in question (a declaration) doesn’t actually do anything; and they certainly don’t care if their resulting code is less readable. In fact, they sort of take it as a mark of honor if their code looks complex. They’re going to love closures.
(more…)

I’ve long been an advocate of outside-in API design. This reflects my interest in user-interface principles in API design. When designing a GUI it is customary to mock it up on paper and then with prototyping tools before implementing the internal code. This helps the interface reflect the user’s goals and expectations rather than the internal data structures of the program. In API design, this means the class becomes more easily usable by decoupled client code.

It occurs to me that the same principles apply in language design. In particular we should try writing some code with proposed new features before we implement the features. This has several advantages:

• Ensures we get what we need, rather than what the proposal supports
• Helps us understand exactly what is being proposed
• Shows the strengths and weaknesses of each proposal
• Avoids unnecessary features that don’t support a real use case

Consequently herewith are some challenges for the proposers of the various closure proposals. I’ve tried to make them as simple as possible so that the closure issues will be focused on.
(more…)