[cfe-dev] Chrome/mac is all-clang, all-the-time

David Chisnall csdavec at swan.ac.uk
Mon Oct 31 15:27:05 PDT 2011

On 31 Oct 2011, at 21:37, Miles Bader wrote:

> 2011/11/1 Chandler Carruth <chandlerc at google.com>:
>> That said, while the feedback was overwhelmingly positive, there were
>> definitely some who were less enthusiastic. Many of these people had worked
>> with GCC for so long that they exhibited strong change aversion. The
>> messages from GCC are very familiar, and map to an existing set of problem
>> descriptions for these people. They faced a learning curve when the messages
>> changed *at all*, and that was costly.
> Yeesh, could you get any more condescending?

I don't think that's condescending, I think it a pretty accurate description and something that developers familiar with one compiler will always find when they move to another.  Many years ago, I used Microsoft's (approximation of) C++ compiler, and when I switched to using GCC I found it took a while to get used to the different error messages.  Not because they were more or less expressive, but because I subconsciously mapped specific error messages to specific patterns of changes in my code.  When I saw one error, I immediately fixed it by making a change, without even reading the error all the way through.  After a few months of using GCC, I developed the same habits.

Some years later, when I switched to clang, I found the same thing.  GCC would say 'unexpected something after whatever' and I know that this mean 'idiot, you forgot a semicolon'.  When I started using clang, the error message actually told me that I missed a semicolon, but I had to actually read the entire message because it wasn't the pattern of text that I was expecting.  

After using clang for a while, I find that I was starting to rely on its error messages.  Back when clang's C++ codegen was largely nonfunctional, I was running g++, getting incomprehensible error messages, running clang++, fixing the errors it showed, and then compiling with g++ (which, in spite of the relative poor quality of the errors, had the advantage that it did generate a working binary - something that is generally considered beneficial in a compiler).  

Whatever the compiler, after you've been using it for a while, you don't read the common error messages in detail, you look at the vague shape and fix the problem automatically, without thinking, because you've seen that error message a lot before and you know what kind of typo causes it.  This isn't condescending, it's the kind of automatic behaviour that any HCI textbook will tell you about in chapter 1.


More information about the cfe-dev mailing list