I just read this. It's a note from Havoc Pennington who happens to be some muckety muck in the GNOME world.

This is the death knell for desktop linux as a first class citizen in the world. While people bitch and complain, debate about this or that, wrap their morality around the discussion and so forth, MSFT will be delivering solutions that work (please, no trolls about their stuff only sorta works). The MSFT stuff will be coherent, it will solve real problems and it will be moving things forward.

See here's where MSFT always, always wins. There are bunches of options. They (Bill, Steve, whoever) sit in a room and debate for awhile. Others in the company join in, voicing opinions and so forth. Eventually Bill says, "This way". And that's it. Everyone at MSFT goes that way or they leave. Nobody is going to fork Windows. And so they make progress on the path they set out on. What MSFT has, that a "community" (gack. stupid term) doesn't is not a top down dictatorial structure. It's single mindedness.

The GNOME guys, in this case, need to sit down and simply say "we're going this way". If the code forks fine. If some people jump off the wagon fine. If GNOME fails, fine. Because the goal is not to get a lot of people using an average solution. The goal has to be an excellent solution drawing a lot of people. If the direction they choose leads to solutions that are better than others, people will use it. There is room for a dominant player in the open source world. In fact it's probably required.

But they won't. Nobody is going to say "Damnit, it's Java. And we're going to put a lot of effort into GNU Classpath". It'll be like the Unix vendors of the 80s trying to realize the binary compatability interface or some commonality amongst their offerings. Never happened. Never happen. And so they died. Watch this whole thing closely if you have the stomach for it. Absent something seriously changing you will have no finer proof of the adage that history repeats itself.

Is this not the beginning of a discussion like the one that occurs within Microsoft that you describe? I think there are some things to disagree with in the essay that you link to, but before a decision can be made, arguments for all sides need to be heard. In the open source world, these discussions are always going to be slower and more sprawling than they are inside a single company, especially on projects that aren't run by a benevolent dictator.

If I were a decision maker at Sun, this discussion would be very much of interest to me. Sun needs to weigh the costs of open sourcing Java against the advantages of taking a much larger chunk of the development that's going on in the open source world right now.

I think you might be a tad too pessimistic. You are certainly not wrong to be, given the track record of design by commitee style systems in the past. But we mustn't forget that we're talking about open source (or free) software here, so the comparison to Unix in the 80's should only go so far. Compatibily and interoperability can be maintained even if there's indeed a forking of the GNOME code base. In any event, a fork seems highly unlikely. The high profile splits in the free software community have almost always been caused by licensing issues, not technical ones.

As for the single mindedness or efficiency of MSFT, I don't think it's as great as we imagine. Bill and Steven almost certainly do not get involved in low level technical discussions, and you can bet there was a lot of such discussions before they committed to .NET, C#, or XAML. The difference here is that we (independent developers) are simply informed of their decisions after the fact. From that perspective, everything looks remarkable coherent and easy simply because we are not privy to the gory details. Whereas Havoc's discussion is for all the world to see and chime in. The discussion might be in the open but I think only the voices of active GNOME developers will carry much weight. This is really no different than the dozens of such discussion that take place every month on the Linux kernel mailing list, for example.

When the GNOME developers make a decision, and I think they will relatively quickly, I think we will see them be as committed and single minded as anyone in Redmond. So do not despair.

If you're looking for a coherent linux desktop, I strongly recommend you try KDE. They long ago decided to use Qt, C++, and write as much common infrastructure for use by allapplications as possible, and they've stuck to their guns.

They already use a higher level language (C++), and an excellent UI toolkit (Qt). It's somewhat ironic that the competing (C based) GNOME project is now having a language crisis. GNOME always made a big deal of the fact that they supported many languages.

While KDE provides several language bindings as well (notably Python), the choice of C++ probably deserves much of the credit for KDE's success. GNOME was started about a year after KDE, but they never could catch up, despite extensive financial and public relations support from Red Hat.

C++ is anything but a high level language. In 14 years as a developer - 4 as a C++ hotshot (now retired), I've met exactly 3 competent C++ developers that didn't do stupid things like memcpy C++ objects and forget to declare destructors in base classes virtual (leading to all sorts of freaky and hard to find bugs).

Apart from that, the C++ runtime models vary from compiler to compiler (OK - so we standardize on gcc) and doing dynamic binding and interactive GUI development with a statically bound language is virtually impossible. From a UI developer's perspective, C++ is about the worst language you could choose if you want a lot of people building applications.

C++ has its place - but its down doing OS level stuff - not for application development.

What is perhaps even more annoying is that there are better options not even mentioned. One need only spend a bit of time building applications for Mac OS X (you know - the "other" laptop unix) to realize that they've really got something with that ObjectiveC dynamic binding runtime. This is undoubtedly why a tiny niche platform has so many high quality applications available.

Linux could have the same thing - the GnuStep project has been chugging along for some time and could use some help. It even has garbage collection.

Bottom line is that GUI application development benefits tremendously from more dynamic, less rigorous development environments (Swing development - with the overly strict typing of the Java language - remains tedious and the results are uniformly disappointing in both responsiveness and development speed). That's what the Linux community should be looking for.

> > They already use a higher level language (C++)> > C++ is anything but a high level language. In 14 years > as a developer - 4 as a C++ hotshot (now retired), I've> met exactly 3 competent C++ developers that didn't do> stupid things like memcpy C++ objects and forget to> declare destructors in base classes virtual (leading to> all sorts of freaky and hard to find bugs).

I've met a lot of poor C++ programmers too. They don'twrite code in their spare time for KDE, though. I thinkKDE programmers also benefit from code review and thecompleteness of the QT api.

I would suggest that C++ is both a high(er than C) levellanguage and a low (as C) language.

> Apart from that, the C++ runtime models vary from > compiler to compiler (OK - so we standardize on gcc) and> doing dynamic binding and interactive GUI development > with a statically bound language is virtually impossible.> From a UI developer's perspective, C++ is about the worst> language you could choose if you want a lot of people> building applications.

How do you explain the success of KDE then? And the factthat most commercial gui apps are written in C++ as well?

> C++ has its place - but its down doing OS level stuff -> not for application development.> > What is perhaps even more annoying is that there are> better options not even mentioned. One need only spend a> bit of time building applications for Mac OS X (you know -> the "other" laptop unix) to realize that they've really> got something with that ObjectiveC dynamic binding> runtime. This is undoubtedly why a tiny niche platform> has so many high quality applications available.

Yet Apple themselves chose the C++ KDE html renderer as thebasis for their Safari browser, and used the KDE javascriptengine to boot...

I simply reject the whole "Linux Desktop has a language crisis"presumption of the original article, and offer KDE as evidence.

Gnome did something towards getting it to work, but it's only barely less creaky and cumbersome than is plain old X or KDE (did I mention performance?).

The failure of the Linux "community" (really more a loose gaggle of Microsoft-haters if you listen to them rant than a true community held together by any positive idea) to think outside the box of needing to lock users into something of their choice (rather than something of the choice of someone else) and to immediately discard any idea presented by anyone else as being valid will lead (has led?) to their demise.

I can happily use .NET on Windows, but I can just as easily use any other technology.Noone tells me I have to use MFC to create my applications, or VB. I'm currently working with Java, Python and dabbling with Ruby. I haven't touched a Microsoft development tool in years (not because I don't like Microsoft, but because I don't like their development tools) yet I've created applications that are tailor made for Windows and operate on it flawlessly.

Instead of constantly fighting among each other whose favourite tool/language/platform is best, maybe the Linux people should start cooperating in creating an environment in which I can use pretty much what I want without having to think inside some little box...

Oh no, I'd better install Windows right away! As someone who's used KDE almost exclusively for about the last 5 years I have to say that I couldn't be more pleased with it. The last few releases have seen great improvements in ease of use (IMO).

> I've met a lot of poor C++ programmers too. They don't> write code in their spare time for KDE, though.

Write code *for* KDE? Or build apps on top of it?

> I think> KDE programmers also benefit from code review and the> completeness of the QT api.

I'm not commenting on the implementation of KDE. But I don't think people writing desktop apps are necessarily getting any code reviews from the KDE team.

> > From a UI developer's perspective, C++ is about the> worst> > language you could choose if you want a lot of people> > building applications.> > How do you explain the success of KDE then?

I don't call it successful at all. Apparently, neither does the author of the article that kicked off this thread.

> And the fact> that most commercial gui apps are written in C++ as well?

Because the api to windows is C++. What of it? Put a large enough honey pot on the moon and people will build rocket ships. I don't think the pot is big enough in the linux world to justify the investment yet. That's the point. You can either have market dominance and attract developers based on perceived ROI. Or you can be "not microsoft" and lower the price of entry.

KDE maintains the high cost of entry (C++) without the liklihood of monster payoff.

Yet the UI is done using Cocoa. You cited two low level components. I note that the components were first wrapped with Objective C interfaces, then built into a Cocoa application (and also made available for other applications to use as the WebKit framework).

Applications are seldom about writing low level components, they are about orchestrating the interaction of the components. For that, dynamic runtimes are the way to go.

> > > From a UI developer's perspective, C++ is about the> > worst> > > language you could choose if you want a lot of people> > > building applications.> > > > How do you explain the success of KDE then? > > I don't call it successful at all. Apparently, neither> does the author of the article that kicked off this> thread.

Well the author (Havoc Pennington) of the original article is a leader in the GNOME project, which is famous for ignoring the existence of KDE and pretending GNOME == "The Linux Desktop."

GNOME chose to base their development framework on C, and now they are having a language crisis. KDE chose C++/QT, and they are doing just fine.

The original article also presents "C/C++" as a single language. Obviously it is not.

> Applications are seldom about writing low level> components, they are about orchestrating the interaction> of the components. For that, dynamic runtimes are the way> to go.

Perhaps so. But Python bindings have existed for KDE for quite a while, and I have been surprised at the low percentage of developers who choose to use them (and I am a big fan of Python).

> >>use a higher level language (C++)> Did you read the original post ?> > Moving away from C++ to a high level vm based env was the> whole point!

What I was trying to explain is that the group of developers who want to move to a high level vm are the ones who are now using C. The ones who are now using C++/QT are perfectly happy with their platform.

This is the death knell for desktop linux as a first class citizen in the world.

I have no idea how you came to that conclusion from reading Havoc's post. Havoc seems to be looking at .NET's progress (or hyped progress) and wondering how the open source world should answer .NET.

He's basically saying that C and C++ are no longer 'da bomb'. Higherlevel languages exist which can provide much greater productivity and he wants to start moving in that direction. He lays out the options (with pros & cons) and seems to propose the start of a dialog. He also seems to favor some sort of open sourced Java for this purpose. Personally, I don't think that Java is highlevel enough - the only real advantage it offers over C++ (IMHO) is automatic garbage collection.

Personally, I think he should give more consideration to Parrot for these purposes. If Parrot succeeds (yes, it's still a big if) it promises seamless integration between the open source languages. I do not agree with his assesment that Ruby & Python aren't up to the task of developing the types of apps he's talking about (notice that I left Perl out of the list). Both languages (and you could add a few others like SmallTalk and, to some extent, Objective C*) offer significant advantages over Java (greater productivity due to dynamicity).

*Speaking of Objective C - look what Apple is able to do with Objective C and the Cocoa framework. I've been doing a bit of GUI programming in that environment lately and I must say that I like it a lot. However, I _would_ like to see Obj C get exceptions and it would also be nice if it had some sort of automatic garbage collection built into it's runtime. The addition of those two things could really make Objective C a contender. Perhaps if more effort were put into Objective C improvements (with Apple's support, of course) and OpenStep (the open source equivilent of Cocoa) it might offer another way to get to the nirvana that Havoc is looking for. This would essentially be the "join forces with Apple" option. It could allow you to move GUI code between a Mac and a Linux/*BSD box without having to change it.