Posted by
michael
on from the pipe-dream-or-visionary dept.
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.
Alan Cox Says It Best
by
Gryphon
·
· Score: 5, Interesting
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)
I hate to be a dick, but.
by
sinserve
·
· Score: 5, Interesting
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.
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 or anyGui 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 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 is naive
by
pubjames
·
· Score: 5, Interesting
Miguel's arguments sound all well and good, but I think he is fundamentally naive about Microsoft.
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.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.
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.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...
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.
Re:Great reply, but...
by
Glock27
·
· Score: 5, Interesting
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!
-- Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Not-so-rapid application development
by
nadador
·
· Score: 5, Interesting
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.
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.
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.
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.