I’ve been working with Tim Ewald this week here in not-so-sunny Minnesota. As is usual when I hang out with Tim, my brain hurts from trying to keep up.
We had an interesting discussion over lunch yesterday. We were discussing – among other things – how the CLR has made things so much easier than they used to be that programmers have fallen into a death spiral of trying to abstract everything away. The fact that you can write the same application with about 4x less code leads us to try to cut things even further: a whole app in zero lines of code being the ultimate experience. Obviously I’m exaggerating, but I think the phenomenon of seeking to do things with fewer and fewer lines of code is a real one. And not a new one – if you’ve ever seen a C++ program that got a little bit too clever with preprocessor macros, you know what I mean.
The latest incarnation of “less is more” is the declarative programming model popularized (in the Microsoft world) by MTS and then COM+. The idea there was that you’d simply write your code, flip a few switches, and suddenly all sorts of magical services would appear at your fingertips. Transactions! Synchronization! Security! Just check a box. Or, if you’re programming in the CLR, just add an attribute. Clemens Vasters has been making the rounds lately showing how he has embraced this model to allow you to do all sorts of things by simply adding attributes to your code. It sounds like a great idea.
The problem is, it doesn’t work. It never has.
For a while, I tried to take the other side against Tim. Probably mostly because I’d recently done a bunch of this “hide everything from the programmer” work for a client of mine. But Tim has traveled this road for too long – after all, he wrote the best COM+ book there is. He made mincemeat out of my arguments. Which is hardly surprising – I studied COM+ under Tim for years, and already agreed with him. I just needed to be reminded. Tim pointed out a few things I already knew:
· How COM+ is fundamentally broken around synchronization and STAs
· How switching off one service in COM+ often requires you to switch off several others (e.g. transactions and synchronization)
The basic problem here is that services are not generally orthogonal. What that means is that it’s impossible to simply slap a new behavior onto code without understanding all the other behaviors that are already there. Don’t believe me? Then ask yourself why the CLR’s context infrastructure has IsContextOK. This is the method that – when implementing a new service – lets you look around your environment and decide if you’re compatible with all the other services that are already present. This has two basic problems:
1. How do you know if you’re compatible with a given service that didn’t even exist when you were created?