You missed the point

I don't have a list, but I am sure you use tools every day that were developed in some
language other than C. Perl and Python come to mind, but at any rate, restricting your tool
chain to C-based code is not possible nowadays.  It isn't just narrow-minded to want that, it
is burying your head in the sand to pretend it is possible.

If sylware thinks he understands Gcc's C compiler, it can only be because he hasn't looked at
it in a long, long time.

gcc has an extremely complex codebase.   Your argument would seem to suggest replacing it with
a simpler C compiler such as pcc, in order to reduce the total complexity of the 'system
software stack'.

Similarly you should be running Minix or another kernel that is simple enough  one person can
read and understand all the code.  And I assume you have no truck with the horribly baroque
autoconf/automake/libtool rat's nest.

From what I've read, gold is much simpler than the overly-general ld implementation it
substitutes for.  Of course, part of this simplicity is because it is written in a
higher-level language.  Often this is a worthwhile tradeoff - after all the compiler only has
to be written and debugged once.  Were this not the case, all programs would be in assembly.

Your argument makes no sense.  The C++ compiler stack is part of GCC, and the C++ portions of
the compiler make up such a small percentage of the complexity of the rest of the stack as to
be not worthy of mentioning.  Plus, I'm fairly sure (might be wrong) that the current versions
of GCC have merged the C and C++ parsers.

The complexity of C++ does not mean that you get huge, unwieldly compilers.  It just means
that you have trouble implementing the spec 100% accurately.  It's no different some a
protocol like HTTP.  HTTP (esp v1.1) is actually pretty hard to get fully implemented
correctly.  A lot of HTTP servers get it wrong, as do a lot of clients, and thus there are
certain combinations of HTTP server and client that just don't work together.  Despite this, a
fully correct HTTP server or client implementation is still pretty short, sweet, and easy to
read.  HTTP doesn't force ugly code, it's just not as simple a protocol as one might think it
is.  You can think of C++ the same way.  It doesn't require that much extra effort on top of C
to write a compiler for, but it trying to make sure you cover 100% of the spec is harder than
you might think given how very little C++ adds to the C language.

Well then you should really stay away from the programming for some time already.

Guess what the language is used for the tools used in designing computer chips?

(for reference, see http://www.research.att.com/~bs/applications.html, scroll down to the
bullet labeled 'Intel')

How dare you be this dismissive of *anyone's* work without an alternative to offer? Especially
on that flimsiest of pretexts, ideology?

You want something done *your* way, do it yourself. Otherwise, take what you're offered.
Telling someone that they have to junk what they've done is bad enough when they're only as
far as having it working; when they're handily trouncing what they aim to replace, telling
them that their replacement isn't "good enough" - because their choice of implementation
language doesn't satisfy *your aesthetic tastes* - only exposes *you* as the fool you are.

(Unfortunately, yours is the voice of the majority, and humanity is doomed.)

Um, ld's *algorithms* are wrong, and the wrongness is deeply embedded. The only way to speed
it up as much as gold is is to rewrite it from scratch.

Ian did that, and preferred to do it in C++.

Feel free to rewrite it yourself, in whatever language you prefer. When you make something
faster and easier to maintain than gold, come back to us.