The Cafes » Blogroll

There’s an awful lot of sound and fury right now about adding syntax support for properties to Java 7. The more I think about this the more I think the whole idea is wrong for several reasons:
(more…)

Old Fortran weenies like me still remember with fondness (or loathing) RatFor. For those who don’t remember Fortran, you have to understand that it was the first compiled programming language. Consequently it made a lot of mistakes and had major design flaws. For instance, you couldn’t put anything except a line number or a comment marker in the first six characters of each line. That was a relic of its design for punched cards. (Remember those? Probably not if you’re under 40.) These design flaws weren’t trivial or academic problems. Spaceships could crash when you replaced a comma with a period, though the program would still compile.

RatFor was a 1970s era effort to clean up the language. It was an alternate syntax designed around the then hot-idea of structured programming. (OOP hadn’t escaped academia yet.) For instance, it added while loops and got rid of GOTO. It cleaned up the syntax by letting you write >= instead of .GE.. (Some of the early computers that Fortran ran on didn’t have lower case letters, much less angle brackets in their native character sets.) However, RatFor was compiled (more accurately preprocessed) to standard Fortran code, after which it used the same optimizers and libraries that standard Fortran did. That meant it was fully interoperable and could play in a world where not everyone was rational.

Fortran’s not the only language where this happens. For instance, JRuby is a way of writing Java code the Java VM in Ruby. That’s great if you like Ruby, but what if you actually like Java and just want to make it a little more rational? Well, as it so happens I just got an invitation to a Sun event on Monday where I expect Sun to finally pull the trigger and open source Java. Great. Let’s fork!
(more…)

There are many reasons to write your tests first. An oft unmentioned benefit is that it makes the programmer stop and think about what they’re doing. More often than you’d expect, the obvious fix is not the right answer; and writing the test first can reveal that.

For example, recently Wolfgang Hoschek pointed out that in XOM the Attribute class’s setType() method was failing to check for null. Once he pointed it out, it was an obvious problem so I opened up Eclipse and got ready to fix it:
(more…)

Eclipse 3.2 is driving me nuts. For reasons I just can’t understand or debug, it keeps throwing NoClassDefFoundError when I try to run most code in my project:

Exception in thread "main" java.lang.NoClassDefFoundError: nu/xom/Element

However, it can compile the classes it complains about not finding just fine. There appears to be a disconnect between the path the compiler sees and what the interpreter sees.
(more…)

While it may be a slightly too extreme position to say that tests are the only spec, I think it is absolutely reasonable to consider tests to be a major part of the spec. Indeed a specification without normative test cases is far less likely to be implemented correctly and interoperably than one with a solid normative test suite. The more exhaustive the test suite is, the easier it is to write a conforming correct implementation.

Cedric Beust presents the question, “how do you specify an exponentiation function with a test?” as a counterexample to tests as specs. Actually I don’t think it’s all that hard. Here’s one example:
(more…)