Linked by Thom Holwerda on Wed 11th Jun 2008 08:14 UTC
The KDE project saw the writing on the wall. They saw that they had reached a certain limit when it came to what could be done with the KDE 3.x series - they named it the "big friggin' wall", and decided that in order to get over that wall, incremental updates wouldn't do - they needed massive changes, a big jump, and they went for it. It's been a rough road, but it seems as if KDE 4.1 is showing signs of the vision becoming a reality. And it now seems as if several people within the GNOME community are seeing the writing on the wall too: GNOME 2.x has reached its goal - now what?
Permalink for comment 318316
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Member since:
2005-07-06
No, it isn't. If it's never queried or accessed most of the time, it'll just be swapped away on the harddisk.
As for why gnome fails from a development point of view, well, it's built on gtk and glib, which are horrible c-based implementations of oo-programming and containers, using macros and all kind of other disgusting shit.
This is bound to make for some shaky, pointlessly complicated and difficult to maintain foundations.
Before some clown tells me that the end result is the same and that it's a matter of taste, it's not.
There's no notion of type safety in C, there's no notion of scoped resource allocation (which forces you to write redundant cleanup code for all exit path of your functions, which mean that you can get it wrong, omit stuff etc), and you essentially have to learn a bunch of gtk-specific idioms to accomplish things that can be expressed in a standardized way in other languages.
There no single good reason to do OO programming with a non-OO language in this day and age.
It's just unecessary complication, and unecessary complexity is the enemy of efficiency and ease of maintenance.
The "language bindings are easier to write for c" argument is quite bogus as well, as demonstrated by the amount of bindings existing for Qt and KDE.