Reimplenting Linux Kernel in Python

[Alex Martelli]

Phil Frost <indigo at bitglue.com> wrote:
   ...
> I do agree though that there is little point in rewriting Linux in
> Python. The advantage in Python is its expressiveness, but by rewriting
> an existing system you gain nothing.

By rewriting any existing system in a higher-level language, you may
gain the benefits of higher-level languages -- more concise and readable
expression, enabling maintenance, modification and enrichment.

This is certainly the advantage we're after with the pypy project, which
is based on rewriting the Python interpreter in Python.  Google for
pypy, you'll find lots of materials about it on the net.  If we can
shrink the interpreter and built-in modules from about 350K lines of
code (based on a rough find/xargs cat/wc on the 2.4 release) down to
about 30k (and we're on target for that -- pypy isn't anywhere like
ready, but already does a lot), the benefits in maintenance, further
future modification, enabling experimentations, etc, should follow.

Re Linux, we just got a fascinating talk at CodeJam Italia, last week,
about the new virtual memory twists that are likely going to be in
kernel 2.6.9.  Part of it was this Indian mathematician appearing out of
nowhere with a wonderful new algorithm designed exactly to solve some
subtle problems in the new ("pagetable-less", pardon the
oversimplification!-) architecture for mmap on huge-memory machines.
This is wonderful, BUT, if the source could shrink by a factor of 10 or
more, making them hugely more accessible, think of how much more such
useful, nay, precious, contributions, that might elicit -- and how much
easier it would be for contributors to experiment and play around with a
huge variety of ideas...

The obvious problem might be performance.  For that, all of us in the
pypy project (except the few others who can actually follow what's going
on;-) rely on wizard Armin Rigo, of psyco fame -- the idea is that the
pypy framework will "easily" (ha!-) generate machine code (on the fly or
in advance) for the (runtime-restricted) subset of Python which is used
in "interpreter level"... leading in the end to a _faster_ virtual
machine, wrt current pure-C Python, one competitive with CPython+psyco
or even beating it (thanks to advances in "symbolic execution" and type
annotation which are already enabled by using a higher-level language,
rather than C, for the interpreter/VM/execution framework).

pypy still needs to be completed, and proven in the field.  But I'm
offering it as an example of the potential benefits of rewriting
existing software in higher-level languages...


Alex