[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Elliotte Rusty Harold on Web Services


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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.