Companies Controlling Language

The problem with one company controlling a language is that, if the company is selfish, it can change it in a way that (a) benefits that company, but (b) harms people outside the company.

On the other hand, the good thing about one company controlling a language is that, if the company is unselfish, it can guide its growth in a way that it both (c) benefits that company, and (d) benefits people outside the company.

In the case of SunMicrosystems and MicroSoft, I leave it to the reader to figure out which is doing which. -- EdPoor

In the discussion about Microsoft's CsharpLanguage, someone wrote the following:

: Actually standards bodies like ECMA aren't the voice of democracy that some would have us believe. C# was submitted to ECMA because Microsoft and IBM can pretty much control the standardization process by working together. Java was not submitted to ECMA for exactly the same reason. Sun isn't afraid of letting Java be controlled by the community -- take a look at their community process -- no, Sun is afraid of having Java controlled by the likes of Microsoft and IBM. If you read the C sharp documentation you'll see that it is intimately tied to the COM architecture, indeed that is one of its main strengths. There is nothing cross-platform or open about this language, standardization not withstanding.

Some of this sounds paranoid. I don't understand how even if a company did "control" the ECMA's standard's process how it could benefit. Let's say that Microsoft and IBM get together over C# and decide to add language features that would somehow shut out Sun or other competitors.

How exactly do they do that? And perhaps more importantly, what specific kinds of things can you do at the language specification level that would favor a language on one platform, but not another?

: In the Sun case, the answer is that the standards body might/could have divorced the language from the platform, thereby allowing evil ones such as Microsoft to actually use Java on its platform. The result would be a Language that no longer favors one platform over another, exactly what Sun wishes to avoid.

I guess my thinking goes like this: C# is supposed to be really hot for COM developers. But let's say I'm a CORBA developer. If C# is intimately tied to COM, that means I probably wouldn't use it in the first place-- which means that any "control" Microsoft had on the standardization process doesn't matter to me because I'm not using their product. On the other hand, if C# isn't intimately tied to COM, and other implementations gave me the ability to work with CORBA instead, then any "control" Microsoft had failed.

: Point of Order: C# is not COM. COM is dead. COM is the new legacy. Goodbye COM. C# runs only on the CLR, which is not COM. CLR is all new. Multiple languages run on it, C# is one of them. Logically, the plumbing that COM provided is now in the runtime.

Either way, the efforts to "control" the standardization process failed. --JohnPassaniti

That's circular reasoning: it doesn't matter if C# is good for CORBA because C# isn't good for CORBA. (Actually, this is not circular reasoning. It is a perfectly valid argument, logically speaking. --HaskoHeinecke)

I don't see what you're saying here. I wasn't writing if C# was or wasn't good for CORBA. I wrote that in either case, if Microsoft attempted to somehow "control" the standardization process, they would fail in either of the two scenarios I described. Are there other scenarios?

If C# were to be standardized in such a way as to make it just as useful for writing programs on Linux or for writing programs that compile to Java byte codes as it is for writing COM based programs then people would use it for those things. Apparently the author that you quote believes that Microsoft wouldn't like that and has confidence that it can be prevented.

Yes, and I want to know how. What specific kinds of things could Microsoft do to prevent such use?

I know that Sun backed out of ECMA standardization in part because it would have meant giving the Java copyright to ECMA. I'm surprised that Microsoft is willing to hand over their copyright to C#. -- PhilGoodwin

That's a peripheral issue to my question, but what would Sun have lost by giving up the copyright?

"what specific kinds of things can you do at the language specification level that would favor a language on one platform, but not another?"

You could specify a language method "System.CreateObject?(typeName)" for example. On a Microsoft platform, this translates to a one-line CoCreateInstance(...) operating system call. All of the object resolution and instantiation logic is built into the OS and is available to the language implementor "for free".

On a non-Microsoft platform, you don't have a COM subsystem. You have to roll your own, embed an ORB, whatever it takes to get the same functionality. It's possible to do, but it's a lot more work.

"Either way, the efforts to "control" the standardization process failed."

What's important isn't the standardization process. What's important is making development for the dominant platform so easy that cross-platform development becomes unappealing.

Sample conversation:

Marketing: "How long will it take to develop the whiz-bang 3000?"

Development: "If we do it in C#, n months, but it'll only run on Windows. If we do it in C++, m months, but we'll be able to run it on Linux, Mac, ..."

Marketing: "What?! Those platforms only have xx% of the market. We're not going to squander (m-n) months of sales just to get that xx%! Do it in C#!!"

I purposefully didn't use numbers for market share or time to development, as flame wars over these aren't really relevant here.

(But you are assuming that m > n which remains to be proven. -- HaskoHeinecke)

An open, fair standardization process identifies and eliminates or reduces the language characteristics that favour one platform. As a result, either the language becomes easy to implement on all platforms, or it provides less of an advantage on the dominant platform. Either way, the opportunity for lock-in is reduced. Solution - don't standardize, or find a standardization body sympathetic to your goals.

(CanonicalQuote?: "We love standards, that's why we've got so many of them")

From the author of this section: please feel free to clean up, format, rewrite, or otherwise improve this chunk

I remain unconvinced that Sun is trying to dominate the universe (as evidenced by the fact that I still work here).

As far as I can tell Sun is concerned primarily with making sure that Java lives up to its write once run anywhere promise. That promise is really Sun's only reason to support Java -- Java exists to help Sun sell more servers. The only way Java can do that is if it keeps the write once run anywhere promise: people can write applications in Java for platforms that appeal to them today and migrate to other platforms (like ours) tomorrow. In this way Sun has found a way to implement a business strategy that benefits both them and the rest of the software industry, thus proving that this whole thing isn't really a zero sum game after all.

what specific kinds of things can you do at the language specification level that would favor a language on one platform, but not another?

The Java Virtual Machine has features relating to security and memory management that would preclude it from being a viable platform for C#. In general you can look for features that are supported on one platform and not another and embed those features into the language. Or you can allow features into the language that allow a vendor to make platform specific extensions to the language and still call it "standard". -- PhilGoodwin

The benefit to the developer community of giving a technology to a standards body is that it prevents the controlling company from suing over uses of that technology that it doesn't like. Or, even worse, technology that it likes so much that it decides to own it. While Sun continues to litigate, Java is not an acceptable answer for many people. -- SunirShah

Is Sun suing someone other than Microsoft?

Probably, but they also use their license to acquire technology. I'm thinking of BlackDown? today. [1] Frankly, I think if Java (or anything) is going to be pervasive, it shouldn't be controlled by one interested party (unless that's the government; but that's a whole other thang). -- ss

No, they only sued Microsoft for their "browser incompatabilities" and "not passing certification tests" and allowed Netscape to pass right through when their browser was much less compliant. Sun plays favorites just like any other major corporation. People should not hold on to this vision of them being the Gods of standards and open-ness as a lot of people do.

Sun sued Microsoft because Microsoft tried to break the "write once run anywhere" promise. Netscape didn't do that and that's why they didn't get sued.

Or to put it another way. Microsoft introduced a deliberately incompatible Java implementation, with numerous extensions like "delegate". Netscape didn't introduce a deliberately incompatible implementation; they just introduced a lousy implementation.

If Sun doesn't trust the standards organizations, and perhaps wisely so, I wish that they would hand pick members to form a new one.

What about the JavaCommunityProcess ; does that do anything to address this concern?

No. JCP is a process completely controlled by and dominated by a single entity: Sun. JCP is a lot of window dressing, but isn't open at all. Sun retains veto power, member appointment power, and majority positions in some voting matters. Open?

I've seen what Sun's power in Servers and UNIX have done and are doing to companies like DigitalEquipmentCorporation. They tried to kill Unix standardization that we tried to do with OSF. Their view is any standard is OK as long they create it. 78% of developers want Java turned over to an independent standards body.

I'm not psychic so I can't claim to know what Sun will truly do in the future. All I know is that right now Java delivers on a promise that I believe in. I would like to believe that Sun would turn it over to a standards body if that body were truly independant. There is enough evidence to support the proposition that no such body is available that I'm willing to believe it for now. I think that the JavaCommunityProcess is good -- good enough for now anyway. Probably the best thing that can happen is for companies like Microsoft and IBM to keep nipping at our heels and keeping us honest. I've never hated Microsoft, but I've hated their dominance. If some other company had that dominance I'd hate it just as much there too -- even if it were my company. The best thing that can happen for everyone is if no one can "win".

The thing I like about Java is that it directly attacks the ability of one company to "win". Sun can never have complete control over it because if they steer it in a proprietary direction they'll lose control over it -- or kill it. -- PhilGoodwin

"...what specific kinds of things can you do at the language specification level that would favor a language on one platform, but not another?"

Microsoft have been adding features to their C and C++ compilers at the language level for years. For example, qualifiers on function declarations (__declspec, __stdcall, etc.), anonymous structs, #import directive, __near and __far pointer qualifiers, etc. These extensions are often necessary to access Windows APIs or so convenient compared to the alternative that programmers naturally use them. Furthermore, Microsoft implements them when there are existing mechanisms in the language spec that do the same thing in a standard way, such as extern "XXXX" qualifiers in C++.

This has resulted in code that's hard to port to other systems. Either programmers have to think cross-platform in the first place, and wrap the extensions in macros and conditional compilation directives, or they have to wait for other compilers to catch up with Microsoft's extensions. Cygnus has only recently added support for some of the MS extensions to GCC.

The other result was that other compilers on the Windows platform didn't keep up with Microsoft's APIs. Borland C++, for example, always lagged behind MSVC because they had to convert the headers in the Windows SDK to be compatible with their C++ compiler. Nowadays how many programmers use anything but MSVC to develop in C++ on Windows? -- NatPryce

Microsoft have been adding features to their C and C++ compilers at the language level for years. This has resulted in code that's hard to port to other systems. The other result was that other compilers on the Windows platform didn't keep up with Microsoft's APIs.

Now that MicroSoft have given C# over to ECMA, they can't willy-nilly add whatever they please. It must go through the standards process. So everyone will have the same language and the same CommonLanguageRuntime technology.

In theory. But a vendor in a dominant market position can lock consumers in to a platform or tool chain by adding extensions to a language, even when that language is standardised. This is exactly what MicroSoft has always done.

There is still a danger of the same thing happening with C# if compatible implementations are not produced fast enough and Microsoft's implementation becomes dominant. Perhaps an OpenSource implementation based on GCC and other existing technologies could be completed fast enough and have the same authority as the ApacheGroup's Java Servlet server which is the reference implementation.

Microsoft's approach to standardising its own products has never been altogether straightforward. For example, when the Open Group standardised COM and DCOM Microsoft stated that they considered the Microsoft implementation of (D)COM to be the reference and any changes they made overrode the standard! Let's hope they've finally seen the light about the future of the internet marketplace.

Sun's record with Java is just as bad as Microsoft's past.

I don't see that. It seems to me that Sun has come as close as they possibly could to making Java an open standard (via the JavaCommunityProcess) without jeopardizing it's cross-platform nature. As far as the CommonLanguageRuntime and C# being standards compliant: there is not one single language that can run on the CommonLanguageRuntime in its standard form -- not one. Microsoft has even changed its own language (VisualBasic) in order to get it to run there. Now there are very good technical reasons for this and all of these changes may very well become standardized, but you can hardly say that Microsoft has allowed itself to be bounded in any meaningful way by past standards in its .NET initiative. -- PhilGoodwin

: This is caca. What does it matter if languages must change to support a new runtime? I think it's unlikely that Java, the language, was ever-constant, until God created the JVM on the 8th day. Obviously, the language, the compiler and the runtime (for Java) evolved concurrently. Likewise with the CLR, C# and the other languages, and their respective compilers. Look, if you move to a common type system (as CLR does), then you will imbue changes in languages that support that common type system.
: And no one is saying that .NET is evolutionary. It is much more dramatic than that, involving some very basic changes.

From earlier contribution: The result would be a Language that no longer favors one platform over another

It seems that would be desirable.

CategoryMicrosoft CategoryProgrammingLanguage