Thursday, November 14, 2002

trump cards up the big boy's sleeves: MS and IBM both have huge trump cards that they could play that would cause big ripples. here they are: MS: aggressively release the CLR, .NET framework, and .NET languages for *all* major operating systems. the UI parts probably wouldn't be ported, since their target would be server-side systems, but all the rest would be ported (including the SOAP stack, web server, transactions, etc.). they could charge for this software, just like they charge for windows, and make sure that the windows version is optimized to run better than the other platforms. this effectively neutralizes one of java's remaining differentiators, which is its portability. microsoft's mantra would become "develop on windows, deploy everywhere". IBM: release an open-source CLR, open-source compilers for both Java and C# that target the CLR with compilers for eclipse, and an open-source framework that is different from microsoft's. this neutralizes microsoft's ability to corner the marketplace for CLR-based infrastructure, and is consistent with IBM's direction of open-sourcing stuff to engage the community to combat microsoft. it also frees IBM to innovate in the language arena and accelerate the development of alternative frameworks that are better than those in the J2EE stack. my guess is that both trump cards will be played sometime during the next six months. what do you think? 1:00:56 AM

non-OO languages, part II: why don't i think objects (in the usual sense that java, C#, etc. implement this concept) are a long-term way to go? one of the design problems i used to see a lot at companies was when architects were trying to model a concept such as Employee or Customer. each project had their own idea of what such a thing should look like, and so it was almost impossible to create a first-class object that satisfied everyone's needs. attempts to create a common subclass were nasty, since even an agreement on what was common was hard to get, and even then this would change over time. in addition to the problem of defining a common object definition was the problem that different bits of this object were often scattered across an enterprise, making it hard to create a concrete implemention that wasn't laden with details of where to find the information. object-to-relational mapping systems attempted to bring some kind of sanity to the situation, but even they only work properly when *all* the information is stored relationally. what about when some bits are in a relational database, and some are in an older, possibly remote, system? some companies attempted to copy the old data into the relational store to help matters, but then there's additional software that's needed to keep the various data stores synchronized. this situation is amplified in the internet age when bits of information about a customer or employee are often stored at various locations across the internet. as long as you try to force concepts to be implemented as first-class concrete objects, these problems remain. so the key is to get rid of first-class objects in the first class. i'll chat more about this in the next part of this series. 12:50:45 AM

© Copyright 2002 graham glass.