This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: source mgt. requirements solicitation
- From: Nathanael Nerode <neroden at twcny dot rr dot com>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 15 Dec 2002 21:08:50 -0500
- Subject: Re: source mgt. requirements solicitation
Linus said:
>Naah. It's simple - kernels are just sexier.
That I believe. :-)
>Seriously, I think it's just that a kernel tends to have more different
>_kinds_ of problems, and thus tend to attract different kinds of
>people, and more of them.
I really don't think so. A kernel has more easy problems, in a
certain sense: more problems that can be started by people with little
background. A compiler has *lots* of different types of problems, but
they're almost all rather complicated and hard to start on, for a reason
I mention at the end of this.
>people who are interested in one of them. So you'll find people who
>care about filesystems,
We got that in compilers...
>or people who care about memory management, or
We got that...
>people who find it interesting to do concurrency work
We got that...
>or IO paths.
We got that...
Heh. I think the real reason why fewer people work on compilers is
one of abstraction. To oversimplify, a kernel just *does* things.
A compiler is one level more abstract; it takes input and converts it
into code which does things. It takes some practice to get comfortable
with, and good at, that style of coding, and it's significantly harder
to debug. While I'm sure there's some kernel code like that, *most*
compiler code is like this. Given GCC's design, we even have two
levels of abstraction: the build system compiles and runs programs
to generate a compiler for a specific host-target pair. This is code
to generate code to generate code.
--Nathanael