Date: Wed, 12 Jul 2006 11:46:42 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: rick-freebsd@kiwi-computer.com Cc: freebsd-hackers@freebsd.org, pfgshield-freebsd@yahoo.com Subject: Re: kern/99979: Get Ready for Kernel Module in C++ Message-ID: <17589.6498.456179.132004@bhuda.mired.org> In-Reply-To: <20060712144827.GA99296@megan.kiwi-computer.com> References: <20060712090019.GA723@turion.vk2pj.dyndns.org> <20060712141029.35239.qmail@web32707.mail.mud.yahoo.com> <20060712144827.GA99296@megan.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <20060712144827.GA99296@megan.kiwi-computer.com>, Rick C. Petty <rick-freebsd@kiwi-computer.com> typed: > On Wed, Jul 12, 2006 at 04:10:29PM +0200, pfgshield-freebsd@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@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17589.6498.456179.132004>