try to get an average-skill C++ developer up to speed on a project that's been under development for a year or so, and you'll be spending months explaining why you used the language the way you did
Too often true in practice, not true with Qt/KDE.
You know, that language that Linux, X, GCC, BSD, Apache, Bind, Sendmail and most of the rest of the civilized world's software is written in.
As I said, you should go out more often. There's a whole universe outside of the tiny rosy world of free software.
If you want to use a C library from C++ you can.
But it's highly suboptimal. Frankly it generally sucks big time.
The matrix is a little hard to read because there are so many languages in it....
And how many are complete enough to actually be used to develop a big application right away ?
The conclusion of my experience of 3 years helping to maintain Gtk-- and trying to develop with it, followed by 1 year of programming with Qt professionnally and with Qt/KDE at home is that Qt/KDE is, without a doubt a vastly better and more productive development platform than Gnome is at this time.
The language bindings point is totally moot, and after all these years and so few mainstream Gnome applications written in anything else than C, may be people should re-evaluate it. I wrote about it two years ago already, and as far as I can see most of my claims are still true.
When I started using Qt at work, I found myself to be more proficient with it after just a few days than I ever was with GTK+ or even Gtk--, where I constantly had to lookup either in some barely existant documentation or at the source code itself, or needed to add yet-another-wrapper for some strange struct I'd need.
A direct consequence of this is that whenever I wanted to write a patch for a KDE app, even fairly large and old ones (konsole, kmail), I could get a moderately complex feature done in just a few hours, over code I had never seen before.
Contrary to what you think, the level of entry of KDE for a programmer is way lower than for Gnome. Even a C++ beginner can produce useful code after just a few days of learning. This is not true for all C++ toolkits or projects, but it is true for Qt and KDE.
This is the reason why KDE's development pace is so quick, and why so many high-level applications like konqueror, kdevelop, or koffice could be written by teams of less than half a dozen people. Programming under KDE is just so easy.
I suggest you try it. You'll be surprised, as I was too when I switched.
Yes, I realize that KDE 2.0 has KParts, but bonobo is already here, and it works now.
KParts is also already here, it also works now:-)
And so is DCOP.
Why don't you simply go to TrollTech's web site and check before posting an idiocy ?
Qt is free for X11. In practice it means it's free for every Unix it runs on.
It seems that the overall trend in the evolution of programming languages is to look at the usage patterns and idioms of the previously existing ones, and implement these (thus standardizing them) in a new more abstract language. Or, in short, putting keywords on concepts (for instance, a C++ pure virtual class is now an 'interface' in Java).
However, this is done in detriment of finer grained control, and forcing things into abstractions in which they don't belong. Not every inheritance tree can be reduced to single inheritance and interfaces (you sometimes need multiple inheritance), not everything has to be a class (you sometimes need functions and basic types), not every flow can be modeled with if() and while() (you sometimes need goto), etc...
As such, you can find yourself writing very ugly code into a normally "clean" language just because reality says otherwise.
On the other hand, C++ tried to cover a very large area in that regard, but that is often what people don't like in it : too many features, or, too much freedom.
As the level of abstraction in programming language goes higher, both problems can only get worse. So I have a two questions :
what do you think will be the next level of abstraction in programming ? J. Coplien hints toward pattern programming, will the next generation of programming languages have keywords out of the "Design Patterns" book, like 'singleton', or 'proxy' ?
how would you manage the problem of emcompassing even more programing paradigms ? Should new languages "move up" and forget functions for instance (after all we've already moved away from assembly), or do you think it will always be possible to have most (if not all) programming paradigms available in one language ?
Slashdot Mirror
> They don't.
They sure do. The sorry state of g++ is one reason but not the only.
> It's a critical strength. The GTK+ object model is much more flexible and general than the C++ model.
Not really. It also has a far bigger overhead, and is much more complicated to use.
> The C stuff is infrastructure that most app developers rarely need to touch.
You need to touch it every time you want to do something as trivial as creating your own class or deriving an existing one.
Qt has only one major problem: it's written in C++.
This is actually Qt's greatest asset.
But that one's a problem from which I have never seen a toolkit recover without the marketing dominance of Microsoft.
You should go out more often : RogueWave
Ilog
try to get an average-skill C++ developer up to speed on a project that's been under development for a year or so, and you'll be spending months explaining why you used the language the way you did
Too often true in practice, not true with Qt/KDE.
You know, that language that Linux, X, GCC, BSD, Apache, Bind, Sendmail and most of the rest of the civilized world's software is written in.
As I said, you should go out more often. There's a whole universe outside of the tiny rosy world of free software.
If you want to use a C library from C++ you can.
But it's highly suboptimal. Frankly it generally sucks big time.
The matrix is a little hard to read because there are so many languages in it....
And how many are complete enough to actually be used to develop a big application right away ?
The conclusion of my experience of 3 years helping to maintain Gtk-- and trying to develop with it, followed by 1 year of programming with Qt professionnally and with Qt/KDE at home is that Qt/KDE is, without a doubt a vastly better and more productive development platform than Gnome is at this time.
The language bindings point is totally moot, and after all these years and so few mainstream Gnome applications written in anything else than C, may be people should re-evaluate it. I wrote about it two years ago already, and as far as I can see most of my claims are still true.
When I started using Qt at work, I found myself to be more proficient with it after just a few days than I ever was with GTK+ or even Gtk--, where I constantly had to lookup either in some barely existant documentation or at the source code itself, or needed to add yet-another-wrapper for some strange struct I'd need.
A direct consequence of this is that whenever I wanted to write a patch for a KDE app, even fairly large and old ones (konsole, kmail), I could get a moderately complex feature done in just a few hours, over code I had never seen before.
Contrary to what you think, the level of entry of KDE for a programmer is way lower than for Gnome. Even a C++ beginner can produce useful code after just a few days of learning. This is not true for all C++ toolkits or projects, but it is true for Qt and KDE.
This is the reason why KDE's development pace is so quick, and why so many high-level applications like konqueror, kdevelop, or koffice could be written by teams of less than half a dozen people. Programming under KDE is just so easy.
I suggest you try it. You'll be surprised, as I was too when I switched.
This is false. I'm running the current Beta on both my home and work machines and it's very stable.
It's shaping up, but the underlying architecture will continue to be changed right up to the date of the final release.
They are in feature freeze. The underlying architecture won't change and it hasn't for months.
There are many problems with the current implementation. Read the Kde developer lists.
I do, I see no evidence of what you say.
Yes, I realize that KDE 2.0 has KParts, but bonobo is already here, and it works now. :-)
And so is DCOP.
KParts is also already here, it also works now
Why don't you simply go to TrollTech's web site and check before posting an idiocy ? Qt is free for X11. In practice it means it's free for every Unix it runs on.
It seems that the overall trend in the evolution of programming languages is to look at the usage patterns and idioms of the previously existing ones, and implement these (thus standardizing them) in a new more abstract language. Or, in short, putting keywords on concepts (for instance, a C++ pure virtual class is now an 'interface' in Java).
However, this is done in detriment of finer grained control, and forcing things into abstractions in which they don't belong. Not every inheritance tree can be reduced to single inheritance and interfaces (you sometimes need multiple inheritance), not everything has to be a class (you sometimes need functions and basic types), not every flow can be modeled with if() and while() (you sometimes need goto), etc...
As such, you can find yourself writing very ugly code into a normally "clean" language just because reality says otherwise.
On the other hand, C++ tried to cover a very large area in that regard, but that is often what people don't like in it : too many features, or, too much freedom.
As the level of abstraction in programming language goes higher, both problems can only get worse. So I have a two questions :