OO vs. PP (KDE vs. Gnome)

In the flame war between Gnome and KDE, the leading desktop environments for Linux, I’ve always been on the side of KDE. As you may recall, KDE was first: based on the QT libraries from Norway’s Trolltech (now part of Nokia), KDE was the first real desktop environment for Linux. Then a Stallman-esque backlash at the licensing of QT generated a group that wanted a fully open-source product, and out of GIMP (the Gnu Image Manipulation Program) came Gnome.

I confess Richard Stallman, for all the good he’s done, has been going on my nerves for quite a while. The messianic attitude, the holier-than-though accusations of abandoning the free software movement to everybody that disagrees with him on pretty much anything… We didn’t really need that. In truth, though, Gnome did force an opening up of the QT libraries (now available open source). Of course, the Gnome project did not die just because its fundamental reason for existence was gone. And, really, nobody cares at this point. The only difference between a pure Gnome or pure KDE environment and a mixed one is the libraries and a few integration points.

Gnome has in time developed a serious following, especially amongst the philosophical crowd. Ubuntu and Fedora, for instance, rely on Gnome for their default environment. SuSE, once a strong KDE proponent, has moved towards Gnome lately as a result of being acquired by Novell (who owns also Gnome powerhouse Ximian).

Now, most people that move to Linux seem to prefer KDE. Why is that? Well, mostly because it looks and feels a lot more like Windows, which is from where most people get to Linux. That’s anecdotal, of course, but quite consistent. It is therefore a little surprising that many Linux distributions still default to Gnome, well knowing they would be much better off to default to KDE and let the advanced users decide they prefer Gnome. That it’s not happening is probably a result of peer pressure and Geek Superiority Syndrome, the attitude according to which it’s perfectly fine to ignore reality for the sake of a hypothetical argument.

[As a brief aside, that same GSS came to the fore when I first ran Tcl on a FreeBSD machine while I was at Yahoo!. I got the code installed, but when I tried to run tclsh, FreeBSD told me I had to specify a version, as in tclsh8.4, because there were compatibility issues. That’s of course complete BS, since no other interpreter (python, perl, ruby, etc.) was subject to the same treatment – while all of them have the same version compatibiltiy issues. I guess Tcl was not cool enough for the FredBSD crowd.]

KDE looks and feels more like Windows (or MacOS) than Gnome for one simple reason: things are a lot more consistent. Gnome is happy about freedom, it promotes freedom, it guarantees freedom. And it forgets that it’s talking about the freedom of developers, regardless of user preferences.

It so happens that every application under Gnome can have different dialogs to do pretty much the same thing. The open file dialog in GIMP may not be the same as in GNUPlot, and there might very well be an outstandingly good reason for that. But what seems an important point to the developer ends up being a real nuisance to the user, who has to familiarize herself with lots of different dialogs, and has to wait for all implementers to update as soon as a new feature is out.

KDE apps tend to like using the same dialogs. Bookmarks, for instance, are the same across all applications – which can be a nuisance when you are sharing bookmarks between your browser and your image sorting app, but at least you get the same functionality all over.

I guess there must be an outstanding reason why, despite all the push from the top, the bottom is still far more interested in KDE. Despite the fact that Gnome is a real word, while KDE is not, the former lands you about 35 million hits, while the latter gets almost 80 million in a googlefight.

Regardless, KDE can be enormously frustrating. Oddly enough, its being frustrating is tied to its advantage over Gnome, which is its object-orientation. KDE is entirely built in C++, while Gnome’s foundation library (GTK) is written in C. The notion of object orientation gives KDE a naturally class-oriented view of things, which “enforces” consistency by virtue of paradigm.

What’s not working about this approach is what’s not working about all object oriented paradigms: they reflect a state of mind that is not that of a typical human.

I noticed it with a great many applications, and the reactions of humans to them. Typically, a human wants to accomplish something with a program. You would sit in front of an app and try to perform a task, say write an email. When you do that, you need two things:

1. a meaningful representation of the objects you need to accomplish the task
2. a meaningful representation of the process itself

Procedural systems, like Gnome or most apps written before 1980, do a good job at (2): the model what you need to do fairly well. They fail miserably, though, when you want to do things you think of as “similar” but are not available – they typically need to be implemented from scratch.

Object oriented systems, like KDE or most Java apps, do a good job at (1): they provide a series of metaphors for the things you know, and then present them to you for manipulation. Typically, they make it a lot more complicated to get your task handled, as if it was below the developers to implement your special cases.

The motto of the first class of programs seems to be, “you can do exactly what you asked me for (but not more)”. The motto of the second seems to be, “there is always a way to do what you want to do (but it could get really complicated).”

Failing to understand that a real program needs to do BOTH things is what makes a lot of programs unusable. Finding a program that does both makes users extremely happy.

You want two examples? Here you go:

1. BlackBerry: if you owned a BB in the early years of the Millennium, you were one of the happiest geeks around. That thing always knew what you wanted to do next. You just got an email in your inbox (click on the wheel) you read it (click on the wheel) you replied (click on the wheel) you sent it. It just knew what was next, and it would do the next thing magically for you if you just clicked the wheel. You could navigate manually, of course, but you didn’t need to. That thing saved a lot of time, a lot of grief, and a lot of car accidents.
2. iPod: when the original iPod came out in 2001, it was just one of hundreds of MP3 players. For the first time, though, there was an MP3 player that could be easily “charged” with music. You could easily download music onto it, you could easily navigate through your collection, you could easily … do anything! It was a life saver! No more finding of stores that sold MP3 files, no more finding MP3 files on your hard drive, no more using weird proprietary applications to download your music to your MP3 player. It just worked.

Of course, colleges teach procedural programming first, then follow up with object oriented programming. These two are presented in an evolutionary chain, and OO is the end of the development.

Unfortunately, this is quite not right: OO and PP are not meant to be foes, but to be used in conjunction with one another, as they have complementary functions in a program.

OO helps developers finding and defining common behaviors. It helps developers focus on what’s related and what’s not. Inheritance and derivation help a ton in abstracting functionality and clarifying the abstractions necessary to the procedures. For instance, you can read a spreadsheet and a presentation because they are both documents, but you cannot read a folder, because it isn’t. Folders and documents, though, are both files, and hence they both have time stamps.

PP helps developers connecting with the user, finding the tasks that are most common and streamlining the process of accomplishing them. Procedural thinking is so ingrained in humans that I don’t even have to find examples of how it benefits programmers and users alike: it’s how we think!

In an OO program, you can do whatever you want, since you can manipulate the objects (the abstractions). You cannot do that in a PP application, because there are no common abstractions, and you can only do what the developer thought of.

The fusion of both is, though, what users really want: an application that can do everything that I can think of, but that focuses all the time on the things that I’d be most likely to want to do.

As they say: a program is well-designed if simple tasks are easy, and complex ones are possible.

I, for one, am cheering the advent of OOPP, object-oriented procedural programming.