kern/99979: Get Ready for Kernel Module in C++

[Mike Meyer]

In <20060712144827.GA99296 at megan.kiwi-computer.com>, Rick C. Petty <rick-freebsd at kiwi-computer.com> typed:
> On Wed, Jul 12, 2006 at 04:10:29PM +0200, pfgshield-freebsd at yahoo.com wrote:
> > C++ is the de-facto standard for OO
> That is just sad.  So many other languages do a much better job of
> implementing OO (Smalltalk, Java, Python, even Scheme).  While we're at
> it, why not implement a bytecode interpreter for all of these languages
> into the kernel?  That would be sweet..

Who needs a byte code interpreter? My favorite Scheme implementation
(back when I wrote a lot of Scheme) was DECWRL's Scheme->C, which
compiled Scheme to C. Likewise, most Eiffel implementations (if you
want a good OO langauge, that's the one I'd pick) compile to C.

Of course, the right way to access those languages from the kernel is
to put stubs in the kernel to call userland code to do the work, as
has already been suggested. That works. There are file systems written
in Python.

> I'm being facetious here;  OO has some merit but aside from that, there's
> very little utility an additional language can provide.

Not true. I'll take a moment to point out that my comments about not
picking C++ just because it's popular apply to OO as well. The
functional programming folks make a good argument that their style is
as or more productive than OO - at least for people who understand it.

In particular, the high-end functional languages provide facilities
that don't exist in most languages: a turing complete system for code
creation at compile time. Ok, C++'s STL has it, but it's *really* hard
to use, and I don't think anyone wants STL in the kernel.

> For this reason, BSD shouldn't bend over backwards for C++ developers any
> more than it should for Python or Ruby developers.  The implied stability
> and consistency of a finished language is exactly what is needed for a
> stable and consistent OS (kernel).  Pick a language (let's call it "C")
> that isn't likely to evolve any further.  Oh wait, we already did :-P

I know you're kidding, but someone might not realize it.

BSD Unix didn't pick C; we inherited it from AT&T Unix. K&R didn't
pick C either; they wrote it so they'd have a good high-level (well,
for the time) language for writing systems code in. It evolved
significantly well after the first kernels were written in it (anyone
else remember =+?).

In fact, it evolved to meet the needs of the peoplel writing code in
it. This argues for picking a *less* popular/stable language than C++:
BSD would be a bigger part of the community, and thus have more say in
how the language evolved.

And, to reference back to your comment about interpreters, the
predecessor to C was B, which was interpreted. The predecessor to B
was BCPL, which is why the successor to C should be P, not D.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.