Too Many Programmers

There are just too many programmers. It's getting hard to find anything to do.

This morning, I thought it'd be a good contribution to the world to build a couple of design by contract systems. I know, it's nothing truly revolutionary, but I haven't done any serious Eiffel programming in years and I miss being able to just state what a function should expect to be true, and what will be true after the function completes. My idea was to do one in python using decorators, and one in java using an aspect system.

I figured the python would be trivial, so just sat down and did it. I think I spent about fifteen minutes on it and it was everything I imagined it would be. Of course, in doing a few google searches, I found that there's a PEP with an implementation already in existence. This is not decorator based, but it has the nice advantage of having the contract stated clearly in the documentation. This is a secondary goal in the contract definition, but still quite important.

For the java one, Contract4J is pretty much exactly what I was intending to do. Aspects and annotations. The only real difference between what was written here and what I intended to do was that these expressions are supplied as strings for an evaluation engine. I do believe this makes it a bit easier to express and clearer, but I'm concerned the performance wouldn't be as good. My intention was to supply a sort of PreconditionCheck and PostConditionCheck interface and build these things out at compile time with a single instantiation at runtime with the evaluation-time overhead being basically a method lookup on an interface and an invokevirtual. I doubt it would be better-enough to make a difference, though.

So as usual, I can't think up anything that's not already implemented and available, and google is there to remind me of this. Of course, I can't really figure out if that's a good thing.