Operator Overloading Considered Harmful

Tuesday, January 30th, 2007

The gates seem to be open for serious revisions to the Java language in Java 7. Thus it’s worth reviewing why some things are just flat out bad ideas for any language, because too many developers either never knew this or have forgotten it. First up: operator overloading:

What Properties in Java Should Have Looked Like

Friday, January 26th, 2007

There’s an awful lot of sound and fury right now about adding syntax support for properties to Java 7. However, all the proposals are vastly too complex for what little benefit they offer. They need new keywords, operators, rules, and best practices. Could we have done better? Yes. Can we still do better? Maybe. Let’s find out.

The proper design of properties was invented in Eiffel over a decade ago, (or possibly some other language, but Eiffel is where I first saw it) and it’s really simple and obvious. All you need are public fields.

Oh my god! Public fields! The ultimate evil of object oriented programming that will bring about chaos, catastrophe, and the heat death of the universe! He can’t be possibly be serious, can he? Well, yes I can, because public fields don’t have to be bad.

Why Java Doesn’t Need Properties (It already has them)

Thursday, January 25th, 2007

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:

Go Ahead. Break the Build!

Wednesday, January 10th, 2007

There’s a philosophy in extreme programing circles that one should never break the build. As soon as the build is broken, everything stops until it can be fixed again.1 Some teams even hand out “dunce caps” to a programmer who breaks the build.

If by “build” you simply mean the compile-link-package cycle, then I tend to agree. Breaking the build is pretty serious. One of the advantages of extreme programming is that the increments of work are so small that you don’t get very far before discovering you’ve broken the build, so it’s relatively easy to fix. Integration is almost automatic rather than a painful, months long process. Avoiding coupling is also important to keep build times manageable.

However some systems define the build a little more broadly. They consider the build to include successful execution of all the unit tests. For example, Maven gives up if any unit test fails.* It will not create any subsequent targets such as a JAR file, if it can’t run unit tests. Ant doesn’t require this, but does allow this. All that’s necessary is declaring that the jar or zip target depends on the test target.

It’s not just open source either. Over at closed source vendor Atlassian, Charles Miller tells us, “all our tools are predicated on tests that start green and stay green. ” In fact, a failing test is so damaging to them, that he actually advocates writing tests that pass if the bug isn’t fixed and fails if it is. That’s a recipe for disaster if I ever heard one. Five years down the line some new programmer is going to finally fix the line of code that causes the bug, and then carefully reintroduce the bug to get back to the green bar.

This is where I part company from the most extreme of the extremists. If building includes passing all unit tests, then it is often acceptable and even desirable to break the build.

Faint Praise: Mac OS X is Better than Vista

Sunday, January 7th, 2007

John C. Welch has a nice article in Information Week in which he compares Mac OS X to Vista, and Vista comes out much the loser. This is no great surprise, especially since he focuses on UI issues. This is like comparing a Toyota Camry to a car built by UNM engineering students for the Formula Society of Automotive Engineers competition. Sure, it’s cool that the undergrads can build a car in a couple of semesters, but you wouldn’t put the student car in your driveway to commute to work.

However, what struck me was how many of Welch’s examples of how things were easier on Mac OS X, were easier only by comparison to the even poorer Vista. Many of his examples are actions that non-geeks are not able to accomplish on Mac OS X. They are harder than they need to be be, and harder than they should be. For example,