AK's weblog

Through this tweet, I got aware of redo, a build system with an interesting approach. It's based on some ideas that djb wrote down on his website, but apparently never published any code. This blog posting even goes as far as claiming that redo could be the Git of build systems. It argues that Git replaced most other widespread open source VCS because it's simple and flexible, and redo will go the same way for the same reasons.

I'm a person who is usually open to new approaches regarding development/build infrastructure, and so I evaluated redo by converting the build system of newsbeuter to redo. I chose newsbeuter not only because it's my most successful project so far, but also because it is typical for how I structured projects and their build system in the last few years, and it's non-trivial: some .o files are packed into .a files, two different binaries are built that share a common library, .h files are created from other text files, and it's currently all done by a single, non-recursive Makefile. The hypothesis is that if I can use redo to build newsbeuter without any hassles or weird hacks or workarounds, then it's good enough for what I need.

The actual conversion took me about an hour, maybe a bit more. Documentation could answer all my questions, except for those things that I stumbled upon that I consider to be bugs (I will report them later, don't worry). It was really hassle-free and straightforward, and at no point I was ever confused because I hadn't fully digested a new but poorly explained concept yet. But I think that the claim of redo being the Git of build systems can't be held up.

And that is because of one major thing: redo tries to do things "right", and it does so by implementing one certain approach and one certain approach only: redo doesn't support non-recursive builds. If I want a rule to apply to e.g. .cpp files in the root directory and in the src subdirectory, I will have to duplicate this rule. Since redo rules are basically shell scripts, this can be easily deduplicated, but a problem arises when e.g. the command line to compile .cpp to .o files contains -I options to reference files in the local project directory. For the .cpp file in the root directory, such an option has to be "-Iinclude", while for a .cpp file in the src subdirectory, it has to be "-I../include". I don't see anything in redo's documentation that the author has thought of that situation in any way, he even explicitly states that "There is no non-recursive way to use redo."

And that's the fundamental difference to make (the make I use is GNU make, just to make that clear), where I as a developer can choose to use make either in a recursive or non-recursive fashion, whichever I prefer. redo really lacks flexibility here. I would probably be able to solve some of my issues by restructuring the source tree to work around these deficiencies, but why would I want to do that? Tools are supposed to work for me, and not the other way around, they should be flexible enough to be adaptable to my needs, and I shouldn't need to adapt my existing project to make it fit to what redo expects.

So, redo, from a conceptual point of view, has a really good and simple approach (very djb-y), and I'm sure it's an excellent tool for new projects, but for existing projects that already use make in a non-recursive fashion, it would a maintenance PITA. And that's why I conclude that redo in its current conceptual state will never be the Git of build systems. make is still more flexible, and even though it has its flaws, it's still good enough for most people, and also a de-facto standard.

In this posting (and also this one), Su-Shee pleads for a more vocal and active promotion/advocacy. While I know how nice it can be to use a piece of software that makes people envious, I just want a quiet, hype-free, pragmatic, down-to-earth knowledgable community, and I will explain why.

Some years ago, summer or fall 2002, if I recall correctly, there was this new object-oriented programming language that everybody was talking about, that was quite obscure but really cool because you could write compact, easy-to-read, object-oriented code, in a fashion not unlike Perl. That programming language was Ruby. Having had a background of Pascal, C, and some C++ and Perl, I was astonished by the expressiveness and flexibility of the language, without losing readability. I used Ruby for quite some time, worked on some silly open source project with it, I used it for scripting at work (until my then-boss prohibited the use of any programming language for which no other developer in-house had any knowledge), I wrote daemons that formed the glue between email and MMS systems, I even used it as exploratory prototyping language for stuff that I would later rewrite in C. And then came Rails.

Rails was hyped as the greatest invention since sliced bread, the be-all end-all of web development. As somebody who had previously only known CGI.pm and cgi.rb, this indeed looked intriguing. I had a closer look, bought a book, played with it, and found it quite OK. Until I wanted to do things differently than what the usual tutorials had in mind. Useful documentation about the greater context and overall concepts was sparse (be aware, this was pre-1.0 Rails, things may have changed a lot since then), and I felt constricted by too many things in Rails (this has most likely been addressed in later releases; I haven't bothered to look back since then, though). So many things that were advertised as awesome turned out to be nice, but not that impressive on closer inspection.

And this is exactly what I don't want to do, namely awakening false hope in people about awesome features of $SOFTWARE, and I think an overly optimistic presentation of a system's features can easily lead to exactly that. In fact, the only screencast that didn't disappoint on closer look was Google's launch of the Go programming language in 2009, but that only as a side note. Self assurance is nice at all, but in my experience, there's only a fine line between self assurance and misrepresentation.

Another aspect of the Rails hype was the complete turn-over of a great portion of the Ruby community. The usual community and support channels were flooded with people interested in Rails, Rails became synonymous with Ruby, the signal-noise ratio drastically became worse. Some people even tried to actively recruit me for open-source Rails projects because I "knew Ruby". I declined, because the web applications aren't my area of interest at all (even today, the only things I have to do with web is that I hack on stuff like Apache and PHP [the interpreter] for a living; still, no web development).

Yeah, the community turn-over. Soon, people with big egos and great self assurance surfaced, dubbing themselves rockstars or ninjas or similar. I always found these to be acts of total douchebaggery, because, in the end, they all only cooked with water, anyway (a notable exception was why the lucky stiff). These were the people with great self assurance and a total lack of self-criticism or reflection on one's own work. It's not the kind of people whose software I would want to use, because too often my experience was that some library, framework or tool was announced with big words, which then practically always turned out not to be great at all, sometimes even barely usable or totally buggy.

And that brings me back to the original topic of Perl. Exactly the things that I learned to despise about the culture revolving around Ruby and Rails are something that I haven't experienced in the Perl community at all so far. Libraries, framework, documentation and people had more time to mature, probably, while still being down-to-earth. I can expect good documentation, functioning software, friendly people and most importantly accurate words in announcements and discussions.

Through my current employment, I found the way back to Perl, using it at work and also for some personal stuff. I recently even started a new open source project where I productively use Moose for the first time. My code is probably not very expressive and may seem weird (I know, TIMTOWTDI), but at least I feel comfortable writing it. I'm fine with most things surrounding Perl, its eco-system and its communities, and so I don't want to see any kind of interruption and turn-over like I saw it with Ruby.