Jeffrey Yasskin’s blog

(but nobody else is any better.) Alex Stepanov: Notes on Programming course taught at Adobe, 2005-2006 [PDF] (This is the guy who wrote the STL.)

Despite what Java partisans will tell you, Java does not fully support Unicode. Unicode, since at least version 3.1 in 2001, defines 21-bit characters, and the surrogate pairs to encode them in UTF-16 have been reserved since 2.0 in 1996. Yet a Java char value is only 16 bits long, and a Java String consists of a sequence of characters. See anything wrong with this? The documentation for Java 1.4.2’s Strings doesn’t even mention this problem. Now, it’s always been handled by using UTF-16 to encode the strings, which preserves the data, but sometimes uses two chars to represent a single character. This means that the length() method returns a pretty meaningless result.

Java 1.5 finally admits that it has a problem and defines some new codePoint* methods to actually handle Unicode. This is a step in the right direction, but it only helps if developers actually use the new functions. Unfortunately, Sun has been lying that Java natively supports Unicode for so long that very few programmers are likely to realize that they need to change their coding habits. Sun doesn’t help by doing an incomplete job. They haven’t deprecated the old char-based methods and haven’t updated the CharSequence interface. And, of course, Sun employees need to stop claiming that Java has been based on Unicode since version 1.0.

I’m taking a class on DSLs this semester, and the first assignment was to write some trivial programs in Scheme. Haskell is so much prettier. I mean, just compare (lambda (x) (* x x)) to \x->x*x (the square function).

(more…)