[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Elliotte Rusty Harold on Web Services
On Sat, 08 Feb 2003 18:56:19 -0700, Uche Ogbuji <uche.ogbuji@f...> wrote: >> The history of C -> C++ -> Java -> C# is an interesting thing to ponder >> in this context: to me, it's not self-evident that Java did the right >> thing in forking .... I would prefer NOT to do this all over again > > I knew your "ecumenism" analogy was dodgy, but even I did not expect you > to contradict yourself so swiftly. What is wrong with the competition > between Java, C, C++ and C# ? Competition is good, but stovepipes are not so good. Forks lead to stovepipes: Java, C/C++, and C# as actually practiced are essentially three separate environments -- if one chooses to develop a product, one has to either choose one over the others or invest *significant* resources in separate code bases, porting tools, or whatever. Thus innovative tools or implementations of new ideas tend to be available in only one of the above. There ain't no way (AFAIK) to work in Microsoft's best-of-breed IDE and use the great open source Java code out there. I for one consider that a problem. [MS may consider it a solution, I'm not going there :-) ] Hypothetically, had there been a way to agree on the fundamentals and have competition over the details, you could get the advantages of competition without the disadvantages of stovepipes. Even in 20:20 hindsight, however, I don't see how that could have worked in the C++/Java/C# worlds -- arguably the whole *point* was to create incompatible environments to negate the momentum of the others. But I *do* see that as a very viable and desireable scenario in the data language worlds. As much as we all disagree on here, there is an awful lot that we agree on, and "forking" because some subgroup doesn't like some technology or some vendor is counterproductive ... so long as that vendor can't call the shots or the technology does not become "core." So, my general approach to these questions in the XML world is to suggest refactoring things so that what is common is in the core, and then there can be competition in the periphery among alternative ways of adding value to the core. That's why I both resist the efforts of some parties to drive technologies such as W3C XSDL types into the core of XML ... and resist the efforts of other parties to fork XML into "document" and "data" camps. What we all have in common is something much like Common XML, or "the SOAP subset" or "the Skunk Works proposal." I advocate refactoring the core now to avoid forking later, and competing in the periphery to avoid premature lock-in. Extreme specwriting. Another dodgy analogy, I'm sure :-)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|