Many programmers live in a very fluffy world, where there is an API for everything, where a nice compiler takes all that nice code into something that the machine will interpret correctly. Others will go further, and hack their way through uneasy code. Only a few will come to the end of the darkness, where no compiler fits their needs.
I admit this isn’t a feature that is often required, but when you faced it once, you never want to go back again. Having to choose between making your own compiler and a big, ugly massive hack that you will regret for a long time, telling yourself “if only I had access to the compiler sources, I could change this one little thing and everything would be perfect”.
It happened to me once in my short career as a programmer, back when I was working on porting someone else’s application to a new platform. We were working on a library that handled the generic part of most of our tasks, not an unusual strategy. For each project, we received frequent drops of the client’s code, hence we wanted to minimize the changes to their code. In one particular project, we had a nasty crash, hard to reproduce: it took a while to happen, it seemed random, no specific reproduction step could be identified. The stack trace didn’t give much information of what it was, but we finally identified the source: the memory management system in the client’s code.
The client’s code used a memory pool, which is very common in these kinds of program. They defined a global new and delete in order to wrap everything into their memory managing system. This means everything we created in our library that used global new and delete (int, long etc.) was also getting managed by the memory pool. The buffers being at their limit, linking with our library was making everything explode. Blindly increasing the size of the buffer solved this problem, but created others. A brief analysis of upcoming projects shown us that a similar problem could happen again. We had to made our library “global new and delete proof”.
The clean solution would have been to create a new and delete specific to a namespace, but this is impossible to do without modification to the compiler. We didn’t have the budget or task force to buy or create the compiler, so we resign to another solution. We replaced everything with malloc, add a mention to the training program that new and delete were banned, and quit on integrating other libraries in which we couldn’t make this ugly modification.
There are many other reasons to build your own compiler. The Excel team at Microsoft had its own C compiler, allowing them optimizations not possible otherwise and a total control on their software. You can read more about this in this very interesting article from Joel on Software.
My husband want to make the compiler code open (the license has yet to be defined). Once he’ll bootstrap it, he’ll make it available to the world. An important aspect of C3 is that you should not find yourself limited by the language itself. You may need to work hard for something unusual, but everything should be possible (code-wise).