Not a Java rant

Today I used J2ME ("Micro Edition", for handheld computers, etc) for the first time.

I have a whole rant in me about how stupid it is. But writing it won't help, because more than enough people have already ranted about Java, and it didn't help them either.

So I'll just say this: the class library that comes with J2ME is significantly less useful than the ANSI C standard library. And that's saying something, because my Crackberry wastes 64 megs of flash doing it.

Not a C# rant

I have a similarly short-winded statement for C#:

Yes, it looks almost exactly like Java. But the difference is huge. If anyone ever wants to do a study about how "the devil is in the details," this should be your sample data.

Balance of Implicity

I've decided that your ability to quickly communicate(*) depends entirely on how much of the communication can be made safely implicit. The compromise tends to be between making things implicit (which I'm pretty good at) and making things safe (which "typical" engineers like to do).

It's easy to see why saying things implicitly instead of explicitly makes it go faster: implicit things don't actually have to be said, so they're zero work compared to non-zero work. And it's also easy to see why that makes things less safe: if you don't say it explicitly, how do you know the other person (or the computer, for that matter) has assumed what you hoped they would assume?

Once you're thinking in terms of safe vs. implicit, it becomes easier to talk about various aspects of design. For example, stable, long-lived public APIs (eg. Win32) tend to be highly explicit, because they don't assume anything about what exactly you'll want to do. That way, they seldom have to change. On the other hand, internal APIs can assume much more about how they'll be used, because if the assumptions are wrong, you can just fix them on a whim; and you should do it that way, if not too many people depend on your APIs, because it'll save you vast amounts of time in the long run.

On a completely different note, legalese has the same problem for a different reason. Lawyers are paid to deliberately misunderstand anything that's left implicit in a contract, which is how they can help you weasel out of one. To be implicit requires understanding; if it's not in people's best interests to understand, then you'll have to just make everything explicit. And that's why a simple one-page agreement can bloat to 200+ pages if you pay enough lawyers to look at it.

I think the best answer, if you can pull it off, is to be safely implicit: don't state the obvious, because it's obvious. But you have to be really good to know what's obvious, and if you screw it up, you would have been better off just saying it outright.

(The really expensive lawyers know what they can leave out and still have it be legally indisputable; they write shorter, more readable contracts that are just as enforceable. But will that make you feel more safe, or less safe?)

Specialized jargon is a very interesting example of "safe implicity." When you use a particular unusual term ("Feature Pusher" like we used to say at NITI) instead of the more usual one ("Project Manager" like we now say at NITI), it makes people stop and examine their assumptions. If they don't know what a Feature Pusher is, they have to go look it up somewhere, and the answer suddenly becomes explicit. If they did already know what it was, they don't need to look it up, and you've included a huge amount of information implicitly.

But be careful! You usually have to invent whole new terms if you want that to work, because when people see a term they've seen before, it has a whole lot of baggage attached to it. A Feature Pusher at NITI wasn't the same as a Project Manager; now, after the name change, suddenly it is, which is why it works so much more poorly.

When lawyers write contracts, they solve this conundrum by using Capitalized Words like "Person." (Quite often, a Person in a contract isn't actually a real person at all, but the capital letters are a signal to other lawyers that they need to look back in the definitions section to find out.)

* Communication also includes all of programming, since programming is just communicating to a computer and/or any human who reads your code later.