For my money, you either design for inheritance (and this is not an easy task, folks--it requires a tremendous eye for possibility and detail)--or it needs to be prevented.

Again, this is because for all the mechanisms in Java-like languages, they still do not support the reality of software development. Developers get into trouble, and rather than make the developer's life easier, the language designer introduces another kind of straightjacket.

The problem is the straightjacket, not the lack of ten kinds of straighjackets.

But that doesn't mean that it doesn't need some improvements to meet our future challenges. ?Coordinating XML messages between applications? isn't quite the same thing as ?coordinating work between fine grained services?.

The whole 'partial' implementation of classes will come as a bit of a shock for most old school OO developers, who would probably cringe at the thought of implementing the class in different locations, using different languages for each implementation -- it seems quite messy and unstructured. But if we step back for a moment and think about the possibilities of using this style of code, we can see that its more than just having classes written in different languages, and in different locations -- it's about splitting the 2 layers, control and presentation.

Thursday, April 15, 2004

Ahh, components. Anybody heard this story before? I remember hearing it with objects, then components, now services.... Look, we've had ways to partition our code up before, and we've failed to take advantage of it. Note that I say that very deliberately: we failed. Not "the industry hype wore off", or "the technology couldn't deliver", but "we failed to use the technology as it was meant to be used". We've had our chances to build apps and systems out of constituent parts. The problem is, we've never done it. Or at least, not on any recognizable scale. What makes you think this time around will be any different, Harry?

Monday, April 12, 2004

WinFS appears to be the main casualty, having already been curtailed. A year ago Microsoft confirmed that Longhorn wouldn't, as expected, introduce an entirely new database storage architecture in which file systems NTFS would be a plug-in. Rather, Microsoft would add database like properties to NTFS. Business Week reports that the new features of WinFS will only work on local storage rather than across networks. That's been pushed into Blackcomb, which is way out towards the end of the decade.

To reiterate I think the problems being addressed by WinFS are far better addressed not as a file system but by rethinking "the database". But then that would even more directly eat into the SQL Server cash cow. Either way, there are some tangly knots along the way that had simply been bypassed in the several WinFS presentations I've seen.

This is a good call, but too bad Microsoft has put countless hours into the WinFS over a decade now, if you count the origins back in Cairo-pre-Win95. If I read the above as WinFS will always be a "local file system" capability, then this is a total loss. Come back when this thing understands multiple users and runs on the network with location independence.

i.e. Come back when it is *really* a database, but not complex and not naive and self-managing... this is not easy.

Reports from Redmond suggest that the Avalon UI archtecture and the "managed code" API are also likely to be trimmed in order to get this most reluctant of steers out of the gate.

About Me

I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer.
Contact me at my gee mail account, username patrickdlogan.