Posted by
chrisd
on from the what's-a-nice-coder-like-you-doing-in-a-place-like-this dept.
twigman writes "MSDN has an interview with Ximian CTO Miguel de Icaza about Mono and past Ximian projects. It's a surprisingly objective discussion, definitely worth a read." Of course we're not surprised Miguel is objective...
Blah blah.. standard crap about reading your own site:)
No one was banned from DotGNU lists
by
bkuhn
·
· Score: 5, Informative
There is a factual error in the interview.
No one was banned from any DotGNU lists. A few times in the early days of the project, the lists were put into moderation mode when discussion got inappropriately heated or off topic. Martin claimed that having this moderation imposed constitued banning, but that simply isn't the case. It's unfortunate that Martin felt rejected by the need for moderation, but we didn't intend it as such.
I even personally had some of my posts rejected during one of the moderation periods.
Bradley M. Kuhn, member of the DotGNU Steering Committee
Ximian has been doing a good job balancing financial practicality with free software ideoligy. They make a GPL'd PIM (Evolution) and sell a proprietary interface to a proprietary server software. They have to make money, right? Exchange Connector only hurts the people who are already using Exchange.
The idea of using the.NET standard to create a robust component architecture is a pretty good idea. Microsoft is betting the farm on.NET. It is going to succeed. What is the harm in having a GPL implimentation of it? Even if it doesn't help *IX interoperate with the MS world, GNOME (and everybody in the GNU world) get a seemingly good technology. Morover, having Mono will allow the millions of.NET developers to make GPL stuff in the evenings without having to climb a steep learning curve.
We could have had a working Mono two years ago.
by
mj6798
·
· Score: 5, Insightful
I'm glad to see that there are open source projects based on a language and runtime that supports a component architecture and runtime safety from the ground up. I think a Linux desktop environment and services platform based on C#/CLR will be so much better, more efficient, and more robust than the current systems based on plain C or C++. This has long been overdue.
What I am disappointed about is that the Linux community could have started on this several years ago. While there are some cosmetic differences between C#/CLR and Java/JVM, the object models and performance of the two languages and runtimes are essentially the same. And there actually are already several open source, high performance Java implementations already.
Even today, I think it still makes more sense to use something like GNU gcj or Intel's Open Runtime and maybe the existing native Gnome widgets (for which there are already Java bindings). But Mono is obviously not going to go that route. Too bad.
Nice to see Brad Cox mentioned
by
LizardKing
·
· Score: 5, Interesting
I was pleased to see Brad Cox mentioned - the man who invented Objective C (the lesser known Object Oriented C derivative). His seminal book on Object Oriented Programming was the first thing I read on the subject, and although I was disappointed in one sense - I was expecting the equivalent of K&R for Objective C - it was a great read on why software hadn't advanced in the same leaps and bounds as hardware. The books goals (maximium code reuse through self contained components called software IC's) have still not been fully realised, but Java Beans and Bonobo components are definitely a step in the right direction.
Re:Miguel is the smart fellow
by
Metrol
·
· Score: 5, Insightful
KDE's DCOP and KParts are rather incomplete imitations of CORBA.
First off, I'm not a developer. At best I just read a fair amount about what folks are doing. One of the things I personally found interesting about this interview was Miguel listing problems with Bonobo and CORBA that sounded a LOT like the reasons KDE doesn't use those technologies. Essentially that bindings such as CORBA are like swatting a fly with a hammer for desktop apps, thus a simpler approach was taken with things like DCOP.
Again, I'm not in the trenches, but from an observers point of view it seems that Gnome is just needing that next set of bindings to be developed sometime later over and over again. Everything was going to be better with CORBA and Bonobo linking everything. Now that's all the wrong approach, and Mono is needed. I may be way of base here, it just seems like it's the "bindings to be developed" of the month club.
On the other hand, KDE made the call to move things to DCOP a while ago and they seem to be sticking to their guns on it. The developers are extending where needed, but leaving the core intact as it's doing what they intended from the onset. I honestly don't know if this is a good or bad thing in practice. It seems like a more reasoned approach, and it's certainly produced a wonderful desktop environment.
Early into next year both projects are looking to have major releases. I guess we'll see which approach provides the payoff of a more robust environment that developers prefer to work on.
-- The line must be drawn here. This far. No further.
Re:Miguel is the smart fellow
by
Anonymous Coward
·
· Score: 5, Interesting
> One of the things I personally found
> interesting about this interview was Miguel
> listing problems with Bonobo and CORBA that
> sounded a LOT like the reasons KDE doesn't use
> those technologies. Essentially that bindings
> such as CORBA are like swatting a fly with a
> hammer for desktop apps, thus a simpler
> approach was taken with things like DCOP.
Actually, he didn't say this. He said, "CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML parsing Bonobo/CORBA component would be inefficient compared to a C API."
Basically, CORBA is good enough for it's current use (GUI components and general application interfacing) but it's a bit heavy for simple things like a (high performance) XML parsing library. DCOP isn't any more efficient. It's likely less efficient since with DCOP there's a lot of serialization/deserialization to strings whereas that serialization doesn't take place if you're using Orbit (GNOME's CORBA) as an inproc procedure. Even when it happens, it's binary serialization/deserialization so it's likely more efficient.
> Again, I'm not in the trenches, but from an
> observers point of view it seems that Gnome is
> just needing that next set of bindings to be
> developed sometime later over and over again.
> Everything was going to be better with CORBA
> and Bonobo linking everything. Now that's all
> the wrong approach, and Mono is needed. I may
> be way of base here, it just seems like it's
> the "bindings to be developed" of the month club.
Again, no. Bonobo is still good and it solves problems that Mono doesn't. Bonobo interfaces are being added to Mono, just like Gtk+ bindings and gnomedb bindings.
One thing Mono has the power to do is unify GNOME and KDE. Mono is getting full GNOME bindings. From what I understand, there are KDE developers who are working on KDE bindings (including DCOP). Because of the way the C# component architecture works, you can use components with little knowledge on how they were actually built, so you can mix and match more easily. Once the work is done, you should be able to embed a KPart in a GNOME component that's embedded in a KDE component that's embedded in a WinForm component.
I don't know about you, but I think that it's cool enough to be woth pursuing.
Slashdot Mirror
Blah blah.. standard crap about reading your own site :)
There is a factual error in the interview.
No one was banned from any DotGNU lists. A few times in the early days of the project, the lists were put into moderation mode when discussion got inappropriately heated or off topic. Martin claimed that having this moderation imposed constitued banning, but that simply isn't the case. It's unfortunate that Martin felt rejected by the need for moderation, but we didn't intend it as such.
I even personally had some of my posts rejected during one of the moderation periods.
Bradley M. Kuhn, member of the DotGNU Steering Committee
Ximian has been doing a good job balancing financial practicality with free software ideoligy. They make a GPL'd PIM (Evolution) and sell a proprietary interface to a proprietary server software. They have to make money, right? Exchange Connector only hurts the people who are already using Exchange.
.NET standard to create a robust component architecture is a pretty good idea. Microsoft is betting the farm on .NET. It is going to succeed. What is the harm in having a GPL implimentation of it? Even if it doesn't help *IX interoperate with the MS world, GNOME (and everybody in the GNU world) get a seemingly good technology. Morover, having Mono will allow the millions of .NET developers to make GPL stuff in the evenings without having to climb a steep learning curve.
The idea of using the
What I am disappointed about is that the Linux community could have started on this several years ago. While there are some cosmetic differences between C#/CLR and Java/JVM, the object models and performance of the two languages and runtimes are essentially the same. And there actually are already several open source, high performance Java implementations already.
Even today, I think it still makes more sense to use something like GNU gcj or Intel's Open Runtime and maybe the existing native Gnome widgets (for which there are already Java bindings). But Mono is obviously not going to go that route. Too bad.
I was pleased to see Brad Cox mentioned - the man who invented Objective C (the lesser known Object Oriented C derivative). His seminal book on Object Oriented Programming was the first thing I read on the subject, and although I was disappointed in one sense - I was expecting the equivalent of K&R for Objective C - it was a great read on why software hadn't advanced in the same leaps and bounds as hardware. The books goals (maximium code reuse through self contained components called software IC's) have still not been fully realised, but Java Beans and Bonobo components are definitely a step in the right direction.
KDE's DCOP and KParts are rather incomplete imitations of CORBA.
First off, I'm not a developer. At best I just read a fair amount about what folks are doing. One of the things I personally found interesting about this interview was Miguel listing problems with Bonobo and CORBA that sounded a LOT like the reasons KDE doesn't use those technologies. Essentially that bindings such as CORBA are like swatting a fly with a hammer for desktop apps, thus a simpler approach was taken with things like DCOP.
Again, I'm not in the trenches, but from an observers point of view it seems that Gnome is just needing that next set of bindings to be developed sometime later over and over again. Everything was going to be better with CORBA and Bonobo linking everything. Now that's all the wrong approach, and Mono is needed. I may be way of base here, it just seems like it's the "bindings to be developed" of the month club.
On the other hand, KDE made the call to move things to DCOP a while ago and they seem to be sticking to their guns on it. The developers are extending where needed, but leaving the core intact as it's doing what they intended from the onset. I honestly don't know if this is a good or bad thing in practice. It seems like a more reasoned approach, and it's certainly produced a wonderful desktop environment.
Early into next year both projects are looking to have major releases. I guess we'll see which approach provides the payoff of a more robust environment that developers prefer to work on.
The line must be drawn here. This far. No further.
"An interview with Miguel de Icaza on MSDN?"
-- I thought --
"Hey, maybe they arent such a bad bunch after all..."
Then, I clicked on the link, and my netscape browser promptly crashed.
Given that Linux perceives Microsoft as Threat Number One (see most links here) one can't stop wonder what Ximians hidden agenda is.
:-)
> One of the things I personally found
> interesting about this interview was Miguel
> listing problems with Bonobo and CORBA that
> sounded a LOT like the reasons KDE doesn't use
> those technologies. Essentially that bindings
> such as CORBA are like swatting a fly with a
> hammer for desktop apps, thus a simpler
> approach was taken with things like DCOP.
Actually, he didn't say this. He said, "CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML parsing Bonobo/CORBA component would be inefficient compared to a C API."
Basically, CORBA is good enough for it's current use (GUI components and general application interfacing) but it's a bit heavy for simple things like a (high performance) XML parsing library. DCOP isn't any more efficient. It's likely less efficient since with DCOP there's a lot of serialization/deserialization to strings whereas that serialization doesn't take place if you're using Orbit (GNOME's CORBA) as an inproc procedure. Even when it happens, it's binary serialization/deserialization so it's likely more efficient.
> Again, I'm not in the trenches, but from an
> observers point of view it seems that Gnome is
> just needing that next set of bindings to be
> developed sometime later over and over again.
> Everything was going to be better with CORBA
> and Bonobo linking everything. Now that's all
> the wrong approach, and Mono is needed. I may
> be way of base here, it just seems like it's
> the "bindings to be developed" of the month club.
Again, no. Bonobo is still good and it solves problems that Mono doesn't. Bonobo interfaces are being added to Mono, just like Gtk+ bindings and gnomedb bindings.
One thing Mono has the power to do is unify GNOME and KDE. Mono is getting full GNOME bindings. From what I understand, there are KDE developers who are working on KDE bindings (including DCOP). Because of the way the C# component architecture works, you can use components with little knowledge on how they were actually built, so you can mix and match more easily. Once the work is done, you should be able to embed a KPart in a GNOME component that's embedded in a KDE component that's embedded in a WinForm component.
I don't know about you, but I think that it's cool enough to be woth pursuing.