Tue Jan 22 19:28:00 EST 2013

The Haskell Toolchain: Clarifications

My recent rant briefly appeared on the front pages of HN and /r/haskell, to a largely negative response. Most of the comments either accused me of having autotools-Stockholm-syndrome or insulted my reasoning ability. Since I still stand by what I said, I will respond to those main criticisms.

Autotools-Stockholm-syndrome: this argument is basically "I could write a 20-line Makefile to build my code instead of learning the autotools". Yes, you probably can. Now suppose you want to add automatic dependency tracking, so when you compile foo.c into foo.o. gcc (and other compilers) can list any included .h files as extra dependencies for foo.o. Now suppose you want to support other compilers, more OSes than just GNU/Linux (or your MacBook). Now suppose you want to support cross-compilation. Now suppose you want to support the GNU Makefile Conventions, including the standard targets for users. A tool to automatically generate makefiles starts to sound pretty good. The traditional ./configure && make && sudo make install dance is pretty good for the user (CMake, for all its faults, wins here with its wonderful GUI) and a properly autotooled package is quite easy for distros to package. In the past, I've written hand-written Makefiles for specific projects (often internal ones that don't need an install step), and it is often the way to go. For free software projects written in a supported language, automake is an excellent (if warty) tool. You never know quite what users are going to want to do with your package.

Reasoning: The accusation here is that I'm appealing to tradition by saying that libtool is allowed to wrap the C compiler, but a new tool cannot. I maintain that wrapping the C compiler always was a bad idea to be avoided if possible. There's not much that can be done in libtool's case (especially when factoring in things like DLL support on Windows) but a pkg-config-ish tool for GHC really would help. There's nothing wrong with a convenience wrapper, but as Alan Kay says, "simple things should be simple, complex things should be possible". GHC's approach covers the "simple things" but not the "complex things".

Saying that "your new tools should play nice with the old tools" is not an appeal to tradition. It makes no assertion about the quality of the old tools, but simply addresses a practical concern. Look at how long it took for python 3 to get going because it tried to make a clean break from the past. Working in an ideal world is nice, but supporting the real world is better for getting things done.


Posted by Jack Kelly | Permanent link | File under: rants, coding