[Shootout-list] Re: OO (was Re: process creation & message passing)

Aaron Denney wnoise@ofb.net
Thu, 21 Oct 2004 06:21:41 +0000 (UTC)


On 2004-10-21, Brandon J. Van Every <vanevery@indiegamedesign.com> wrote:
> I would like to know why, exactly, you think this whole line of
> reasoning is important to investigate.  This is 2004.  These arguments
> are ancient and, I would submit, uninteresting.  At least with regards
> to C.  Are you really really really really into the idea of promoting
> the "potential OO-ness of C," or are you just being kinda theoretical
> and wonkish about testing inclusiveness?  It is actually OK, IMHO, to
> cut out spurious cases and get people to concentrate on big picture
> issues.  The marginal OO possibility of C is an itsy bitsy eeny weeny
> teeny tiny issue.
>
> And, we'll happily take the first C person out back and shoot 'em who
> says otherwise.  :-)

C is not my favorite language.   And yet, I have seen a few large
projects use OO techniques.  You may know about one of them: the
linux kernel.  In practice, yes, some C programmers do use OO
techniques.

If we want to exclude some languages from some tests on the basis that
their communities "do not commonly do things that way", we should have
some way of saying that, rather than a blank spot on the test summary.

How would people feel about adding a test that used continuation-passing
style?  Should languages that can technically do this be excluded, just
because it's not common?  How about if it's just somewhat difficult and
cumbersome to fake passing functions, as in Java?

How about laziness?  It's trivial in Haskell, possible to make fairly
painless in the ML's and scheme, and can be a pain in the imperative
languages.

I say we should be measuring what's possible, and how cumbersome it is.
That may be "it's so cumbersome we need a few hundred more lines", or
even "it's so cumbersome that no one has done it."

Yeah, sometimes a hand-rolled implementation of something will beat the
language provided one performance-wise.  I don't see this as a problem.
It's accurately reporting that OO that only uses those features in
language X will be faster than OO using only those those features in
language Y, because you can't turn off those features in language Y.

-- 
Aaron Denney
-><-