<div class="gmail_quote">On Mon, Oct 31, 2011 at 2:37 PM, Miles Bader <span dir="ltr"><<a href="mailto:miles@gnu.org">miles@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/11/1 Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>>:<br>
<div class="im">> That said, while the feedback was overwhelmingly positive, there were<br>
> definitely some who were less enthusiastic. Many of these people had worked<br>
> with GCC for so long that they exhibited strong change aversion. The<br>
> messages from GCC are very familiar, and map to an existing set of problem<br>
> descriptions for these people. They faced a learning curve when the messages<br>
> changed *at all*, and that was costly.<br>
<br>
</div>Yeesh, could you get any more condescending?</blockquote><div><br></div><div>I'm really sorry that came off as condescending, it wasn't meant to be. The cost imposed by switching to Clang's error messages was one we took very seriously. Working with GCC for a long time isn't a negative statement about the developer, it's a simple reality given the long history GCC has in the open source community as essentially the only compiler option available.</div>
<div><br></div><div>When evaluating Clang's error messages the threshold wasn't just being better based on the average feedback than GCC's messages; the improvement had to be sufficiently large to justify paying for the learning curve. There was a lot of debate, and a lot of things had to be fixed in Clang's diagnostics before it was clear that the cost/benefit tradeoff here supported transitioning to Clang's diagnostics across the board.</div>
</div>