Re: [tlug] C vs. other languages

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Steve" == Steve Smith <sjs@example.com> writes:

    Steve> On Fri, 30 Jul 2004, Godwin Stewart wrote:

    >> Why are 99% of the operating system I use and its auxiliary
    >> tools written in C rather than Java?

Well, for starters, Java wasn't really available at that time
(consider Xt, for example---object oriented out the wazoo, but the
programmer, not the compiler, has to keep track of types <shiver>).
Most existing production OSes are really 1980s vintage at the latest,
even TRON and Plan 9.  If you want to see modern OS implementations,
I'd say go look at embedded.

Java sucks for that purpose, too; it assumes a certain virtual
machine, and doesn't like to allow you anywhere near the metal.  But
... don't forget the Lisp machines.  They had Lisp _microcode_, OK?
They didn't fail because they were slow, they failed _as a business
strategy_ because most people don't want to wrap their minds around
Lisp, not now, and not then either.  It would be interesting to see
what a Java chip would behave like.

    >> What about the mailer I use? A few of the tools I use
    >> (including the GUI) are written in C++ - why not in Java if
    >> Java's OO is so good? ("because they suck" isn't an answer...:)

Bigotry.  The main reason is that people think that OO, VHLL are too
slow.  They certainly can be, especially in database and database-like
code.  But I regularly use Emacs Lisp (a notoriously slow language[1])
for numerical code.  (Not serious number crunching, I'm talking about
linear regression, quickie projections.)  It will do a 100x100 matrix
inversion before you finish the upstroke on Enter.  Nothing can be
usefully faster than O(negligible_fraction_of_a_second).

    Steve> But in our case a major part of the problem is the OO
    Steve> paradigm that was chosen.

So it's a design problem, not a language issue after all.

Maybe you've seen http://www.jwz.org/doc/mailsum.html?

In fact, much of http://www.jwz.org/doc/ is relevant to this
discussion.  (In particular, Jamie confesses to a love/hate
relationship with Java.)

    Steve> In general OO is much more resource intensive (memory and
    Steve> CPU) than a more process driven design.  And C is a much
    Steve> more suitable languzge for this than C++

Nonsense.  Bjarne was employed by the phone company, and C++ was
expected to used, and is used, for switches as well as for the
database stuff.  The only time where you are unquestionably right is
at compile time, and that's a good time to be using more resources,
no?

In my personal experience (which in this respect is limited to
XEmacs), all the benchmarks say that XEmacs is faster when compiled
with C++ than with C.  It's within the margin of statistical error
over all, but with matched pairs (compiled and run on the same
machine, with no toolchain, library, or OS packages installed/upgraded
between them), C++ regularly beats C because it's slightly more
aggressive at inlining in certain contexts (which are emphasized in
the benchmarks because users complain about features exercising them,
so it probably matters), and the call sequence is more efficient in
some contexts.

The reasons we don't mandate C++ and start taking advantage of the OO
features are that (1) we still support a couple of platforms that
don't have a standard C++ compiler (although G++ does support them)
and (2) nobody who really knows C++ implementations is willing to
promise that C++ exception handling and constructor/destructor
disciplines are compatible with our garbage collector.

This doesn't really deny your claim w.r.t. to OO, since obviously
"Clean C" (ie, that common dialect of C and C++ which compiles and
runs the same way under both) doesn't provide the relevant OO
features.  However, I do want to advocate the position that you're
wrong about oo (lowercase OO ;-).  It's pretty clear to me that if
XEmacs were written in a "C + Classes" style, we would get very big
wins in maintainability at zero expense in pretty much anything
relevant, except the few users who would have to install G++.  The big
problem would be holding the line against some of the newer (ie, < 10
years old) features of STL, etc., until a clear use case was
demonstrated.

Oh, by the way: the places where _I_ personally would give up sex for
a week to get OO are in the low-level stream-handling code, where
we're typically dealing with raw sewage and have to clean it up
_fast_.  XEmacs is a text editor, so that's not realtime programming,
but still, I think I have some idea where you're coming from.


Footnotes: 
[1]  ((How . slow) . (is . it?))  Well, one of my colleagues has an
Emacs Lisp bytecode simulator written in Scheme48, and the XEmacs Lisp
bytecode engine and the Scheme48 bytecode simulator running on the
Scheme48 interpreter finish in a dead heat on the available benchmarks.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.