Our Development Approach
We are, first and foremost, an engineering company. The company name was chosen, in part, as an allusion to Thomas Edison and his statement that "genius is one percent inspiration and ninety-nine percent perspiration." We believe that creating a good compiler front end is not a matter of coming up with a handful of clever algorithms. Rather, it involves making ten thousand small decisions carefully and correctly -- and then revisiting many of those decisions as years go by, to be sure they are still correct as the language and the world of software change.
We study the written definitions of the languages we are implementing, attend standards meetings, and correspond with other experts to develop a detailed understanding of the languages. We refine that understanding by looking at lots of real-world code, so we know how language features are really used, and what common extensions (and bugs of popular implementations) are exploited in existing code. Then, we design carefully and implement even more carefully. We worry about reliability, efficiency, and portability. We make sure that we implement all the pathological corner cases. We don't build in any fixed limits. We do complete error diagnosis and good error recovery.
We also worry about clarity. Unlike compiler developers who sell primarily to end users, we know that our source code and our internal documentation will be used and modified by others, and right away. We know that if we don't write the code clearly and with lots of comments, it will come back to haunt us as a support headache. We take as much pride in hearing comments like "the best looking code I've ever seen" as we do when our products' reliability and correctness are praised.
In addition, we anticipate customization. Since we know that our customers may want to make certain kinds of changes, we try to make that easy to do. A good example is our support for pragmas. We don't provide very many pragmas, but we provide a comprehensive mechanism that allows our customers to add many kinds of pragmas.
After implementing something, we do extensive testing. We use unit tests, commercial test suites, and large real-world programs as part of our testing procedure. For the C++/C front end, for example, we use five commercial C++ test suites, four C test suites, five commercial libraries, five freely-redistributable libraries, and about 17,000 unit tests. We know that testing cannot make a good product from a bad one, but it can make a good one even better. The results are good: we're second to none in our pass rate on test suites.
And after all that, since the job is 99% perspiration: we're very careful about checking and rechecking details, and we pay attention to what our customers tell us.