[
Lists Home |
Date Index |
Thread Index
]
On Sat, 08 Feb 2003 18:56:19 -0700, Uche Ogbuji
<uche.ogbuji@fourthought.com> 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 :-)
|
