Slashdot Mirror

There are a couple of problems here.

First, there are organizations like the ECMA that publish freely their specification. I can also think of several others, including Microsoft, that publish information without charging royalties for internet distribution. In the case of ISO, I think they see this as a revenue source.

Personally, I think that standards can and ought to be in the public domain. By trying to limit or restrict a standard, you are encouraging other competing "standards" to be developed. Image if you had to pay a royalty for using a gram, meter, or liter? I think pounds, feet, and gallons would become very popular if that occured, even in Europe.

On the other hand, it appears as though ISO is trying to charge royalties on their copyrighted works. This is fair in and of itself, because they wrote the original document and it is in fact copyrighted. That means that people who publish these ISO standards on alternate or mirrored web sites are violating copyright law. As a private organization that can copyright anything they produce, they have every right to prevent or control how that text can be copied. This is the very definition of copyright.

That doesn't stop me from thinking they should never have been copyrighted in the first place. Standards need to be available for everybody to access and learn about, and the companies that sponsor and develop those standards also gain by having the standards availble for their products. Indeed, it is financially in the interest for any for-profit company to get involved, and involved early in the development of a standard. If you are the first company to successfully implement a standard you can often turn that into a near monopoly of the market that has been standarized, or at least get a major portion of that market. Also, competing companies that want to stay compatable with your products (following the standard) must not only comply with the written standard, but must also test against your products, which also help to define the standard. Since you wrote the standard, you don't have that cost.

Any other justification to charge for standards publications is just legal BS beyond the mere cost to support the servers. ISO gets plenty of money from its membership dues, and that should cover the cost of its support staff. I don't object to some donations to cover the server, or even charge for the documents to be given to you, but ISO has nothing in terms of document volume compared to the Gutenberg Project And that is donated server space.

C# is one programming language I've stayed away from--and for no particular reason. I had picked up the C# specification [PDF] in 2000, but never really got down to the canonical "hello world" program. Today in 2003, as I look back, I guess I haven't missed much.

Let's go back to August 2000 and revisit Hejlsberg's famous O'Reilly interview by Josh Osborn.

Why are there no enums in Java, for example? I mean, what's the rationale for cutting those?

And Java has enums now, just like they come in C#.

one of our key design goals was to make the C# language component-oriented

I think this was really nice, and fitted in well with Microsoft's COM framework. I remember COM enthusiasts mentioning how every C# object would automatically be a COM object, thereby eliminating all that old school drudgery.

C# is the first language to incorporate XML comment tags that can be used by the compiler to generate readable documentation directly from source code.

Python and Java have docstrings (or javadoc) as part of the language.

Developers are building software components these days. They're not building monolithic applications or monolithic class libraries.

Developers are building all sorts of stuff, and not just "components". I think that statement is overrated.

Boxing allows the value of any value type to be converted to an object, while unboxing allows the value of an object to be converted to a simple value type.

Thanks, now Java has it too!

Unsafe code allows you to write inline C code with pointers, to do unsafe casts, and to pin down memory so it won't accidentally be garbage-collected. [...] The real difference is that it's still running within the managed space. The methods you write still have descriptive tables that tell you which objects are live, so you don't have to go across a marshalling boundary whenever you go into this code. Otherwise, when you go out to undescriptive, unmanaged code (like through the Java Native Interface, for example), you have to set a watermark or erect a barrier on the stack.

Honestly, I didn't understand the stuff about "unsafe code", the implementation of IL, and the implementation of generics. Just for comparison sake, Python also has a scheme for inlining C and C++ code.

Let's face it, some people like to program in COBOL, some people like to program in Basic, some like C++, and some will like C#, I hope. But we're not trying to tell you to forget everything you ever did.

I've raised this point to Java bigots on several occasions. It's just too difficult (and sometimes impossible) to interface Java with other languages. (In this context,

Also, Java isn't exactly a competitor's product; it's also an attempt at an industry-wide open standard that Microsoft wants to subvert, dominate, and exploit. Hey, they already tried

But it is a competitors product. You want to talk about standards? Read about C# and ECMA. Have Sun turned over control of the Java specification to a neutral standards body? Nope, Sun control it fully.

Make no mistake: Sun don't want to compete with Microsoft, they want to become Microsoft.

The "contract" for language interoperability is called the Common Language Specification (CLS) and furthermore, languages are divided in CLS producers, consumers and consumer/producers.

You can think of the "CLS" as a richer contract than say the CORBA IDL or the COM IDL: they define APIs. Now on top there is a virtual machine that allows you to run either native code or "CIL" code that executes on the common runtime.

There are plenty of CIL compilers (C, C++, C#, JavaScript, Fortran, Cobol, Eiffel, Ada, VB, Haskell) that can produce/consume CLS code.

It is great if your language can produce and consume CLS classes, but its also good it it can consume them, because then a large body of code is available to you.

Miguel.

figure out if any DHTML techniques have become standards.

DHTML means manipulation of the HTML DOM through ECMAScript. The HTML DOM is a W3C Recommendation, and ECMAScript is a European international standard.

The only parts submitted to ECMA are C# and the CLI which excludes Windows Forms, Web Forms, and many base libraries which are proprietary and owned by Microsoft. As Nelson would say, HA! HA!

The only parts submitted to ECMA are C# and the CLI which excludes Windows Forms, Web Forms, and many base libraries which are proprietary and owned by Microsoft. As Nelson would say, HA! HA!

Thats great, what about the bytecode?

Yes, the bytecode is standardized.

Actually there were two different submissions into ECMA for .NET. One concerned C# as a language, syntax only with no consideration to a runtime (could make a native implementation if you wanted, would be very similar to D.) The second dealt with the CLI, or Common Language Infrastructure. Included is the bytecode (CIL, or Common Intermediate Language) and the base classes of the CLI. Here are the ECMA project pages that contain the specifications available for download:

Enjoy. The CIL standard is located within partition III of ECMA-335.

Thats great, what about the bytecode?

Yes, the bytecode is standardized.

Actually there were two different submissions into ECMA for .NET. One concerned C# as a language, syntax only with no consideration to a runtime (could make a native implementation if you wanted, would be very similar to D.) The second dealt with the CLI, or Common Language Infrastructure. Included is the bytecode (CIL, or Common Intermediate Language) and the base classes of the CLI. Here are the ECMA project pages that contain the specifications available for download:

Enjoy. The CIL standard is located within partition III of ECMA-335.

Just as soon as these burners hit the markets, I expect Sony to introduce SVDVD (Super Video Digital Video Disk), with a higher bandwidth and a richer, emotionally more intense "look" that is often compared to film.

Unfortunately, the DVD Consortium, in its "wisdom", has decided to push a competing high definition format that uses the current DVD physical layer (book 1 of the DVD spec, ECMA-267), but with higher compression ratios. This seems rather short-sighted.

Any idea what version of JavaScript IE6 emulates, and Mozilla actually uses?

IE6 doesn't emulate JavaScript. It uses JScript, which is Microsoft's implimentation of the ECMA-262 Edition 3 language standard (ECMAScript). Similarly, JavaScript is Netscape's implementation of the same standard. Neither is "emulating" anything.

You can find the ECMAScript standard here: ECMA-262v3. You can discover what your favorite vendor has actually implemented by visiting either mozilla and microsoft documentation for each vendor's implementation.

Anyone can implement their own versions under any license.

Anyone can implement their own versions under any license.

Uh, WRONG. Both the language and the platform are standards.

The C# standard is ECMA-334 aand the platform is ECMA-335.

You should check your facts before spouting off in bold.

Uh, WRONG. Both the language and the platform are standards.

The C# standard is ECMA-334 aand the platform is ECMA-335.

You should check your facts before spouting off in bold.

About the CLI - common language Infrastructure and part 2 of CLI information

To really understand what is going on here, consider the CTS - Common Type System and the CIL - Common Intermediate Language as a midway translation point for any programming language.

With this other programing languages or other programming mehodology interfaces can more easily be created.

It's like taking all popular programming languages and putting them into a pot and boiling them down to common and non-conflicting data types and programming concepts. And from here, using the summed vocabulary set of data types and concepts as a translation base to use in converting a program written in your convient programming language choice into CIL or Common Intermediate Language bytecode. From which you can run on any systemj that has a VES or Virtual Execution System type of system installed.

This of course allows both intrepreted and compiled types of languages to potentially be used.

About the CLI - common language Infrastructure and part 2 of CLI information

To really understand what is going on here, consider the CTS - Common Type System and the CIL - Common Intermediate Language as a midway translation point for any programming language.

With this other programing languages or other programming mehodology interfaces can more easily be created.

It's like taking all popular programming languages and putting them into a pot and boiling them down to common and non-conflicting data types and programming concepts. And from here, using the summed vocabulary set of data types and concepts as a translation base to use in converting a program written in your convient programming language choice into CIL or Common Intermediate Language bytecode. From which you can run on any systemj that has a VES or Virtual Execution System type of system installed.

This of course allows both intrepreted and compiled types of languages to potentially be used.

the c# specification has been standardized so i wouldn't worry too much. i suppose ms could stray from the spec, but i really don't see it happening.

"First, a little background. C# was, is, and always will be, a Micro$oft invention."

C# is supposed to be an open, standardized language (standardized via the ECMA) - see here - in contrast, directx and the rest were all closed, proprietary systems. M$ would lose a lot more than they would gain by mucking with the standard.

They, however, may unofficially extend it... that's a lot more likely, if you think they are planning evil.

But then I reconsidered. First, a little background. C# was, is, and always will be, a Micro$oft invention. Like it did with SMB and OLE, not to mention DirectX and ZIP, M$ will have no reservations about mucking with C# just to break Mono compatibility.

C# is an ECMA standard, like C++ which is an ISO standard unlike Java which is Sun Microsystem's property. Thus Sun has complete control over the future of Java while Microsoft does not have the same for C#. So claiming supporting C# is supporting Microsoft is way off base. Question: Were DirectX, OLE and SMB also international standards or are they technologies wholly owned by M$?

the other parts of .net such as passport, application services and MS web services are the troubling part. mono has nothing to do with these.

Yes, I have read the standards. Or browsed them at least, so I do know what I am talking about. They are here and here if you also want to read them.

I think you are confusing 'open source software' with 'free software'. Remember, open source just means the source is open for you to see and use, examples being the Microsoft Shared Source license and the BSD license. If it classified as Free Software it has additional restrictions to stop people from modifying and then closing the source.

The fact that it is Open Source is a huge step forward for Microsoft in working with the open source community. You slate it as being FreeBSD only - but really, they just picked the most popular of the *BSDs. It makes sense to go for BSD, as there are too many other Linux platforms to work on. And it makes sense to go for the most popular (even if 'BSD is dying', hehe :-) )

The important thing is that there is a *Unix* port of it, available as Open Source. This is a very good move all round.

And it's not a case of 'taking down' Windows. Look at it this way - they open source it, get lots of free development on it from interested third parties, and then get to sell more of their .net server software based on this free development.

Pretty neat, and like I said before, beneficial all round. Surely you are not so blinkered that you cannot see that Microsoft may want to benefit it's customers? You don't win in business by screwing your customers over!

Yes, I have read the standards. Or browsed them at least, so I do know what I am talking about. They are here and here if you also want to read them.

I think you are confusing 'open source software' with 'free software'. Remember, open source just means the source is open for you to see and use, examples being the Microsoft Shared Source license and the BSD license. If it classified as Free Software it has additional restrictions to stop people from modifying and then closing the source.

The fact that it is Open Source is a huge step forward for Microsoft in working with the open source community. You slate it as being FreeBSD only - but really, they just picked the most popular of the *BSDs. It makes sense to go for BSD, as there are too many other Linux platforms to work on. And it makes sense to go for the most popular (even if 'BSD is dying', hehe :-) )

The important thing is that there is a *Unix* port of it, available as Open Source. This is a very good move all round.

And it's not a case of 'taking down' Windows. Look at it this way - they open source it, get lots of free development on it from interested third parties, and then get to sell more of their .net server software based on this free development.

Pretty neat, and like I said before, beneficial all round. Surely you are not so blinkered that you cannot see that Microsoft may want to benefit it's customers? You don't win in business by screwing your customers over!

Fighting .NET is stupid. .NET is a great technology, it's an ECMA standard.

Hardly. The only parts that have been submitted to the ECMA are C# and the CLI. Everything else, all the parts that provide the .NET functionality are another matter entirely.

Fighting .NET is stupid. .NET is a great technology, it's an ECMA standard.

Hardly. The only parts that have been submitted to the ECMA are C# and the CLI. Everything else, all the parts that provide the .NET functionality are another matter entirely.

Furthermore, the ECMA-334 Standard does not specify:

• The mechanism by which C# programs are transformed for use by a data-processing system;
• The mechanism by which C# applications are invoked for use by a data-processing system;
• The mechanism by which input data are transformed for use by a C# application;
• The mechanism by which output data are transformed after being produced by a C# application;
• The size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor;
• All minimal requirements of a data-processing system that is capable of supporting a conforming implementation.

Most of these issues are critical to implementing ECMA-334. Thus the standard is not entirely open. Why did Microsoft leave these particular issues out of the standard? Microsoft may well have patented the only practicle means of implementing these aspects of the standard. Even if they did not, Microsoft certainly holds patents on other aspects of the .NET architechture.

Finally, if Microsoft does hold patents on the ECMA-334&5 standards, the only penalty for not disclosing them, is that they will have to license their patents on reasonable and non-discriminatory (RAND) terms, which effectively closes out open source.

Furthermore, the ECMA-334 Standard does not specify:

• The mechanism by which C# programs are transformed for use by a data-processing system;
• The mechanism by which C# applications are invoked for use by a data-processing system;
• The mechanism by which input data are transformed for use by a C# application;
• The mechanism by which output data are transformed after being produced by a C# application;
• The size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor;
• All minimal requirements of a data-processing system that is capable of supporting a conforming implementation.

Most of these issues are critical to implementing ECMA-334. Thus the standard is not entirely open. Why did Microsoft leave these particular issues out of the standard? Microsoft may well have patented the only practicle means of implementing these aspects of the standard. Even if they did not, Microsoft certainly holds patents on other aspects of the .NET architechture.

Finally, if Microsoft does hold patents on the ECMA-334&5 standards, the only penalty for not disclosing them, is that they will have to license their patents on reasonable and non-discriminatory (RAND) terms, which effectively closes out open source.

Alan's ideas are usually good and I've been involved with the formation of the AFFS in the UK as well as having donated to the EFF in the US several times, but he will not make any friends by insulting some of the smartest developers on the Linux desktop today. Like it or not, .NET is becoming a force to be reckoned with on Linux.

The Mono .NET framework implementation is more complete than many people realise, and in terms of efficiency, design, feature-completeness, and best of all, freedom, it beats the non-free Java implementations hands-down.

Debian users will be able to apt-get install a JIT virtual machine that can play cross-platform applets in their browsers for the first time ever without resorting to propriterary software, and as far as I'm concerned, that's the most important thing we can ask for from a desktop OS -- a good, modern infrastructure for the development of desktop and server applications.

Any legal objections are simply false. Eben Moglen, rofessor of Law he will then once again have my full support.

As someone else stated, it's a standard, not a product. The C# Standard merely describes the C# language.

Where are the APIs? That's a different standard. ECMA-335, to be precise, and it describes a set of APIs to program against, as well as what the intermediate language is, the semantics the the IL, how it should be executed... In short, most of what you would need to know in order to execute a .NET program.

The one downside is that ECMA-335 doesn't define the entire library to .NET; it's missing Windows Forms, ASP.NET, and other large parts of the library. But that doesn't prevent the developer community from re-implementing these libraries. In fact, people are working on these libraries as part of the Mono Project.

- Jon

As someone else stated, it's a standard, not a product. The C# Standard merely describes the C# language.

Where are the APIs? That's a different standard. ECMA-335, to be precise, and it describes a set of APIs to program against, as well as what the intermediate language is, the semantics the the IL, how it should be executed... In short, most of what you would need to know in order to execute a .NET program.

The one downside is that ECMA-335 doesn't define the entire library to .NET; it's missing Windows Forms, ASP.NET, and other large parts of the library. But that doesn't prevent the developer community from re-implementing these libraries. In fact, people are working on these libraries as part of the Mono Project.

- Jon

Ok, I admit it. I'm being sucessfully trolled, but in an attempt to educate those who don't know any better, I'll plow on ahead.

C# is not in beta. C#, as implemented in the .Net Framework SDK, released earlier this year. ECMA has also ratified standards for C# and the CLI (Common Language Infrastructure.) Someone correct me if I'm wrong, but Java (tm) is not a standard, it is wholly owned by Sun.

That said, C#, as a language, isn't a order of magnitude better - or worse - than Java. The core languages themselves are roughly equivalent. They are both C++ derived, single inheritance OOP languages without generics (yes, I know JG is looking at generics for Java (tm) - Anders is considering it for C#.) C#, in and of itself, won't kill Java. If anything, it's the integration between the tools, the ease of use, the boring simplicity of SOAP, etc that will bring Java developers over to .Net.

As far as API support goes, I'm not even sure I know what you're talking about, and I suspect you don't either. The .Net framework comes with a APIs for writing GUIs, asynchronous messaging, diagnostic logging, file, network and device IO, internet protocols, rich collection data types like hash tables and dictionaries, XML DOM, SOAP, reflection, ........ the list goes on and on. Look no farther than sourceforge for examples of great, free software such as NAnt, NUnit, and log4net. Being a Java (tm) guy, I'm sure you'll understand what insired those projects.

Ok, I admit it. I'm being sucessfully trolled, but in an attempt to educate those who don't know any better, I'll plow on ahead.

C# is not in beta. C#, as implemented in the .Net Framework SDK, released earlier this year. ECMA has also ratified standards for C# and the CLI (Common Language Infrastructure.) Someone correct me if I'm wrong, but Java (tm) is not a standard, it is wholly owned by Sun.

That said, C#, as a language, isn't a order of magnitude better - or worse - than Java. The core languages themselves are roughly equivalent. They are both C++ derived, single inheritance OOP languages without generics (yes, I know JG is looking at generics for Java (tm) - Anders is considering it for C#.) C#, in and of itself, won't kill Java. If anything, it's the integration between the tools, the ease of use, the boring simplicity of SOAP, etc that will bring Java developers over to .Net.

As far as API support goes, I'm not even sure I know what you're talking about, and I suspect you don't either. The .Net framework comes with a APIs for writing GUIs, asynchronous messaging, diagnostic logging, file, network and device IO, internet protocols, rich collection data types like hash tables and dictionaries, XML DOM, SOAP, reflection, ........ the list goes on and on. Look no farther than sourceforge for examples of great, free software such as NAnt, NUnit, and log4net. Being a Java (tm) guy, I'm sure you'll understand what insired those projects.

Try here

That title is a bit misleading.
If you read the article, it says that HTTP is not optimal for anything more than relatively simple web services - in other words, complex applications with operations that take more than a few minutes to execute shouldn't use HTTP as their RPC protocol.
Sounds reasonable to me, provided the new protocol is standardized in a way similar to the other net standards, e.g. RFCs, and all that.[1]

The cli and description of C# have been passed by ECMA, for whatever that is worth,

Prolly not much, but more than the (AFAIK) lack of open, published standards for Java, which I see as being .net's direct competitor.

As for mono, there are other people working on office file formats so that they can be created/read/used on other platforms....that hardly makes them interoperable or cross-platform.

I see a huge difference here.[2]
People writing office import/export filters have to reverse engineer the mostly-undocumented format.
There is no detailed, published spec of the office formats.

If you think .net is MS's plan to be the good guy and support "open standards" so that developers can develop on whatever platform they want and users can use whatever platform they like...well, I sugges you take a long look at their history.

Of course they aren't, but you can say that about any company, really.
Everyone is trying to make a buck[3], usually at the expense of someone else.
"Business ethics" is an oxymoron.

C-X C-S
[1] Hell, even the MS guy (not an exec, BTW) said "if one vendor does it on their own, it will simply not be worth the trouble."
[2] I'd say it's an apples to oranges comparison, but someone recently proved scientifically that apples and oranges were basically the same. :)
[3] Netscape certainly ignored/made up their share of "standards" back in the pre-mozilla days, that's for sure.

The spec is over 400 pages, and I've been meaning to read it one of these days, but it hasn't been a real priority for me yet--can you be more specific? There are certainly huge differences, but do any of them represent new capabilities (as opposed to "negative variety" due to not-invented-here syndrome)? Assemblies seem to be a workaround for vendors too brain-damaged to rename libraries when they violate old interface contracts, and unsafe code completely subverts the security model. What have they done that's actually an improvement?

This is really not true - the CLI is very different than the JVM from the perspective of compiler and tool builders.

You should check out the ECMA spec for details, but there are a whole lot of differences that will make the world a much better place for people who want a component model rather than just OO fluff.

I think your view of .NET is a little clouded by the fact that Microsoft is involved. Sure Microsoft has demonstrated monopolistic practises, but when is the last time they released a standard to ECMA and then purposely broke it?

You cannot do this if you are chasing standards Microsoft sets.

The standards are now in ECMA's hands to maintain. Sure, Microsoft can change libraries they don't release to standards organizations, but I believe that the benefit of the .NET runtime will be seen in the open source community without those libraries anyway.

So write of GNOME (Ximian's Mono Project, to be more specific, GNOME hasn't decided to incorporate Mono yet) and .NET if you want to, but you're doing it at your own peril.

This point has been made before, but it bears repeating. C# and the CLI (Common Language Infrastructure) are ECMA standards! As such Microsoft no longer truly controls them. There is nothing to keep Microsoft from 'embracing and extending' these standards if they do not like the direction they are going. Just as they can with any open standard. Just as you can with any open standard.

MS tried the embrace and extend strategy with Java, remember? And they ran into a huge roadblock. Namely Java is not an open standard. Despite what Sun says in the press releases the standard is not open in the same sense. Sun controls it and Sun can shut down any attempt to create a non-conforming version.

From some points of view this is a good thing. But, although I appreciate any argument that starts with 'We need to avoid incompatible versions.' I also know that Sun has not proven any better than Microsoft as a steward when it comes to keeping the commons clean and competitive. To put it simply; I just don't trust them. And I think there is an equally persuasive argument that competing products evolve faster while products without competition tend towards stagnation. This eco-system analogy appeals to me.

From this point of view let us return to 'embrace and extend'. In a closed standard a single organization controls all progress for that standard, with limited participation from the outside. In an open standard the process is, at least titually, open to outside input and you are more likely to see third-party enhancements absorbed into the standard itself. Furthermore no corporation is going to sue you if you create your own implementation of the standard. Even if it is tweaked to work best on a competing platform. (Can we all say 'Mono'?)

So, the way I look at it, C# and the CLI will drive Sun to improve Java. Third-party implementors will drive the C# and CLI specifications faster than MS would alone. In the end we get better technology. I like better technology. So I win either way.

Besides, I like the design of the CLI a lot. And C# looks like an arguably better language than Java.

Finally, many arguments in the 'One Runtime' article seem a bit weak to me. For example, "... Design-by-Contract, a fundamental strength of Eiffel that .NET does not support." Since when does 'Design By Contract' have to be baked into the underlying runtime to make it work? What is keeping you from implementing any kind of runtime you want on top of the CLS?

Jack William Bell, who likes the idea of coding with mix-n-match programming languages.

This point has been made before, but it bears repeating. C# and the CLI (Common Language Infrastructure) are ECMA standards! As such Microsoft no longer truly controls them. There is nothing to keep Microsoft from 'embracing and extending' these standards if they do not like the direction they are going. Just as they can with any open standard. Just as you can with any open standard.

MS tried the embrace and extend strategy with Java, remember? And they ran into a huge roadblock. Namely Java is not an open standard. Despite what Sun says in the press releases the standard is not open in the same sense. Sun controls it and Sun can shut down any attempt to create a non-conforming version.

From some points of view this is a good thing. But, although I appreciate any argument that starts with 'We need to avoid incompatible versions.' I also know that Sun has not proven any better than Microsoft as a steward when it comes to keeping the commons clean and competitive. To put it simply; I just don't trust them. And I think there is an equally persuasive argument that competing products evolve faster while products without competition tend towards stagnation. This eco-system analogy appeals to me.

From this point of view let us return to 'embrace and extend'. In a closed standard a single organization controls all progress for that standard, with limited participation from the outside. In an open standard the process is, at least titually, open to outside input and you are more likely to see third-party enhancements absorbed into the standard itself. Furthermore no corporation is going to sue you if you create your own implementation of the standard. Even if it is tweaked to work best on a competing platform. (Can we all say 'Mono'?)

So, the way I look at it, C# and the CLI will drive Sun to improve Java. Third-party implementors will drive the C# and CLI specifications faster than MS would alone. In the end we get better technology. I like better technology. So I win either way.

Besides, I like the design of the CLI a lot. And C# looks like an arguably better language than Java.

Finally, many arguments in the 'One Runtime' article seem a bit weak to me. For example, "... Design-by-Contract, a fundamental strength of Eiffel that .NET does not support." Since when does 'Design By Contract' have to be baked into the underlying runtime to make it work? What is keeping you from implementing any kind of runtime you want on top of the CLS?

Jack William Bell, who likes the idea of coding with mix-n-match programming languages.

This point has been made before, but it bears repeating. C# and the CLI (Common Language Infrastructure) are ECMA standards! As such Microsoft no longer truly controls them. There is nothing to keep Microsoft from 'embracing and extending' these standards if they do not like the direction they are going. Just as they can with any open standard. Just as you can with any open standard.

MS tried the embrace and extend strategy with Java, remember? And they ran into a huge roadblock. Namely Java is not an open standard. Despite what Sun says in the press releases the standard is not open in the same sense. Sun controls it and Sun can shut down any attempt to create a non-conforming version.

From some points of view this is a good thing. But, although I appreciate any argument that starts with 'We need to avoid incompatible versions.' I also know that Sun has not proven any better than Microsoft as a steward when it comes to keeping the commons clean and competitive. To put it simply; I just don't trust them. And I think there is an equally persuasive argument that competing products evolve faster while products without competition tend towards stagnation. This eco-system analogy appeals to me.

From this point of view let us return to 'embrace and extend'. In a closed standard a single organization controls all progress for that standard, with limited participation from the outside. In an open standard the process is, at least titually, open to outside input and you are more likely to see third-party enhancements absorbed into the standard itself. Furthermore no corporation is going to sue you if you create your own implementation of the standard. Even if it is tweaked to work best on a competing platform. (Can we all say 'Mono'?)

So, the way I look at it, C# and the CLI will drive Sun to improve Java. Third-party implementors will drive the C# and CLI specifications faster than MS would alone. In the end we get better technology. I like better technology. So I win either way.

Besides, I like the design of the CLI a lot. And C# looks like an arguably better language than Java.

Finally, many arguments in the 'One Runtime' article seem a bit weak to me. For example, "... Design-by-Contract, a fundamental strength of Eiffel that .NET does not support." Since when does 'Design By Contract' have to be baked into the underlying runtime to make it work? What is keeping you from implementing any kind of runtime you want on top of the CLS?

Jack William Bell, who likes the idea of coding with mix-n-match programming languages.

Patents are going to screw any free software/OSS implementation of .NET, and anyone (i.e. GNOME) depending on it is going to be f**ked.

Microsoft has flat out said that it will use patents to defend it's .NET investment. Miguel claims that lawyer(s) have told him that the patent issue can be avoided.

DON'T BELIEVE IT (I don't; here's why):

ECMA rules stipulate RAND licensing of member's patents, and don't require disclosure of pending patents. Remember Miguel's quote about those, spiffy -- novel -- assemblies? What if MS has a broad patent filed to cover those? What if MS has a bunch of other overly broad patents in the pipeline to stuff that may seem non-novel, obvious, or based on prior art to you and I, but which a judge or patent examiner will give the benefit of the doubt?

Microsoft will use patents for things like this to force all implementers of the standard beside themselves to pay, OSS/Free Software or not.

And that's the good scenario! Suppose MS does a RAMBUS and says that they aren't LEGALLY bound by ECMA RAND policies? Then they could refuse to allow an OSS/FS implementation at all, and even if it wouldn't ultimately stand up in court, what free software company, developer or user can afford to fight one of the most deep-pocketed companies in existence in court on this one?

Abandon hope all ye who enter here...

ECMA-334 and ECMA-335 were approved by the ECMA General Assembly on 13th December 2001.

ECMA-334 and ECMA-335 were approved by the ECMA General Assembly on 13th December 2001.

How is this situation any different from free software projects using Sun's Java technologies? Isn't this just two sides of the same coin?

On one side you have Gnome intending to use Mono, a cross-platform language and runtime environment based on open standards,
and on the other you have projects such as Apache's Jakarta using Java, a cross-platform language and runtime envionment based on almost open standards.

I don't recall seeing RMS bitching too heavily about Sun's absolute control of the Java language and runtime.what it was that RMS didn't like about it. I wouldn't be surprised if he's just being reactionary for the sake of it.

How is this situation any different from free software projects using Sun's Java technologies? Isn't this just two sides of the same coin?

On one side you have Gnome intending to use Mono, a cross-platform language and runtime environment based on open standards,
and on the other you have projects such as Apache's Jakarta using Java, a cross-platform language and runtime envionment based on almost open standards.

I don't recall seeing RMS bitching too heavily about Sun's absolute control of the Java language and runtime.what it was that RMS didn't like about it. I wouldn't be surprised if he's just being reactionary for the sake of it.

It has been SUBMITTED to the ECMA (not IEEE), but I'd like to see link to info that it actually has been APPROVED as a standard. The last spec document I saw had the entire chapter on exceptions missing, for instance.

The difference between submitted and approved is an important point so I checked for the current status at ECMA where the NEWS link on the front page led to this:

Assembly met in Montreux on 112the December 2001, and approved 33 revised and 7 new Standards. Among the new Standards, the files of Standard ECMA-334, C# Language Specification, and Standard ECMA-335, Common Language Infrastructure (CLI), are already available in this web site and can be freely downloaded.

An ECMA TR, ECMA TR/84, related to Standard ECMA-335, has also been approved and can be found here.

It has been SUBMITTED to the ECMA (not IEEE), but I'd like to see link to info that it actually has been APPROVED as a standard. The last spec document I saw had the entire chapter on exceptions missing, for instance.

The difference between submitted and approved is an important point so I checked for the current status at ECMA where the NEWS link on the front page led to this:

Assembly met in Montreux on 112the December 2001, and approved 33 revised and 7 new Standards. Among the new Standards, the files of Standard ECMA-334, C# Language Specification, and Standard ECMA-335, Common Language Infrastructure (CLI), are already available in this web site and can be freely downloaded.

An ECMA TR, ECMA TR/84, related to Standard ECMA-335, has also been approved and can be found here.

It has been SUBMITTED to the ECMA (not IEEE), but I'd like to see link to info that it actually has been APPROVED as a standard. The last spec document I saw had the entire chapter on exceptions missing, for instance.

The difference between submitted and approved is an important point so I checked for the current status at ECMA where the NEWS link on the front page led to this:

Assembly met in Montreux on 112the December 2001, and approved 33 revised and 7 new Standards. Among the new Standards, the files of Standard ECMA-334, C# Language Specification, and Standard ECMA-335, Common Language Infrastructure (CLI), are already available in this web site and can be freely downloaded.

An ECMA TR, ECMA TR/84, related to Standard ECMA-335, has also been approved and can be found here.

It has been SUBMITTED to the ECMA (not IEEE), but I'd like to see link to info that it actually has been APPROVED as a standard. The last spec document I saw had the entire chapter on exceptions missing, for instance.

The difference between submitted and approved is an important point so I checked for the current status at ECMA where the NEWS link on the front page led to this:

Assembly met in Montreux on 112the December 2001, and approved 33 revised and 7 new Standards. Among the new Standards, the files of Standard ECMA-334, C# Language Specification, and Standard ECMA-335, Common Language Infrastructure (CLI), are already available in this web site and can be freely downloaded.

An ECMA TR, ECMA TR/84, related to Standard ECMA-335, has also been approved and can be found here.

"Java and C# are closed languages."

Only one has been accepted by a standards body... and it's not Java.

http://www.ecma.ch/ecma1/MEMENTO/TC39-G2.HTM

They don't?