This is only incidentally *apropos* of BitC, but it seems relevant to our discussions about inheritance.
I've been reading *Coders at Work*, and Doug Crockford makes an observation that I think is dead on. And incidentally matches my own experience in C++: *Crockford: ... *Part of what makes programming difficult is most of the time we're doing stuff we've never done before... And doing things that you haven't done before is hard... Particularly if you're using a classical methodology you're having to do classification on systems that you don't fully understand. And the likelihood that you're going to get the classification wrong is high. *Seibel:* By "classical" you mean using classes. *Crockford:* Right... in a classical system you can't [focus on instances] -- you're always working from the abstract back to the instance. And then making hierarchy out of that is really difficult to get right. So ultimately when you undestand the problem better you have to go back and refactor it. but often that can have a huge impact on the code, particularly if the codes' gotten big since you figured it out. So you don't. So you keep bundling these new things on top iof it to try to patch the problems that were in the original hierarchy and it gets cruftier and worse. Sound familiar to any of you? In practice, I don't know how much this matters. Class hierarchies are part of an awful lot of languages, and if we go down the path of a common bytecode runtime with a high-level type system we may be stuck with them. But I do find it interesting to see somebody like Doug state very clearly one of the issues that I have been grappling with in OO. Of course, the question then becomes: if that's really a problem, what's the solution? The problem is that your language/system will be out in the field for five years before you know, and by then it's too late to fix it. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
