Gnome, Mozilla and the Challenge of Longhorn

I've done c++ professionaly for the past 7 years. I still don't consider myself an expert just because I guess I don't really care about the language that much. It's not a bad language, but the problem is that it seems that it's very hard to get right. What I mean by that is unless your team has very stringent guidelines on how to use it you can wind up with a clusterfsck of bizarro object hierarchies and just plain miserable syntax. Generics are cool, but they are so freaking ugly in C++. If I was developing by myself I probably wouldn't be so bitter about C++, but man throw a few other people in the mix and things can get weird. I'm not saying that happens all the time, but that's just my experience.

C is so much simpler with basically just structs, macros, and functions that "to me" it just seems easier to look at other people's code and grok it in a minimum amount of time. I know that might sound weird, but that's just my opinion.

The KDE guys seemed to have gotten their framekwork right. The internal code is ugly as sin, but from the app developer perspective it seems to be pretty nice. I have a problem with the QT license so any kind of QT development(unless funded by someone else) is basically out of the question for me. But all in all, I'd have to say that the KDE framework is just a lot better than the Gnome framework. I'm not knocking anybody's work, it's just the way I feel.

Now developing core Gnome libs in C seems reasonable to me. It's what the developers are comfortable with, it's a bit more portable, and it doesn't have binding problems that c++ does. In C# I can just pinvoke a call from a c shared library and be done with it. In C++, I'd probably have to write a wrapper library.

I think what Havoc and Miguel and others are trying to point out is that if you really want to leapfrog KDE or just get Gnome development on the fast track it just makes sense to up the ante on development by going to something like C# or Java with rich class libraries, a managed enviroment, not many memory problems...

To me, C++ just doesn't raise the abstraction bar enough. It's just too quirky, ugly, too many gotchas. Personally, I would vote for Mono because it seems that ecmca 335 and 336 core seem to be pretty clear legally speaking, but java would be fine too. If you really want to get into some kind of component-oriented development, then c#/Mono seems like the logical choice. Kparts is powerful stuff and I just don't know if Bonobo ever was really that attractive to developers. I've never used it, but it seems that a lot of people think its a pain.

I think the real thing here is that we want to move to more of component type programming. Stringing interesting and useful objects together with a minimum of hassle. I think C# and mono gives you that.