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...
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
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
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.
> 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.