hasenj blog

Why I won’t use D for my next project

Posted in hacking, rant by hasen on 11/08/2009

I used to follow the D programming language closely, I thought it has some really great ideas, and it could potentially replace C++,

I’ve had an idea for a new project for a while now, and I started working on a proof of concept, which I wrote in D, and while the language syntax is great, I’m afraid I’m going to have to switch to another language. Before I say why I won’t use D, I want to mention why I wanted to use D in the first place:

I considered using Python, but I want to create an application that’s usable by ordinary people who are not programming nerds. I know I can convert the project into a windows application with tools like py2exe, but that will create a huge executable; not a good thing.

C++ is too complicated, I just hate the language.
Java is too bloated and complicated, I hate the language, and its environment, and the monster that’s called Eclipse.

C is certainly a lot less complicated than C++, but it’s old and its age shows. Though still, I might end up using it.

D seems just perfect, the syntax is nice, build tools are nice, it should be able to produce a small executable, and working with it should be a pleasure.

BUT, here are the problems:

I put a lot of effort into creating an environment for programming in D on windows. I downloaded DSSS and Tango, and also Tangobos. I also downloaded gtkD since I want a GUI for this project of mine. Setting these things up to work together is not exactly a very easy task; but still it wasn’t too difficult on windows. Though still, it’s not a very easy or pleasant task.

Recently I switched to Linux, and setting up a D environment in linux proved to be quite the hassle, that I essentially gave up on it. While I was able to install dmd with no problem, I didn’t know how to install DSSS. I tried with apt-get, but the DSSS I got expects to find gdc, when I have dmd.

Why is it so hard to setup a development environment for D? This is a problem, not only because it will cause me a headache, but it could put-off many potential/would-be contributors.

Also, I was considering switching from GTK+ to Qt, however the QtD project is also difficult to install, even on windows.

Above all, one of the main reasons I love(d) D is because its syntax and features and build system should theoretically make working with it a pleasure; but … it’s not a pleasure at all!! So why even bother? If it’s gonna cause more pain than pleasure, then I might as well work in C++, at least it’s well supported.

Do I wish to see D succeed? Yes.
Would I love to contribute to its success? Sure!
Am I gonna make sacrifices for it as if it was my religion? No.

I didn’t really explain in detail why installing D and setting up its dependencies is complicated, but those who’ve worked with it should have a good idea of why that is the case.

My entire point is: why the hell, after 10 years of development, is it still so dam hard to setup a D development environment on linux? Stop thinking about crazy new features for D2 and work on making sure that D1 (the original D) is well supported across-platforms. The way I see it, D is slowly turning into vaporware.

While this is an exaggeration, it will eventually die if the author(s) don’t make it their priority to make D usable with the least amount of hassle that’s possible, instead of cramming new features into D2.


Thoughts on the OOP and abstraction “crap”

Posted in rant by hasen on 05/07/2009

I used to believe firmly in Object Oriented Programming methedology, not because I’ve had any experience with it, but because the professor who taught my class about it sounded like he really knows what he’s taking about (I’m sure he does, and I still have a lot of respect for him).

However, judging from my own experience, OOP is not always the answer. Hell, it’s the thing to avoid most of the time!

Let me first explain what’s the OOP crap I’m talking about, because there are many definitions of what OOP is, so to make sure you’re on the same page as I am, OOP means:

– High cohesion: every class should be responsible for a single task only, and it should do it well.

– Low coupling: different parts of the application should not be highly coupled/interwined together.

Now, in principle, this is all well, but in practice, if you apply high cohesion, you end up with high coupling.

Think about it, if every class is so simple and so small, then every class is utterly useless by itself, because it doesn’t do anything! Therefore, to do anything useful, many objects must interact together. Even simple tasks become very complex.

Think about reading a file in Java, I’ve done it several times but I keep forgetting how to do it. What was it? First you create an object that reads chunks of a file as raw bytes, then you wrap it in a buffer, then a buffer reader, then a text buffer reader? or some nonsense like that.

That, my friends, is a Horrible Way To Program!

This is related to my previous rant about Django.

With everything chopped down into tiny simple classes, the task of adding new functionality becomes immensely complex, and also the act of changing an existing functionality. Because the interactions between objects are so complicated.

I’m not saying that you shouldn’t use abstraction, no, do it, but do it sanely. Do make classes/function simple, but don’t make them dumb and useless. Make them simple to use, simple to read, to interface to, but don’t make them stupid.

Linus made a comment about micro-kernels, in which he describes why they are so damn difficult to implement: you don’t have a single thing that is a kernel, you just have many tiny components that do simple things, which results in a system that needs many complex interactions between these components, and that’s something that’s very hard to get right and very difficult to debug. (every wonder why the Hurd kernel is taking so damn long??)

That’s exactly what it is: if you simplify the individual components too much, you’ll get a very complex system that’s unmaintainable.

It’s better to start with something that “just works” even if it looks like spaghetti at first, as long as you keep refactoring, you can end up with a reasonable abstraction, where functions and/or objects are simple, but not too simple to the point of being utterly useless.