As several people are sure to remind me, the Linux Kernel mailing list is not the right forum for a discussion on language choice and the impact on kernel development, but as this is not the first time I've followed this class of argument, I'd like to make a couple of general observations that I hope *are* relevant to the list. First, arguments of the form "it's ok for applications, but kernels need more control, performance, et cetera than language X provides, which is why we use language Z" are fallacious. The end user of a computer system cares about the *entire* performance of that system, not just the kernel. Peformance issues exist whether the hardware is executing in 'system' mode or not (to use an archaic term) and applications are not immune from these considerations simply because they execute in 'user' mode (to use a related archaic term.) The point is that performance critical sections of code need to be treated as such, no matter where they occur, and that one person's performance critical code may never be exercised in another person's workload. Second, arguments of the form "language X is slower, sloppier, harder to control than language Z" suffer from extreme oversimplification. The most that can be said when comparing the relative performance of two programming languages is that the combination of programming practice and compiler sophistication is such that typically, programs written in language Z need more care than programs written in language X in order to reach the same level of performance, controllability, et cetera. (For instance, in the mid 80s, I recoded a rather famous Fortran vector supercomputing benchmark into C, and, for a particular combination of machine and compiler, was able to actually outperform the Fortran version in many of its tests. The machine's vendor spent far more effort on their Fortran than C compiler, and in a few years even that machine returned to Fortran outperforming C.) The Linux kernel is an old-style process oriented Unix clone. As such, it is best written in C, and should probably remain in C, since its overall structure falls into a family of kernels written in C over a period now approaching 30 years. That is, in fact, the best reason for leaving Linux in C: preserving the long legacy of C related optimization and the C related programming skill set. That is *not* an argument for not writing an operating system core in mixed languages or even other languages. Not counting assemblers, I've worked on operating systems in a lot of languages, including Ada, Algol, Basic, C, C++, Forth, Fortran, Lisp, Pascal, PL/I and Smalltalk, and all of those that were in use for any period of time reached acceptable (and often very good) levels of performance. While C++ implementations and programming practice are not yet anywhere as mature as those for C, I expect that within a decade a new breed of operating system cores, which have overthrown the idea of 'kernel' without falling into the trap of 'microkernel' will begin to arrive, written in languages that more suitably match the programming paradigms of the application systems built on top of them. The last, by the way, is the key to language choice for OS implementation, in my opinion: it is best to choose the language that best resolves the competing constrains of fitting the prevalent paradigm while having robust implementations and mature understanding of programming practice suitable to the language. Marty - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
