Ken Arnold's Blog

June 2005 Archives

Harmony

Names matter

A clue for the folks who run this conference: When I run into someone I've met at last year's JavaOne, what's the first thing I want from the conference badge? Let me give you a hint: it isn't to see whether they have the same X-Ray of a cell phone that every other attendee has. This may come as a surprise, but trust me on this.

I want to know their freakin' name.

I'm particularly bad at names, but I know I'm not the only one who needs the help. This is why conference badges traditionally have names on badges that are large enough to be read from a few feet away, sometimes even across a room, and occasionally are readable from low Earth orbit. This allows you to be reminded of someone's name when they greet you without peering in way that at best makes your memory failure obvious, or at worst will get you slapped.

This year's badges have print you can only read by grabbing the tag and pulling it up to your eyes, or by getting your nose closer to some folks than is actually healthful.

Whoever designed the badges needs to be forced to put their noses close to all the attendees until they get the point.

Miss Manners at JavaOne

Generics Considered Harmful

Generics are a mistake.

This is not a problem based on technical disagreements. It's a fundamental language design problem.

Any feature added to any system has to pass a basic test: If it adds complexity, is the benefit worth the cost? The more obscure or minor the benefit, the less complexity its worth. Sometimes this is referred to with the name “complexity budget”. A design should have a complexity budget to keep its overall complexity under control.

Generics are way out of whack. I have just finished (well, nearly) my work in the fourth edition of The Java Programming Language. I am glad to say that David Holmes, not I, was the one who covered generics. Just reviewing it and reading the specifications was enough to put my brain through a cuisinart stuck on “pulse”.

We went through that chapter multiple times, consulting with several people who wrote the specs and are otherwise experts. We were only able to cover the highest level in the book, and it's still pretty hard to understand (although David exceeded himself in making it as comprehensible as possible).

Learning to use generified types can get very complicated. It's hard to understand why you cannot do some things without casts, for example. But writing generified classes is rocket science. Here's one that showed up at the very last minute: It's a bad idea to declare a type that returns an array of a type parameter. That is, you shouldn't do this:

    interface Holder<T> {
        T[] toArray();
    }

Actually, I'm only mildly embarrassed to say that I've forgotten. But I remember that it took a few back-and-forths between David and the advising expert so that David — remember, David is the guy who has been writing a chapter on generics after several months of experimentation and research and over a year of thinking about how to approach it — could understand the problem. So our book recommends against it because it isn't good.

Although there is an exception. It's okay to do this if the method takes as a parameter an array of T or a Class<T> object:

        T[] toArray(Class);

Which brings up the problem that I always cite for C++: I call it the “N^th order exception to the exception rule.” It sounds like this: “You can do x, except in case y, unless y does z, in which case you can if ...”

Humans can't track this stuff. They are always loosing which exception to what other exception applies (or doesn't) in any given case.

Or, to show the same point in brief, consider this: Enum is actually a generic class defined as Enum<T extends Enum<T>>. You figure it out. We gave up trying to explain it. Our actual footnote on the subject says:

Enum is actually a generic class defined as Enum<T extends Enum<T>>. This circular definition is probably the most confounding generic type definition you are likely to encounter. We're assured by the type theorists that this is quite valid and significant, and that we should simply not think about it too much, for which we are grateful.

And we are grateful. But if we (meaning David) can't explain it so programmers can understand it, something is seriously wrong.

So now we know it's complex. But if it really saved your programming butt a lot it could be worth it. So what does it save you? It saves you making mistakes, like putting a String in a list that should only contain Longs, or attempting to pull out a String from such a list.

But we have a demonstration proof that we can live without it, namely that we have for nearly a decade. Of course there are such bugs in code, and if you generify a bunch of code you might even find one or two that were waiting to bite you (unless that code is actually orphaned). But I have yet to find someone who believes this to be a major source of error in their code, compared to other problems.

So we have a feature whose complexities are high, whose learning curve is steep, and whose benefit is limited. And add to that the feature is ubiquitous -- with Java 5 it is nearly possible to write code that doesn't interact with generics.

The complexity of Java has been turbocharged to what seems to me relatively small benefit. I don't see that the value is there to justify the cost. Not that we can change things, but I think we should at least view it as an demonstration proof of the value of an explicit complexity budget against which features must be justified. Without such a budget, it feels like the JSR process ran far ahead, without a step back to ask “Is this feature really necessary”. It seemed to just be understood that it was necessary.

It was understood wrong.

Oh no, not again

The place has certainly calmed down. Which is to be expected. The first JavaOne was at the rush of the .com boom. Everything was new, everyone was doing business with everyone else, new ideas, new possibilities. Every corner hid a new frisson. You felt you could just live off the vibes.

By now it's much more staid. After all, Java isn't this amazing new thing, it's a well-established part of the programming field. Then, finding someone with six months Java experience was really amazing, and that was almost certainly "playing with it because it was interesting". Now it's just another language that pops up on resumes everywhere The price of success, of course, is that you are now established.

For those who enjoyed the whirlwind, though, you have to dig harder. There are still a lot of really cool things that are being done. Some are just cool because they're cool, no matter the language. Others are cool because Java makes them possible. There are still things that Java does that other languages just can't do, or can't do smoothly, mostly having to do with mobile code, security, and nearly complete platform transparency.

I'm going to be looking for those. Plus, of course, looking for folks I meet only here, once a year. Frankly they're more interesting than a lot of the sessions. While it's nice that someone is presenting the current draft of version 1.3 of the JSR 9,324 spec on adapting to .... [snore]. Hey, it's probably important to someone, and if it's right up my alley I'm there, but generally I'll find out about this stuff when I need to, and faster by using online docs.

But the arguments in the hall about Jini vs. JXTA are not online docs. The folks at tables by themselves, who you ask to sit with and then get to know -- they're not online docs, either. The people who are still nutty enough to be running around causing a fuss without being paid to are online nuts, but they're not online docs, at least not ones you're going to run into. (Paying people to cause a fuss is pretty pathetic, and has always looked pathetic, yet marketing folks keep trying it, which is even more pathetic.) The unknown ideas that show up that get you thinking a new way? Who is going to point you at those online docs?

Which is why the BOFs are often more interesting, more vital in both senses, than the talks. Look around. Find a couple you not only don't recognize, but that look like they might open to something new. If you haven't been to two or three BOFs like that, you've wasted your trip.

After ten years of JavaOne it can't be the exciting innovation it once was, but it still has exciting innovations. So post up the sideways things, the interesting things you're going to look at. Let's help each other find the good stuff, the stuff you might not put into your trip report, but that you regale others with over coffee or beer. It can't be all spark anymore, but let's keep connected to the spark anyway.

Unicode marches on

What I always look for, though, is the new version of the Unicode book. In about 1,000 pages of technical text, one can find out amazing things about various languages and writing systems. Our book already has an exposition on title case (which is a third case beyond lower and upper case, used in Croatian). Case again rears its head for Georgian which has an upper case, but the upper case is considered archaic, so while toLowerCase will translate any upper case Georgian letter to its lower case equivalent, toUpperCase will not do the opposite.

And so it goes. One of my favorites is \u09F8 (which looks sort of like a backward N). This is a Bengali currency symbol that means “one less than the denominator” in a fraction. I don't know what this is really for, but I've always assumed it was the way that Bengalis did the equivalent making things look cheaper by pricing things for $19.99 instead of $20.00. So instead of writing “19 ³¹/₃₂” or “19 ¹⁵/₁₆”, they just made a mark that meant “Doesn't look as expensive as it really is!” Saved a lot of time and trouble, no doubt. Maybe it means something else, and I may be just about to find out from some Kind Reader, but I've thought sometimes that we ought to extend Java that way: Allow \u09F8 in expressions such as “\u09F8 / i” to mean “figure out what i is, subtract one, and then divide by i”. How useful!

Well, today I finally got my copy of the Unicode 4 book, and I've opened it right up to the choicest bit: \u2600 - \u26FF. That's where they put the “Miscellaneous Symbols”, and they are quite a miscellaneous lot. This is where you can find the hammer and sickle sign for communism alongside the peace sign. Want a snowman in your text? Try \u2603. Writing a horoscope? Here are your astrology symbols, right next to the religious and political symbols, such as the one for Iran (\u262C).

I've always figured that some of this got here as pranks. Maybe in each version the leader of the group or the person who wins the karaoke contest gets to add one personal symbol. I don't know, but it might explain why, tucked in between the card suits and a set of basic Western musical notations, is a symbol for “hot springs” (\u2668).

Well, this version's karaoke star was a recycling nut, I guess. There are 12 symbols for recycling added. And maybe this year's drunken evening was at the casino because now we have images for all sides of a six-sided die. (Not D&D players, clearly, as we have no images of 20- or 12-sided die sides. Maybe next time.)

Of course, Unicode 4.0 is not just about adding a second kind of umbrella symbol (\u2614, which is just like the existing one except that it has little raindrops above it; for versimilitude, I guess) or a steaming coffee cup (\u2615, so you can have coffee in your hot springs). That's just where groupies like me go to look at the seamy underbelly of character encodings.

No, it was mostly about adding new entire character sets, such as Mongolian, Osmanya (Somali), and Canadian Aboriginal. Many added sets were historic. Unicode is not only for modern languages, but also provides standard ways to encode ancient languages. So Linear B (an ancient Greek script) is available, as are Runic and Ogham (old Irish). They also added Deseret and Shavian, scripts desinged for writing English phonetically (Shavian was designed by playwright G.B. Shaw. Mark Twain also invented such a system, but his dropped redundant letters (“c” can be written with “s” or “k”) and then reused them. This had the advantage of not requiring an entirely new typographic system, or a new Unicode block set, so he remains unrecognized by the Unicode committee.)

The really neat thing about this is that these are all characters. I mean, real actual characters to Java. You can write your identifiers in ancient Irish or Scandanvian Runes. Although it raises some interesting questions, such as: What would Homer name a loop index variable? Or, Should you use Shavian instead of ASCII for English variables to help the reader pronounce the names correctly? Or if you name identifiers using Ugaritic, which is a cuneiform system, do you need to be able to print out your code on clay tablets?

Unfortunately Java does not (yet) allow you to write numbers in non-ASCII scripts, but if we are fortunate, we could someday be able to write our constants using ancient Aegean numbers.

Time to start lobbying!

This work is licensed under a Creative Commons License.