Slashdot Mirror
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.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
> Miguel wrote:
..., iff the (.NET) CIL is sooooo powerful.
> 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.
Bullshit. See here for JVM languages.
Furthermore care to explain the existance of "managed" C, Perl,
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)
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.
No... he lobbies for Free Software (which he had meticulously defined). He speaks up in logical arguements when Free Software is threatened with loss of any of the fundimental points of Freedom.
If I lobbied against rape, would you expect me to say "Well, okay - you can rape her this one time" or "That occasion was okay - he only raped her a little bit"? Sure, it's not "as important" as rape, but at one time, in many cultures, rape of the lower clases by the upper classes was considered part of society. RMS simply sees a vision of a better, more humane future, and is working towards that.
Note that I don't necessarily *agree* with him - just that I can see that his inflexibility is a virtue.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
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?
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 don't need to call set() and get() methods, you can map them to the = operator, for example).
- "Write once, run on Microsoft". In order to run .NET apps on another platform you would have to virtually re-implement (or substitute) the entire Win32 API, which will probably be modified at an ever-increasing pace. No company can keep up -- only open source may be able to do that, but Microsoft's opinion might be that open source is no real threat for the platforms where they want to deploy .NET. (After all, even the average Slashdotter seems to think that Linux will never be ready for the desktop -- quite idiotic, IMHO, but the more people believe that, the better.)
Insofar Ximian's Mono project may be a good thing as it offers a migration path where previously none existed (from Windows to Linux), even if .NET apps don't run properly on Mono (think about all the GUI stuff that can go wrong, for example). Besides, Java has never really been a mature technology IMHO and it's about time to replace it with something better, even if superficially less cross-platform.
Now the advantages of having a modular architecture become clear. Mono cannot break Linux, it cannot break X, it can probably not even break GNOME. There are more alternatives than you can throw a kernel image at if something goes wrong. Let's just wait and see what the Mono guys come up with. The only people who should worry about this are Sun and their followers. And maybe RMS.
Miguel's arguments sound all well and good, but I think he is fundamentally naive about Microsoft.
.NET framework are still vague. Now, why might that be? The naive might think it's because Microsoft still haven't worked some of the details out. As has been stated many times before, Microsoft is betting the farm on .NET. Microsoft are a very competitive company, with one of the most lucrative monopolies in the world. Think about that. Imagine how Microsoft will respond if they start to loose market share, or control over developers, because of Mono.
.NET! That's because it's great technology and these days we're such nice people." But as soon as they feel it's a threat, well...
Microsoft have fought tooth and nail over many years to build their monopoly. They will do whatever it takes to protect that, within the boundries of what they can get away with these days.
Some parts of the
As long as Mono stays a little project (which it is as far as Microsoft is concerned) then they will play nice. They will be able to point to it and say "Hey, look, even the Open Source people are supporting
Don't be naive Miguel. You are implementing a copy of a system still under development the world's largest and most aggressive software monopoly. Think about that.
when this comes to its only possible conclusion: microsoft silently encourages this effort until lots of gnome folks understand how to write c# and write to the .net fwk apis - then they will crush mono/open source .net; they'll kill you with licensing and incompatibility; they'll take you to court and screw you silly.
.net fwk class libraries - what do you think those folks will do? learn something else, or put those skills to work - often for money - on windows.
and then you'll have a huge group of people that like coding c# using the
and i will laugh my ass off at you idiots.
Read the explanation. That's covered. They're implementing the ECMA spec and adding seemless access to GNOME. If there's compatibility with Microsoft's implementation, that's nice since portability is free. If Microsoft deviates from the standard, it's a shame Mono is still has merit, especially language independence which was always important to GNOME. Essentially, Mono is cherry-picking features from .NET.
Okay, you're asking, why not use Java's JVM since it supports multiple languages. As someone pointed out in the gnome lists, Java, like TCL, is Turing complete so it can support any language your CPU can. Suppose you tried to implement Java in TCL? Would you be pleased with the performance? Probably not. Java's JVM lacks several features that make running languages like C++/C, Lisp, and Haskell fast, including:
The .NET's CLR gives you these features. If Java's JVM were open source, the Mono team could easily extend the JVM to support these features. It would certainly make life a lot easier. Unfortunately, if they did, Mono would get little commercial support, and they'd receive a call from Sun's legal department. I personally hope .NET and Mono force Sun to do the right thing and extend the JVM to efficiently support other languages.
Java is nice, but the take it or leave attitude of Java is the reason .NET was not laughed out of existence.
Let's face it. As much as we may not like it, the majority of the computing world uses some flavor of Microsoft Windows as a desktop computing environment. Now, we can argue about this from many different perspectives.
(My personal opinion is that Microsoft is not necessarily evil on account of this. To be honest, Windows is actually relatively useful -and useful is what companies require to survive. Rather, Microsoft is evil simply for what they are charging for their software. Sure, they can charge companies whatever they like (I don't care). However, the common man for his home computer should not be charged hundreds of dollars for an operating system and office software. That is truely the real evil of Microsoft and the Microsoft monopoly.)
Anyways, back to my point. Miguel is right because, like it or not, Windows is a reality that we have to coexist with. We can view this as contending or perhaps cooperating. Whatever the case, it is here and that is that.
Well, as Miguel said, Windows is here and that means that
Now, if Microsoft had done a terrible job with
Therefore, it makes absolutely no sense for us to do our own thing. Especially considering the benefits that we will recieve due to actually getting along a little bit better.
Back to my prediction. I think that the computer world is heading toward a point where specific desktop platform is a non-issue. People thinking about the short term will fret about XP this, or Gnome that. However, something like
The journey to a non-platform-centric desktop world will have many parts. One of these will be the arrival of other competitors on the scene. That is hear, with wonderful options such as Linux/Gnome (foo on KDE) and Mac OS X. Ok, KDE can play too if they manage to provide things like
Other pieces of the puzzle are things that allow applications to be used from these multiple platforms. Well, suprise but some of these are already here. They best example to this is the internet. Other examples include emerging technologies such as the
Anyways, once again, just my two cents. For what it's worth, I hope someone gets something from it.
(Go Miguel, go. Go Miguel, go!)
I liked the comparison of technologies, but it misses a main point. Or rather, I believe its primary audience misses a main point.
.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.
.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.
.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
What would be really nice is using
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!
- I don't need to go outside, my CRT tan'll do me just fine.
Yes, that's exactly what it is. I think you are misinterpreting the article. 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
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!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Miguel's argument can be boiled down to this: (1) writing big applications sucks because complexity grows geometrically with each line of code, and (2) integrating code written in different languages sucks because complexity grows geometrically with each line of code in either language. Basically, Miguel is fighting the same fight that every software engineer has faced since the beginning of time. Complexity grows much faster than anyone can handle, and as soon as you let heterogeneity into the equation, you're basically screwed.
The only problem that a CLR supposedly solves is the maintanence of the bindings. Instead of binding Gtk to perl and python and ada and C and C++, etc., you bind it in a library in the CLR. Except that to access that new CLR binding, you need to have perl and python and ada and C and C++ compilers that target the CLR, which is certainly a more glamorous job than maintaining bindings for every language under the sun, but is *WAY MORE* complex.
Basically, the CLR is middleware for the desktop. It does nothing to decrease the complexity of the system, it just shifts some of the complexity to another software engineer. Applications get easier to write, but new compilers need to be written and maintained.
When Microsoft's writing the compilers and you're shelling out the cash, you're only responsible for your piece of it - the application. Obviously this is good for you. But the free software community is responsible for all of it, from compilers to run times, to new bindings, to applications. *We* have to do it all. I wonder if Ximian will really benefit from dispatching software engineers to work on Mono when they could be working on the applications. Companies that buy stuff from Microsoft don't have to send software engineers to work on Mono, but free software projects will "lose" engineers because they'll have to work on Mono, not their respective projects.
The challege that software engineers face in the future is constructing systems that actually reduce the complexity of applications, rather than just shift the complexity elsewhere.
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
The Scorpion and the Fox
A Retelling of an Ancient Middle Eastern Tale of Two Enemy Countries
by Ms. Holly
Once long ago in the vast lands of the desert there was a great and vast river that had to be crossed for animals to seek food and water elsewhere in the desert. As it was on this day Fox had come to the point where it had to cross the river in its travels. As it stood contemplating the best way to cross the river safely Fox's life long enemy Scorpion came upon it and began to talk to Fox.
"Fox as I was walking along the river bank looking for food I noticed a particularily easy place to cross the river where the water is not so deep and not so swift. As it is I would like to cross over myself also but as I am so small it would be impossible. Would you be willing to take me across if I show you this place to cross the river?" asked Scorpion.
"Why should I take you across? How could I possibly trust you will not sting me on the way across as we have been life long enemies?" asked Fox.
"Why would I sting you? For if I stung you it would mean you would drown then both of us would die." replied Scorpion.
Fox thought this over for a bit while carefully watching Scorpion with a distrustful eye. Eventually Fox said, "Show me where the place is and I will take you across."
"First place me on your back and then I will show you. For otherwise you may jump in and leave me behind once I show you." replied Scorpion.
Fox thought this over for a bit while carefully watching Scorpion with a distrustful eye. Then walked over to Scorpion and allowed him to climb onto its back. Scorpion directed Fox to where the river was not so deep nor so swift such that it was a safer place to cross over. As Fox was swimming across the river and had reached the middle of the river Fox felt a sharp stinging sensation on its back and realized it had been stung by Scorpion. Fox cried out, "How could you sting me we shall both drown now?"
Scorpion replied, "It is better we should both perish than that my enemy should live."
Can't think of clever sig so had to settle for this! Damit it Jim I am a programm not a sig writer.
First, let me say that I use Gnome for my desktop and have used GTK+ for sizable projects. I've even developed smaller GNOME applications and found the various API's horrible. I can't stress enough that I'm not trying to cook someone here for the sake of cooking. I think the only point he makes here is that GNOME is without a solid technology direction and has suffered dearly for it for a very long time. In fact, he as much as points this out. So, call me a troll if you like but I fail to see how Mono isn't anything other than a new tech headline. Please read below if you care to follow his assumptions while he explains pretty much nothing.
The CIL and the promise of language independence
This is what CORBA promised more or less. Please correct me if I'm wrong, but didn't Gnome start out using CORBA and decided that it needed different technologies later in the cycle?
Are there not already language bindings for C, C++, Python, Perl and I'm sure several others? So tell me again why we need an interpretted wanna-be CORBA in the mix?
This technology allows programming languages to be considered on the basis of how they will perform for a given task, and not based on the runtime libraries that you will depend. Any software engineer should read this article:
Generally speaking, good engineers already do this. The choice of yet another tool somehow doesn't make this happen, though, choice can be a good thing. Adding a slow runtime is not going to make the awesomely optimized FORTAN libs suddenly appear and become compatible with various CIL implementations. In fact, really all you can say is that when you use this technology [CIL implementations], the language of choice will no longer effect performance rather it will be forced back onto the developers to optimize for a given language; that is, language specific CIL tuning tricks. On the other hand, all of the languages which use this are going to have a negative performance impact so it sounds like programmers will have even more choice (seemingly pointless). Let's see, I can pick C or C++ for performance or I can pick C/C++/C# [CIL implementations] which performs an order of magnitude slower. Hmmm. Hard choice. Tell me again why I should care about CIL, Mono and C#??
GNOME had always tried to have a good support for multiple programming languages.
No it hasn't. Save only for the CORBA efforts, GNOME is very C biased. One of the common complaints coming from the C++ KDE camp. The more correct statement would be, "multiple programming languages have always tried to support GNOME." These efforts have inflicted various levels of pain on their bindings implementors.
They have incorporated many ideas from Java, and they have extended it to address new needs that developers had. They took where Java left off.
What does that mean? Sounds like they are re-implementing Java. Why? Why don't you just further improve Java. I'll make it known here, I've never beena Java fan but this just doesn't make sense to me. It only makes sense to Microsoft because they badly need to de-crown Java. Aside from Microsoft, I don't see how this helps anyone. By the way, what are these "new needs that developers had", that existing technologies can't address? Do we really have to move to a VM to address these needs?? Somehow this seems like we're taking several steps backward. Anyone?
Libraries have been built by disconnected groups (PNG, JPEG, Gtk+, Xml, Bonobo, CORBA spec apis, etc) and the end result is that a developer eventually has to learn more than he wanted to in the course of developing a large application.
Might this have more to do with the fact that GNOME has been wondering without direction for a very long time and no one in the GNOME camp has been willing to settle and agree on a single API nor the technology behind these APIs? Does it have to be the programmer's fault? Can't it be that the API's provided have just sucked? Can't it be that the API's have changed so fast and often that programmers wonder what they are doing trying to implement a large application via GNOME? Can't this mean that the implementations behind the API's have been less than wonderful and seemingly change daily? Does it have to be because programmers don't want to learn? Seems to me, if programmers didn't want to learn, they wouldn't be trying to develope large applications in a highly dynamic environment (from an API perspective). Wouldn't a static API help address this? Won't simply adding yet another API compound this issue even further?
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]
Doesn't this really reflect the choice of underpinning APIs and implementations behind the APIs as much as the language. It's funny, I've developed very large applications (C/C++) before and never had nearly as many issues as one does when trying to use the GNOME/GTK technologies. Might it be that you've been chasing the wrong end of the technology spectrum? Might it be that you should of been looking to replace GTK and the billion other obtuse libraries that are the foundation of GNOME with better, faster, stronger technologies? Might is be that the number of memory leaks and associated debugging issues have something to do with design skills and/or coding habits? In not in whole, in part? Some part? Maybe a little? If you have even a small problem which is compounded over and over in various suite of libs that is GNOME, might this actually result in a large problem manifesting it self as obtuse APIs which lend them self to these issues?
Evolution took us two years to develop and at its peak had 17 engineers working on the project. I want to be able to deliver four times as many free software applications with the same resources, and I believe that this is achievable with these new technologies.
Wow! This really is magic technology1 It's going to 4x the level of productivity over any other tool, toolkit, and language. Wow! Does it come with a bridge too? I can't wait.
Even C++ was invented at ATT.
Yes, you're right, however, it was written by people who wanted to look at solving real problems with a different approach while leveraging the large C programmer base. It was need driven. The same can not be said for C# and CIL. Both of these are being driven my Microsoft to side step Sun and Java. The motive is as important as anything else, especially when we are talking about Microsoft. If, according to you, it's pretty much Java with some icing, why not go the shortest and best path for everyone and help improve Java? Go ahead, make the icing for Java. Then, you'll have everything you're asking for with a whole lot less effort and TONS more people will be rewarded for your efforts.
Windows developers know how to write code for it.
Do they? Windows developers are going to be coding to GTK's and GNOME's interfaces? That's news to me. As far as I know, what this really means is that Windows C# programmers will be able to code C# on unix. Last I heard, Windows C and C++ programmers already know how to code C and C++ on unix. Please, tell me again where this magic bean grows from...
Lets make it easy to bring developers from the Windows world into our platform.
I must of fallen to sleep or something because I don't see how this has suddenly changed. Anyone?
Training materials, tutorials, documentation, tips and tricks are already available in large quantities, lets leverage this.
I seriously question this. Seems to me, that would be true as long as the programmer is really using C# and the underlying CIL implementation is the same. But, you're telling me that you're developing your own CIL and your own C# implementation so I doubt this will be true any more than it is today for any other given language and platform combination. More magic beans. Mmmm....I smell fresh brew magic coming my way...
Sorry folks, I've gone on long enough...I'm simply tired of typing. Obviously I don't see anything that he's stating other than there's a whole bunch of magic in this technology that no one has ever seen before. Furthermore, I think he helps make a wonderful argument that GNOME needs someone else at the helm. And if he's saying that he's not at the helm (I think he tried to say that too), then GNOME very badly needs someone which is not him.
Greg
WHAT are you talking about??
.NET's intermediat langauge is intended to be compiled into native code, for one thing. C# has lots of nice development features that Java is sorely lacking. HOW can anyone fix Java when Sun is in official control of it, and is always late in implementing features? (And then does such things 1/2 way?) Yes, Java performs better then C/C++ in some situations, but most of those situations are lacking real-world features, like a fast/native-looking GUI.
Better yet, WHAT are you comparing MONO to? Java? Well, there's lots of complains about Java out there.
Mono does Not need to be compatable with Windows in order to be a success. This was mentioned in the reply. The concepts, and the basic language of C# can't be bastardized by MS since it's already been submitted for standardization. They can add things to future versions, but how is that different then the HUNDREDS of C/C++ compiler problems out there?
Mono and the CLI will offer an easier development envirionment, allowing developers to use the best tool for the job w/out worrying about cross-language bindings. It will allow developers to easilly change from Window's C# to Mono's C# (Even if they can't use some specific language feature!). It will be a success when completed in it's own right, no matter what happens w/the MS implementation because it is good technology.
One point Miguel made really made me sit up and take notice. He pointed out that all of Gnu started out as Richard Stallman's attempt to make a free copy of a proprietary system, and Mono is just another attempt to do that same. I'd never thought of it that way, but he's right; it is very hard to remember in this day and age that 20 years ago, AT&T and company were really a lot like Microsoft as far as their treatment of end users, so why was it good for Stallman to propogate the then-evil-and-proprietary Unix interface and bad for De Icaza to propogate the .NET interface?
I would like to further add that CIL (Common Intermediate Language) is one of the few aspects of the .NET ( and Borland C++ Build and Delphi) that I actually like. This simple idea could increase productivity exponentially on all projects, especially open source projects, if all compilers produced CIL code with meta data and packaged other programs to extract the needed informaiton to use the code segment/component in any particular langauge. For example, if Borland C++ build came with a program to generate the headers needed to use any CIL code produced by anybody.
The time wasted on learning new languages just to work with a given project would be removed. That time could then be refocused on newer sections of the code. Granted you would have to learn the a new language if you want to look at the actual code, but it wouldn't be necessary.
The strengths of various languages could easily be combined. You could write various code segments in the language tjat was best suited for the task, and then use that code in all the other languages you program in with very little effort and fuss.
This technology could be improved by adding a layer to compile the CIL code down to native machine code (even if the whole process ends up being CIL Compiler - Native Byte Code Compile - Linker - final native executable). Imagine being able to use portions of the KDE or GNome libraries interchangeably! You could utilize the work of both group and make interoperable components easier without worry about what language it was compiled in. The efforts of both groups could be combine easier and avoid the divided efforts that current exist.
In short this is one of the next step in Soft Engineering/Programming (along with Apest Orient Programming). This code help change the focus of programming/software engineer away from language specific programming to generic concept programming and thinking.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
Remember this?
How we know is more important than what we know.
Okay, I must admit I have lost all respect for GNOME/Ximian, now.
.NOT Framework, then it will be just as bulky and unreliable as windows programs.
Miguel has this "if you can't beat 'em, join 'em" attitude, which usually goes along with being a follower, not a leader. Some friends I have, who are also MS people, always jokingly say, "Don't fight it... don't fight it! Let Uncle Bill take care of you!". I really hate that way of thinking.
Open source is about pure innovation, and problem solving, not porting others' work over to the free world (necessarily).
The other beef I have is with his comments regarding productivity. He says he has reached a point where he has "implemented too many linked lists", etc etc. My problem is, a good programmer knows how to reuse his/her code, and not reimplement ALL of it from scratch every damn time. You know why Microsoft's code is so bulky and unreliable? It's because they made their API's so attractive to lazy programmers who "don't want to deal with all that hard stuff" by doing it all for them. You write a "hello world" program in windows, and you'll be lucky if it isn't under 200Kb, because the routines and libraries that actually got compiled in are the same ones MS Office uses.
If we ignore the small and tedious details to programming, and base GNOME on the
Good software is not made by people who want to "get it done quickly and efficiently", it's made by people who want to spend the time to do it right, and "get it to run quickly and make it efficient". It's only one way or the other... we can drag 'n drop our way to building an application, but it sure as hell won't be as fast/reliable/efficient/good as a program written in a text editor, compiled by hand, checked and rechecked.
What is it that Microsoft has said/done to create this impression?
As I recall there was an article on news.com that quoted the President of ECMA as saying there were not and could not be licensing fees for ECMA standards, while Microsoft seemed to be saying there were elsewhere in the article. I couldn't find that exact article, but this one seems to cover most of the issues. Note that WinForms is absolutely not part of the ECMA standard. Also note that in this article Microsoft says clearly that there may be license issues between their software (even the ECMA standard) and Free Software licenses.
One especially pertinent snippet from the article:
"Part of the ECMA (standardization process) provides a forum for us to license the intellectual property you will need to have to implement the standard," Goodhew [a Microsoft product manager] said. "It's up to the implementers to make sure whatever license they choose to use is compatible with the ECMA licensing terms."
I hope de Icaza has looked over the "ECMA licensing terms" very, very carefully. They don't cover the GUI functionality regardless.
299,792,458 m/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
What made you curious? As a Java developer, you'll be aware that there's nothing radically new in the Dotnet CLI or C# and you'll be highly sceptical about claims of portability between Dotnet and Mono, given the difficulties we have today with AWT, SWT, Swing, WebLogic vs. WebSphere etc.
It seems that you're most excited by the prospect of applying some pressure to Sun to open up its IPR. Well, I think there are many ways of doing that, most of which will not involve putting MS in the driving seat of Linux application development.
An ancient verse in Open SOurce Lore...
Gee, so I guess that makes Miguel de Icaza Celebrimor, building his own runtime based on secrets given to him by the Dark Lord of Redmond, disguised as Annatar, Lord of Gifts. Maybe RMS is Elrond, watchful and distrustful of this mysterious being bearing secrets...
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
O.k. here is a karma burn.
If this will be so simple in the future, then MS companies will really try to lure people of off linux, plus think of the Virus factor! Now you can infect two OS's for the price of one!
This SIG pulled due to lack of funding. (This damn war is costing too much!)