Why are we using C again?

It has been a while already since I last ranted about the main programming language used for Gnome. Mostly because you are not forced to use it and so I did not. But recently there were some posts on Planet Gnome which reminded me how inherently broken the core of Gnome is. I mean we have all this nice libraries like GTK, Glib etc. and they are easy to use and generally well designed, but when you want to hack on the core of them you have to use C.

I understand that back then when the Gnome project started C++ was in a very high flux with uncertain design bad compilers and so Gnome was written in C instead.

But looking at C++ today especially at the modernizations coming with C++0x (which are mostly already available in gcc4.4 btw.) it is really hard to understand why C is still used.

Just look at the linked examples; since C does not provide any build-in concept of iterators and the language is not flexible enough to provide them as library even experienced Glib developers iterate over lists in O(2^n) instead in O(n). How braindead is that? Instead of re-using the object concept and the syntactic sugar provided by C++ we are re-inventing the wheel with Glib. Luckily the community lately noticed that the syntax using Glib is so fucked up so you are not being productive any more. And what was decided as a solution? Reinvent the compiler by writing Vala – WTF?? There is already a compiled language which is compatible with our old code and which looks almost identical to vala; C++.

And I am not the only one who thinks that C++ is generally preferable over C. Here is a presentation discussing writing GCC in C++ which eventually happened. And these people are writing compilers so they should know if the language switch is worth it…

I thought the great thing about OSS is that you dont have to reinvent the wheel, but simply can use the well tested ones. Sometimes I really question the sanity of the Gnome developers…

13 thoughts on “Why are we using C again?”

  1. I assume, and I’m not a dev; this is speculation, it’s because that is what all the existing code is written in, so porting it would be a right pain…

  2. Since I’m in the mood: C++ is crap, too. Modern compilers still take ages to compile code, you need to add empty copy constructors everywhere to make sure idiots don’t accidentally copy shit around, stuff like that.

    If there actually was a language that were better than C, we’d be using it by now. But there isn’t. Certainly not C++.

  3. “even experienced Glib developers iterate over lists in O(2^n) instead in O(n).”

    Come on, be serious. No experienced dev would write that piece of crap. And C++ also has its pitfalls… C isn’t perfect, but no language is. Sure, I agree for real OOP that GObject boilerplate code is a bit harsh, but the example you’re pointing at is about GLib, where there is no inheritance involved. Furthermore, rewriting the whole codebase would take ages, for a very uncertain benefit.

  4. @otte
    well I do not say that C++ is the perfect language – by far not. But I think it has enough to offer over C in order to justify using it.
    I also used to think that C++ is crap until I found out that you actually can write as compact code as in python with it. (modulo braces)
    You really should take a look at C++0x – it allows writing much cleaner programs and standardises some useful libraries like garbage collection or function objects.

  5. @liberforce
    the nice thing about C++ compilers is that they also compile C code. So basically all we would need to do is switching the compiler and start using C++ features for new code as appropriate – similar to what the gcc people did.

  6. Hi there… maybe you guys would be interested to take a look at eC …
    It takes somewhat of a different attempt at making C object oriented, not taking anything away from it, yet adding some nice useful features.

  7. While I agree that C++ is a huge improvement over C, I also think that both are really obsolete. Yes, C/C++ will be used for a long time for low level stuff, but for application programming we can do much better.

    The pressure from Mono will keep increasing simply because you are way more productive in that language.

    I really think Gnome should look closely at Java, more precisely at the JVM. Yes, originally it was mainly optimized for servers, but that has changed. With good bindings for Java (for the GTK, Glib, …), and using a language like Scala or JavaFX Gnome would benefit a lot.

    But then again, it is enough to mention Java and Linux people will start screaming at you.

  8. I find that Vala is quite different than C++, and I like it more. I doubt you did anything extensive with it.

  9. You need to really look at Vala. It would be great to see all Gnome applications that are currently written in C re-implemented in Vala.

  10. Coming from C++ as my first programming language, reading through large programs in C they always seem awkward to me. But I can imagine that’s the other way around for veteran C-programmers… I guess this will always make the whole language discussion thing a pain. Knowing how to read C/C++ and how to really use it are different things.

    So somehow I guess the only way to convince the other camp is to create compatible implementations in whatever preferred language of some parts of the libraries… that way people cannot deny the benefits?

  11. I’m going to be very unpopular very soon, but there’s been a painful trend for a very long time that I really need to complain about, and this seems to be the best place to do it.

    In order to avoid “reinventing the wheel”, before there were computers we turned to something called “library science”.

    After computers came around, we came up with the term “object oriented programming”. Originally, once upon a time, this meant that various parts of our code would work like organs inside an organism or parts in a car and could be swapped out. The problem was, our object orientation features in various languages weren’t compatible. So we reinvented the wheel in order to avoid reinventing the wheel, and we came up with design patterns and virtualization. Soon every language started needing to support these features, with some languages being scoffed at (I’m looking at you, php) because despite being great at whatever purpose they were actually designed for they couldn’t keep up with the newest incarnation of OO. How do we solve this problem? Clearly we need to reinvent the wheel again and come up with new across the board coding standards that work in whatever language you need! It’s XML and CORBA and .NET and on and on to the rescue! Except, of course, our new incarnation of OO, itself, needs to be learned and relearned, which means there are people that aren’t going to use it, which is going to cause-

    You know why I like C? It works anywhere. It’s layered on top of assembler. Which is layered on top of machine code. Which means no matter what revolutionary brilliant game changing web 9.0 solution we all have to instantly learn well enough to preach and dissiminate that will solve every software engineering and communications problem ever, causing us to relearn every single language because they’re all glued together now in the same project and my JAVA is talking to my PHP and my Python and my Fortran and my MySQL, Oracle, and PostGre databases, because AJAX is soooooo nifty and it’s sooooo worth it for people never to have to refresh a page even though they have noscript up…

    It’s clean. You write something, and it works. If you want it to work in windows, just use window’s API and handle a few signals. If you want it to work on your router, use their api. If you want to handle sockets, use that api. If you want to learn an API, rather than spending 50 of your hard earned bucks on an O’Reilly book, spend ten to twenty seconds looking at a header file.

    It can’t be more complicated than that, because if it were, it would be C++ or whatever else is supposed to completely revolutionize C and compress every ten lines of code into one terse block.

    If I wanted terse, I would use perl. If I wanted to take a million concepts and compress them into a regex and fifty characters, that’s the way to go. So taking up fewer lines of code is not a virtue, otherwise no one would ever use python.

    If something is clunky or long and drawn out or involves reinventing the wheel, you know what, it’s at least easy to understand just by reading it. There are no features except the ones you include explicitly. No one’s genius solution which honestly works better is going to have to be learned by you, the computer programmer. You have a swiss army knife that can solve any computer problem ever, at the slight cost of being mocked by people that can take the problem you solved and do it faster with fewer lines of code. You know what those people can’t do? Solve the problem you solved to begin with.

    Because that would involve reinventing the wheel, and everyone knows that a computer programmer’s job is to compensate for a total lack of applied library science to the software engineering community by looking at whatever the business majors are marketing at us as the next best thing.

    That’s my rant and I’m sticking to it.

  12. well first of all; thanks that you took the time to write that lengthy reply.

    But I think you are wrong at some substantial points:

    • The point in OOP today and in recent languages is not reusability(not reinventing the wheel), but the expressiveness and thereby readability.
    • Object Oriented design is the de facto standard for imperative language these days. This means most of C programmers use it and GObject is the support library to ease the development. But good OOP support requires support on compiler level. Therefore GObject fails.
    • The thing which makes leaning a new language hard is not the new syntax , but learning a new API for the standard library. And changes on this level occur in every language – even in C. See the the OpenGL1 -> OpenGL3 transition; the fact that it is C does not save you from the introduction of OOP here 😉

Leave a Reply to methdo Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.