De Icaza Responds on Mono and GNOME

miguel writes: "Here is my reply to the various questions on Mono, the future of GNOME and the Register statements." Linux Today has a copy of the email as well.

The crux of his argument

GNOME had always tried to have a good support for multiple programming languages, because we realize that no matter how much we loved C as a programming language, there was a large crowd of people out there that would like to use the GNOME libraries fromtheir favorite programming language, which might not necessarily be C.

This is the reason having Mono at the heart of Gnome would be a good idea. Base it on the CLI and suddenly any language that is ".Net-enabled" is usable under Gnome.

It's about choice. Isn't that what Open Source is all about?

Re:The crux of his argument

Don't get too excited about this "any .NET enabled language" being able to drive GNOME. If you think about it, the number of possible languages is pretty dim (mostly C#). Why that? Because .NET must handle common interfaces across those languages. If I use a more exotic language with features not found in others (like multiple dispatch, funky lambda-lists or closures in Common Lisp) I don't think I'll be able to export Interfaces using these features. As those happen to be 'natural' to these languages, I'd have to limit myself in how I can write my applications/libraries.

.NET is far from being the perfect solution.

Re:The crux of his argument

You do raise an interesting point. Some features are not available to all languages (for example, a LISP closure definition).

But there is a large subset that is. This subset is encapsulated in the Common Language Specification (CLS) which differentiates between:

* Consumer languages.
* Provider languages.
* Consumer/Provider languages.

You can find the details here:

here [microsoft.com]

Miguel

Re:The crux of his argument

Which was exactly why MS 'broke' VB6. Some parts of the language needed overhaul to be CLS compliant. I imagine other languages will need the same kind of overhaul. And that might not be such a bad thing. VB is a much cleaner and nicer language thanks to the overhaul (although there are still things i don't like, and i would still stick with C).

Programmer's Life

Really, programmer's lives are boring, I wish my life would be as exciting as other people's life appear to be.

Wrong. Programmer's lives are exciting, as long as you like Computer Science and enjoy tweaking with the little bits, discovering new things. Now, if Miguel started writing Unix software thinking he would be rich, surrounded by girls and driving Romero's Ferrari, he's far beyond dumbness.

Re:Programmer's Life

I guess you miss-understood.

Writing about a programmer's life is pretty boring. The programmer might be enjoying himself, but to an external viewer he is only tapping at a keyboard.

miguel.

You're Not Surrounded by Girls?

Dude, what's wrong with you? The rest of us are swimming in chicks, piles of cash and fast cars! You must be doing something wrong! As long as you follow the instruction book they send you when you start an open source project, all this can be yours. It outlines in clear steps exactly what you need to do to make your fortune using Open Source software, and it always works! Didn't you get yours yet?

Good response...

Sorry, but RMS tends to fly off the handle any time he even gets a whiff of something non GNU. So do we all here it seems. I'm tired of hearing it from the community because it's starting to hold us back.

Miguel has made many positive arguments for his prior statments. And thanks to the Register for obfuscating the variables.

Re:Good response...

The guy demanded a response, as if De Icaza was somehow obligated to jump when RMS said frog. He might, just might, try asking for more information and then taking time to frame a rational response instead of treating somebody else as a lackey who needed to come explain himself to the master. Stallman's good ideas and tireless campaigning for what he believes to be right get ignored because he comes across too often as a freak and a prick.

Some of the donations and grants the FSF brings in need to go to a good *publicist*, instead of more coders and lawyers. Like it or not, RMS is a poster child for the Open Source and Free Software movements, but he needs some serious help with his image before all those shiny folks in suits who make IT purchasing decisions will even pay attention to him, or anyone associated with him. A good souless weasel PR guy will keep RMS from making kneejerk responses that piss off folks who might otherwise go along with him, and it will free Stallman's time up for more of the things he does do well. Everyone wins - the pointy haired bosses can interact with the brighty colored and non-threatening Stallman Interface, and the real geeks can get work done with the Command Line RMS.

-reemul

Great reply, but...

Reading Miguel's response makes me better understand why it is that he's so enthusiastic about the .NET framework (as he calls it).

One thing though. Miguel says:

So when you copy your binary from Windows that was compiled with the Visual Studio.NET and run it on your Unix platform, it will just integrate nicely with your GNOME desktop.

This just strikes me as overly hopeful optimism to think that Microsoft is going to give up their hard fought and long defeneded applications barrier to entry.

Re:Actually, this is the way it is

Any compiled class written in Java can run in any environment with a JVM.

Unless that class inherits or calls proprietary library stuff that you don't have.

This is why I can't run most Java stuff on my Amiga. I have the Kaffe JVM, but no AWT. So I can run a program that says "hello world" and even Sun's Java compiler (written in Java) that comes with the JDK. But AWT or Swing apps are right out, because no one has implemented that stuff for my OS.

You're going to have the same problem running Microsoft Office on Linux. Your VM will work perfectly, but the app will want to use stuff that you don't have.

Re:Great reply, but...

This just strikes me as overly hopeful optimism to think that Microsoft is going to give up their hard fought and long defeneded applications barrier to entry.

Yes, this is a key area where I think de Icaza has a problem. He's clearly planning on implementing Winforms (I checked on the Mono site) and those are not part of the ECMA C#/CLI/CLR spec. Microsoft will not permit those classes to be cloned - its already dropped strong hints about it.

An interesting thing to do would be to write a Java compiler (backend) for the CLR, and try to implement Swing or Eclipse in a Gnome environment...hmmmm. Of course, on the other hand I can just use one of the excellent Java runtimes for Linux, and get better performance. I can still use other languages through JNI (and DirectIO in JDK 1.4).

All that said though, competition is good. Perhaps .Net and Mono will do more to spur Sun to refine Java significantly further.

299,792,458 m/s...not just a good idea, its the law!

Alan Cox Says It Best

Miguel:
> or ourselves. I want to be as compatible as
> possible with the APIs that were published by
> Microsoft.

Alan:
Be assured that the day they decide you are a nuisance the VM will acquire a patented neat feature that kills you off. Just ask the Samba people.

(from Alan's reply to Miguel's message)

Re:Alan Cox Says It Best

Microsoft will HAVE to publish APIs etc. for patented features. How else can they get a patent? The whole point behind a patent is that you are granted a 100% legal monopoly for your product IN EXCHANGE for your full disclosure of your product.

Unfortunately, this is the future of proprietary software. Look around at any developing area.

Microsoft has patented the second generation Windows Media Format codecs. Real had patented its codecs. Apple holds exclusive licensing for Sorenson codecs used in Quicktime. So if you want to make or decode a decent video codec, you have to license a patent.

SAMBA is now also encumbered with patents with respect to user authentication. The next generation of Windows will contain this authentication, and the SAMBA team will be unable to make a functional work-alike. Too bad, that is the law.

Unless the Microsoft settlement has something to say about open licensing of patented formats, codecs, and authentication, making software to duplicate new Windows functionality, or providing file or print servers for Windows machines, will become impossible without licensing from Microsoft. You can expect that authentication of users under .NET will use patented protocols, and that they will similarly use other patented protocols into other inter-machine communication APIs. After all, there are a lot of ways to skin a cat; this is one way to keep free software out of Microsoft-monopolized areas.

Re:Alan Cox Says It Best

Miguel himself responded to this point:

"There is the issue that we might not be able to keep up (right
now, we dont, as .NET Framework 1.0 is already out there, and we
are, well still underway). Also, theoretically there is the risk
of a given API being unimplementable on Unix.

Even if that is the case, we still win, because we would get
this nice programming environment, that althought might not end up
being 100% .NET Framework compatible, it would still be an
improvement and would still help us move forward. So we can reuse
all the research and development done by Microsoft on these ideas,
and use as much as we can."

This applies just as much to being intentionally broken by Microsoft as it does to them simply outpacing Mono's development.

Microsoft has and will enforce .Net patents

From Craig Mundie, VP of Microsoft at the O'Reilly Shared Source vs. Open Source Panel Discussion (http://linux.oreillynet.com/lpt/a/linux/2001/08/0 9/oscon_panel.html [oreillynet.com])

Craig: "But look: we're a business, okay? We're in the business of licensing intellectual property. So if it turns out that in the future that business says, "Okay, we should license the patents to people who use that in order to be compensated for the development of intellectual property," maybe we'll do that. You're always welcome to come and ask us to license anything from sources to patents. But I mean, we are a business. We're not --

...

Craig: Well, at the end of the day, if you have a patent, you enforce the patent if it's valuable to you. And so I think that Microsoft and other people who have patents will ultimately decide to enforce those patents.

Brian: Are there any patents that apply or that will apply to implementers of .Net or Hailstorm?

Craig: I expect there certainly will be. I mean, the patent process takes a long time.

Those who fail to learn from history...

..are doomed to repeat it.

Over and over again, Miguel De Icaza has displayed the same sort of breathless excitement over Microsoft technologies that I'd expect to see from a newbie, not a developer of his caliber. It's extraordinarily short-sighted for him to believe that he'll be able to keep up with Microsoft. This isn't a matter of talent. Microsoft has shown, time and time again, that it has no problem locking out other vendors using API changes and whatever other means available.

Miguel seems to be ignoring the fact that Microsoft will very likely do everything it can to keep Mono uselessly lagging. They've embraced and extended every technology they've adopted, and even their own APIs shift constantly. I realize that the .NET Framework looks like a different approach, and Microsoft is acting like it's going to start playing nice. If it happens, it'd be a first for Microsoft. I personally have my doubts, and history backs me up. What a shame that a talented developer like Miguel doesn't know better than to trust them.

-zack

Re:Those who fail to learn from history...

I think he does realise it. He pointed out that even if it isn't compatible, he'll still end up with a better development environment, at the expense of MSFT's R&D department.

To quote:

* What if we never can keep up?

There is the issue that we might not be able to keep up (right
now, we dont, as .NET Framework 1.0 is already out there, and we
are, well still underway). Also, theoretically there is the risk
of a given API being unimplementable on Unix.

Even if that is the case, we still win, because we would get
this nice programming environment, that althought might not end up
being 100% .NET Framework compatible, it would still be an
improvement and would still help us move forward. So we can reuse
all the research and development done by Microsoft on these ideas,
and use as much as we can.

I hate to be a dick, but.

There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists [1]

Last time I felt that way, I dicovered Lisp. Java also fits the bill (and so does C++ with STL, BOOST and ACE.

Re:I hate to be a dick, but.

Of course, with Mono you get all that neat stuff while still being able to code in _whatever_ language(s) you want and have it work transparently and consistently.

Whatever language you like so long as its semantics and runtime behavior have been massaged to work with the CLR.

Really, the CLI/CLR is just like the Jave byte codes and JVM, except that CLR's is a bit less strict about security and in that the CLR's support for 'unmanaged' code allows for cleaner support of native machine code than does Java's JNI interface. It's a convenience thing, much as Visual C++'s helpful COM automation wizards are a convenience thing.

The biggest difference between Java and the .NET framework is that Java's bytecodes and VM are a bit more paranoid about things like security, and that Java is designed with portability as a first order concern. .NET code will probably never be as portable as Java, precisely because it is designed to make it super easy to interface with operating system level code. Java is designed to make it a pain to use any code that isn't itself portable.

CLR and so-called language independance

Good article on this appeared today:
One Runtime to Bind Them All [javalobby.org]

Some quotes:

The reality looks much darker instead. The CLR is not truly language-neutral, and it will ostensibly favor languages that look a lot like C#. Those not in this group will be severely bastardized, producing dialects which are really "C# with another syntax"; look at ISE's Eiffel# (or even Microsoft's own VB.NET and J#) for great examples. Programmers' choice will be limited to superficial features: whether to delimit their blocks with curly braces, Begin/End or parentheses. It's also worth notice that the CTS/CTS do not allow use of the full set of CLR features; for example, unsigned integers are supported by the CLR but not considered language-neutral, simply because many languages share Java's abomination for the signed/unsigned duality (this includes Microsoft's own VB) and there's no good solution for this issue.

-cut-

Playing with the .NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a language's most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the system's look and feel, add a few features, but never compete with a fully new toolkit.

Re:CLR and so-called language independance

It's a sad thing that the JVM also sucks for non-Java-like languages. One of the points that they make is that languages like Lisp and Smalltalk suck on the CLR. However the same issues are present in the JVM (Kawa's bowdlerized Scheme implementation notwithstanding). And it's not like Sun hasn't been aware of this shortcoming either (With people like Guy Steele and Dick Gabriel on their research payroll, how could they not be aware?). If they had listened to people outside the Java community that wanted a better (read MORE UNIVERSAL) VM, they might had had a moral leg on which to stand.

As it is, this stupid editorial is just a case of the pot calling the kettle black. The only problems that Sun should have with CLR is that (1) it's by Microsoft and (2) Microsoft did a better job at beating Sun at their own game. Not that I like the CLR any beter than the JVM - they both blow chunks for dynamically-typed languages and for languages having anything different from simple class-based objects, but this editorial is just brain-dead.

Re:CLR and so-called language independance

As it is, this stupid editorial is just a case of the pot calling the kettle black.

Yes, that's exactly what it is. I think you are misinterpreting the article [javalobby.org]. The author is trying to say that runtimes can only be optimized for one language, and that the .NET stuff will not be any better at running other languages than the JVM is.

I don't know if that is true or not, but don't try to pretend this article is saying that the JVM is better in some way. The only problems that the author has with the CLR is that (1) it is by Microsoft, and (2) Microsoft is (according to the author) lying about the CLR's capabilities to be cross-langauge.

-Mike

Great article!

I liked the comparison of technologies, but it misses a main point. Or rather, I believe its primary audience misses a main point.

.NET is not perfect. The JVM is not perfect. But I strongly believe that they are a step in the right direction. For example, the current choice(?) on UNIX systems is to have C-compatible exports for libraries.

While .NET and the JVM may be limited, let's not loose track of the fact that extern "C" {} and its ilk are far more limited. Instead of limiting languages to objects without templates and continuations, the current scheme of exporting function symbols and structs is downright embarrasing.

What would be really nice is using .NET as a library/component interface and leave each language relatively intact. For example, implement your library/component in the language of choice, but export the functionality (what is currently "handled" by library symbols) in a language-neutral but far more feature-rich manner.

Doesn't "Managed C++" allow for advanced C++ features that simply are not exported for use outside the codeblock? C# has "unsafe" blocks for its own bit-twiddling.

We're on the right track here. Let's not throw the baby out with the bathwater!

Advantages of C# over Java

This is a nice clarification, but it makes at least one assertion that is a little questionable: what are the advantages of C# over Java? I asked this question yesterday and no-one responded. Here Miguel claims (in the What is Mono? section):

Seasoned industry programmers will notice that the above is very much like Java and the Java VM. They are right, the above is just like Java.
The CIL has one feature not found in Java though: it is byte code representation that is powerful enough to be used as a target for many languages: from C++, C, Fortran and Eiffel to Lisp and Haskell including things like Java, C#, JavaScript and Visual Basic in the mix.

But this is surely misleading? It's true that this doesn't exist at present, but there's nothing in theory to stop it being implemented (isn't Java sufficiently "powerful" for this to be done?)

If Java is capable of doing it, then why not work on making compilers for those languages to Java's bytecode instead of working with a new language?

Re:Advantages of C# over Java

Sun proved, when they sued Microsoft, that they don't want Java-the-language being used to generate code to run anywhere but inside Java-the-VM or have direct access to anything but the Java classes.

Not true at all. Look at Apple's Cocoa [apple.com] framework, which allows you to write native Mac OS X applications in Java. Sun has no problem with that, because Mac OS X also includes the 100% compatible pure Java envrionment. Sun sued Microsoft not because MS added features, but because they deliberately introduced incompatibilities in the core Java classes.

Refreshing

The guy makes a lot of points in his e-mail, a lot of good points. Its good to see a leader of the open source community looking at something from the perspective of "use the best tools for the job" than the more common attitude that "anything that has anything to do with Microsoft, or anything that can be confused as having something to do with Microsoft in any way is always bad". This guy is showing some vision and this kind of thinking should be applauded and welcomed. This is what the open source community needs, someone who can challenge ideas make positive changes and get things done. What we don't need are people that refuse to look at things because their heads are stuck up their butt with their with ridiculous counter productive politics and bandwagon views of this is bad that is bad for no good reason.

CLR and language neutrality

The CIL has one feature not found in Java though: it is byte code representation that is powerful enough to be used as a target for many languages: from C++, C, Fortran and Eiffel to Lisp and Haskell including things like Java, C#, JavaScript and Visual Basic in the mix.

Unfortunately, this statement is very close to marketing hype. A very good overview of why the language independence of the CLR is little more than a myth is given in this article [javalobby.org]. Despite the slight Java slant, the article is very factual and fairly objective.

It seems to me that Miguel is using this argument to justify his personal preferences for the CLR, while there are a number of other existing VMs providing similar functionality that could have been chosen instead. Many of them are far more mature than the CLR, and have far richer libraries available on top of them to boot.

Why CLR?

I think it's clear that using common bytecode offers some advantages to developers, as outlined by Miguel. It also seems like CLR can offer performance advantages over Java since it basically just maps native API calls to functions in the .NET framework, much like wxWindows [wxwindows.org] or anyGui [sourceforge.net] do for GUIs. If the classes are properly documented, it should be possible to match their functionality on other operating systems.

So what is Microsoft aiming for? Probably two things:

- Kill Java. They need to kill it before it becomes too wide-spread. They have a really good shot at doing so given Java's performance problems [insert thousands of flames from Java developers here] and C#'s advanced features like better encapsulation (you