Sat
31
Jan 2015

Of various kinds of programs that a programmer can work with, I think that developing compilers is particularly difficult. Here is why:

If your job is to just work with data (e.g. in Excel), all that can be wrong is just the data.

If you are a programmer, you write programs. Programs generally translate some input data to some output data. So if the output is wrong, you examine the input and if you are convinced that the input is correct, there is probably some bug in your program.

If you develop a compiler, things get even more complicated. Then you write a program (compiler) that will take source code of another program as input and produce compiled program as output. That program will process some data. So if the output of that program is wrong, its input data may be wrong, its source code may have a bug or, if you are convinced that they are both correct, there is probably some bug in the compiler. So there are more “degrees of freedom” here. You examine what’s wrong in the output data, then you look at compiled program to find a bug and finally you examine the compiler to understand why it generated that program.

It’s not always that simple to even determine which part has a bug. Even if your change in the compiler causes program to produce invalid output, sometimes it may be a bug in the source code. For example, the program may rely on some undefined behavior (like use of uninitialized variable), so any change in the compiler can produce different output, while the compiler is still correct.

When learning functional programming, you must understand how to operate on higher-order functions - functions that operate on functions. I can see an analogy here. So if you even consider working in compiler development, better think twice whether you are ready for such higher-order, hardcore level of debugging :)

Comments | #compilers Share

Comments