Is GTK+ the real problem?(drfav.wordpress.com)
drfav.wordpress.com
Is GTK+ the real problem?
http://drfav.wordpress.com/2009/07/01/my-take-on-the-monoc-debate/
5 comments
If you haven't read TFA, let me suggest something before you do.
Don't.
This is the kind of post that is not up to this community's standards.
Don't.
This is the kind of post that is not up to this community's standards.
So of course, I went ahead and read it.
And you're right. It was a waste of time.
I don't code desktop software at this time, but as a user of desktop software I will always look for native programs first, i.e. for software written in the same ecosystem as the operating system. And only if its not available, I will accept Mono/JVM-based implementation.
The reason is simple: shared libraries. This is why Safari starts up so freakishly fast - because most of the runtime it uses has already been pre-loaded by other OSX apps written in Objectve-C. Even before I launch Safari most of it is already in memory.
This is also why Microsoft Office launches nearly instantly, which is really impressive, considering its size and complexity (compare that to JVM-based Eclipse).
.NET and especially JVM-based software share nothing. When they start, they need to load their own private copies of memory manager, JPEG decoding, ZIP compressing, console printing, file/network I/O and many other megabytes of stuff I already have in RAM, provided by the OS.
The solution IS NOT to keep coding in C family forever. The solution is to integrate a VM into an operating system (Symbolics). There is no reason to have more than one threading manager, garbage collector and JIT compiler loaded in a computer memory at any given time. Not only it will provide tremendous increase in programmers productivity, but it will also drastically simplify interprocess communication, increase availability and accessibility of libraries and save on RAM big time. Google's Android (seems like) is exactly that: custom JVM promoted to an OS status.
The reason is simple: shared libraries. This is why Safari starts up so freakishly fast - because most of the runtime it uses has already been pre-loaded by other OSX apps written in Objectve-C. Even before I launch Safari most of it is already in memory.
This is also why Microsoft Office launches nearly instantly, which is really impressive, considering its size and complexity (compare that to JVM-based Eclipse).
.NET and especially JVM-based software share nothing. When they start, they need to load their own private copies of memory manager, JPEG decoding, ZIP compressing, console printing, file/network I/O and many other megabytes of stuff I already have in RAM, provided by the OS.
The solution IS NOT to keep coding in C family forever. The solution is to integrate a VM into an operating system (Symbolics). There is no reason to have more than one threading manager, garbage collector and JIT compiler loaded in a computer memory at any given time. Not only it will provide tremendous increase in programmers productivity, but it will also drastically simplify interprocess communication, increase availability and accessibility of libraries and save on RAM big time. Google's Android (seems like) is exactly that: custom JVM promoted to an OS status.
No, GTK+ is not the "real problem."
GTK+ has a very fine C++ binding, gtkmm. It even has a pretty nice java binding: java-gnome. People just really, really like GTK#, the Mono/C#/CLR binding.
The author even cites gnote, a C++ GTK app that uses gtkmm, as an example. He completely lost me at that point.
Example of what? His overall hypothesis seems to have been that GTK+ is so bad, people are driven to very high level languages like C#, and gnote sorta flies in the face of that.
GTK+ has a very fine C++ binding, gtkmm. It even has a pretty nice java binding: java-gnome. People just really, really like GTK#, the Mono/C#/CLR binding.
The author even cites gnote, a C++ GTK app that uses gtkmm, as an example. He completely lost me at that point.
Example of what? His overall hypothesis seems to have been that GTK+ is so bad, people are driven to very high level languages like C#, and gnote sorta flies in the face of that.
I didn't know what gnote was, and when I was reading that I thought he was trying to say that it was a Mono/C# app. My impression of what he was saying -- which it turns out is probably way off -- was that Mono/C# in the hands of seasoned developers takes just as long to write code as bare c/c++ (much in the way that unseasoned developers thought php was 'easy' but they were writing fast code because they were leaving out things like checking for SQL injection/etc that a seasoned developer would be looking to prevent).
Since GNote is a C++ port of a Mono/C# app I don't know what he's trying to say.
Since GNote is a C++ port of a Mono/C# app I don't know what he's trying to say.
As I understand it, he's trying to say:
1. Developers who use C# or Java or other high-level languages aren't "real programmers" (who obviously revel in low-level guts).
2. The only reason anyone likes Mono is that GTK is a terrible, terrible toolkit and can only be made palatable by escaping into bindings from another language.
3. Qt and C++ are the greatest things ever, and he can't imagine anyone wanting to use anything else after encountering them.
1. Developers who use C# or Java or other high-level languages aren't "real programmers" (who obviously revel in low-level guts).
2. The only reason anyone likes Mono is that GTK is a terrible, terrible toolkit and can only be made palatable by escaping into bindings from another language.
3. Qt and C++ are the greatest things ever, and he can't imagine anyone wanting to use anything else after encountering them.
Article needs to be run through an editor at least twice. Flagged.
I think opinions like this are a significant impediment to the advancement of the programming profession in general. The entire point of using a computer is to automate difficult, repetitive problems. Resource management is a problem ideally suited for automation. There are literally dozens of working, proven, high-quality garbage collection and reference counting implementations, and deciding to re-use one is not a sign of weakness nor ignorance. If anything, I think true ignorance is beginning new projects in a legacy language such as C or C++. If more programmers wrote in high-level languages such as LISP, OCaml, Haskell, or even mid-level languages like C# or Java, program crashes and corruptions would be much rarer events.
I don’t want to spend more time talking about this: you can verify what I’m telling you is true by looking at the percentage of KDE code written in languages different from C++. And we have some great bindings.
Here's where the author lost me. The reason KDE applications favor C++ isn't due to any inherent benefits of using C++, it's because they are trapped and cannot escape! Qt has terrible bindings, in large part because C++ is so difficult to interact with. The only mature, widely used binding I'm aware of is to Python -- contrast this to Gtk+, which has bindings to nearly any popular language you can think of; C#, Java, Python, Perl, Ruby, D, LISP, Haskell, OCaml, (ry. And if you ask anybody that uses PyQt regularly, they'll tell you how "alien" it feels -- signals and slots are implemented by embedding C++ declarations into Python string literals!
So this is the point, on which you are free to flame me until death: the problem is GTK. Consider the amount of programs recently written in GTK. A huge percentage of them is in Python or Mono.
[...]
We have PyQt and Qyoto. Yet they are not so widespread and planetkde is filled with new C++/Qt apps. So where is the problem? Probably people are no longer comfortable in programming with GTK/C. I did it a while ago, and it was quite a pain to me actually, and it made me want to look into python, damn my laziness.
And here is the crux of it. In this paragraph, the author states that using C is difficult, and then blames himself! Is this Stockholm syndrome at work? I think the average HN reader would have been overjoyed at being able to use a high-level language instead of groveling through a morass of C/C++, but the author's sentence reads as if he wants to punish himself for infidelity!
Gentlemen, languages and libraries are not wives; they do not deserve loyalty. Do not be like this author, turning your back on advances in the craft due to a misplaced macho attitude or stubbornness.