Wrong name [LWN.net]

Wrong name

Posted Jan 17, 2008 11:04 UTC (Thu) by njs (subscriber, #40338)
In reply to: Wrong name by ms
Parent article: A kernel security hole

What language would you suggest?

For some reason the programming language geeks who understand why powerful type systems are
useful also only care about hyper-abstract functional languages, which are nice and all but
have serious limitations when it comes to writing a kernel, don't have compilers for most
architectures, etc.

(Log in to post comments)

Wrong name

Posted Jan 17, 2008 11:48 UTC (Thu) by ms (subscriber, #41272) [Link]

Well there's no hiding it, I'm a Haskell fan. GHC does support the more standard architectures
(x86, sparc, ppc - see http://haskell.org/ghc/download_ghc_682.html). As for performance, I
really think that the choice of C in general is a premature optimisation. I would argue that
it would be easier and quicker and much safer to write the kernel in a much higher-level
language like Haskell and then invest time in making the compiler and optimiser really
staggeringly clever.

On the other hand, I'm in no way speaking from experience, so I guess like with most
academics, the world will look the other way...

Incidentally, the reason why powerful type-systems tend to only appear in functional languages
is that imperative languages just allow the programmer too much madness to permit a really
powerful type system. Scala pretty much contains everything you can get away with in an
imperative language and even there, I'm unaware that anyone's actually proved it sound.

Wrong name

Posted Jan 17, 2008 12:14 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

“I would argue that it would be easier and quicker and much safer to write the kernel in a
much higher-level language like Haskell and then invest time in making the compiler and
optimiser really staggeringly clever.”

It's not obvious to me that this would work, nor that if it did work it would fix a
sufficiently broad category of problems to be worthwhile, and nor that if it did work, AND
fixed a broad category of problems, it would actually take comparable time (if it takes 10
years to do what used to take six weeks then you've shot yourself in the foot because 10 years
is too late). It's also not obvious that Linux Kernel developers (often expert in C and
low-level hardware stuff) would make good compiler designers, since these are largely
unrelated skills.

No-one has, to my knowledge, been stopping people from actually developing these staggeringly
clever compilers over the decades since LISP and C were the state of the art. It's even
regarded as a genuinely interesting problem (unlike Operating systems which have been largely
treated as a commodity) so you could get funding to work on it.

Wrong name

Posted Jan 17, 2008 21:27 UTC (Thu) by droundy (subscriber, #4559) [Link]

"I would argue that it would be easier and quicker and much safer to write the kernel in a
much higher-level language like Haskell and then invest time in making the compiler and
optimiser really staggeringly clever."

I'm also a big fan of Haskell, but wouldn't really want the kernel to be written in Haskell.
It's a wonderful language, and adding more static type-checking to the kernel would be great,
but for the kernel, performance should be everything (well, almost everything).  I think the
kernel devs have it right: add static checks to C (via sparse).

David

high level kernel code

Posted Jan 18, 2008 21:49 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I agree with your view, but I don't like the phrasing, "compiler and optimizer." The optimizer is an intrinsic part of the compiler -- it's only in low level languages such as C that a user can have a concept of the natural object code, which can be distinguished from optimized code.

The compiler has to be thought of as something that writes machine code, not something that translates source code into machine code. Then it makes sense to say people should spend their time making compilers that write efficient code rather than writing efficient code themselves.