When to (notionally) "Build your own compiler"

Answer 1

In case of a compiler, your cross platform argument is moot. Without virtually unlimited resources, you can't hope to become as cross platform as GCC or LLVM. Also, think about how long it would take to write a compiler, test it thoroughly on all platforms and document it.

The only reason you'd write your own is if you use a new or very exotic language.

Answer 2

Writing a compiler doesn't have to include writing the entire compiler -> platform executable stack. You can go partway and write a compiler to a subset of a particular language, similar to what FogBugz did with Wasabi. At least then you have an easier way to bootstrap it and run it without having to rewrite the entire software development stack.

MSN

Answer 3

In general, you'll want to use the tools everyone else is using, because they are pretty much guaranteed to be less buggy (more eyeballs, etc.), but in the following cases you might want to contemplate rolling your own solution:

1. License constraints: for example, you want to use a tool but it's released under the GPL and your company won't allow that.
2. Specificity: say you have a C compiler that compiles code to "all PIC micro controllers", but you want it to put the produced instructions in a particular order in a particular case (think Intel's C++ compiler, that aligns some instructions differently than other compilers to help the processor pipeline them).
3. Avoiding dependency hell: Consider, for example, the Django framework for Python. They use their own, smaller, version of certain tools (e.g. SimpleJSON) so they can include the tools in their own code-base, and you can easily deploy the framework just by checking out the SVN repository.
4. Their code is worse than yours: this happens quite a lot really. You happen to find a library that does exactly what you need, but the code is a mess, development has gone stale, etc.

Answer 4

Disclaimer - I have not written my own compiler, but I have worked on some fairly complex conversion tools that I consider to fit the spirit of the question.

My personal decision procedure involves a very non-scientific method. Basically look at all the basics such as whether there is a tool available that does what you want, take a quick stab at prototyping a simple portion of the problem, looking at the project timeline and how long you estimate you could write and debug the full-featured utility.

Then, run all the numbers by your manager and let them make the decision as to what to do. :)

Answer 5

Here's an acid test to help make this decision:

Can I obtain their source code and get it up-and-running within an hour?

I'm trying to capture a few key ideas:

• If the code is hard to obtain, it might stay that way.
• There seems to be high correlation between an active support community and initial time-to-run.
• There's a lot of value in rolling-your-own; if it's any serious work to import an external library, it's likely you're better off with your own version.

What's so good about rolling your own? In addition to, or maybe alongside, the general flow of Joel Spolsky's post (linked to by dmckee), I would add the idea of software evolution. Imagine that there were only three or four humans in the world. With such a shallow gene pool, we wouldn't evolve very quickly. Simply having a great deal of variety, along with a natural selection process, gives us better software. I'm implicitly also promoting more open sourced libraries, but I think the evolutionary benefits of roll-your-own can still apply to a single company.

Viva variety!

Answer 6

One other point to keep in mind is that if your development team isn't standardized, regardless of how good you are, not being able to guarantee tool availability across the environment sounds like you're setting yourself up to fail.

However, if you're statically-linking, or packaging, all of the required dependencies, then it doesn't matter if you roll your own or use existing tools.

I'd be concerned over whether or not there is a community around the libraries you want to use. For example, reimplementing glibc is probably a Bad Idea (tm). However, Billy Bob's Super C Toolchain might be worth reimplementing, unless you know Billy Bob is going to be around for a while.