By: Richard Cownie (tich.delete@this.pobox.com),
Room: Moderated Discussions
anon (anon@anon.com) on 6/7/10 wrote:
---------------------------
>Richard Cownie (tich@pobox.com) on 6/7/10 wrote:
>---------------------------
>I don't agree. I don't agree correctness and performance are less important in
>other applications or libraries.
You're entitled to your opinion. But it's hard for me
to imagine that interpeted/JIT languages like Java and
its derivatives could have become as popular as they
are if most code in most apps was really performance-
critical. From what I've read, even the latest highly-
tuned JIT Java stuff goes about 2x slower than C++.
As for correctness, it's serious when an app crashes;
but it's far more serious when an OS kernel crashes.
And it's harder to debug kernel problems than most
app problems, which gives kernel developers a strong
(or if you prefer, an even stronger) incentive to get
it right earlier in the development process, in design
and code review.
>And productivity of programmers does not become
>_less_ important when you have hundreds maybe thousands of >developers working on
>a code base (most of them are paid, by most surveys).
I was unclear. I meant "productivity" in the narrow
sense of being able to write a lot of functionality
per man-month. But in kernel development (and development
of other large/highly-entangled/parallel systems) most of
the developer time goes on debugging obscure interactions,
rather than on actually writing code. So the choice of
language (and coding practices) matters only inasmuch as
it affects the speed with which such obscure interactions
can be understood and fixed. It's not clear that the
features of C++ offer much help with that. What matters
more in the linux kernel would seem to be the ruthless
rejection of code that doesn't meet high standards (and
a willingness to throw out inadequate old code).
>I think these attributes are more due to good design than >choice of language.
Yes, and as I said, the key is to get really good people.
The main advantage I see for C++, under most circumstances,
is that, with good design, it can allow you to get by
with substantially fewer lines of code, and thus with
substantially fewer people. And fewer people means both
*much* less time spent on interactions and meetings; *and*
a much better chance of assembling a team that's 90%
excellent rather than more normal large teams which are
20% excellent (or less).
However, the way C++ achieves that trick of more
functionality with less code is largely by doing a lot
of clever stuff implicitly. And in the context of an OS
kernel, that implicit stuff may well be confusing,
memory-hungry, and slow, unless you're really really
rigorous. [Aside: I just got done fixing an issue in a
big C++ app where a bunch of code was doing unnecessary
implicit copying of hashtable iterators. You just
couldn't have that kind of issue in C].
---------------------------
>Richard Cownie (tich@pobox.com) on 6/7/10 wrote:
>---------------------------
>I don't agree. I don't agree correctness and performance are less important in
>other applications or libraries.
You're entitled to your opinion. But it's hard for me
to imagine that interpeted/JIT languages like Java and
its derivatives could have become as popular as they
are if most code in most apps was really performance-
critical. From what I've read, even the latest highly-
tuned JIT Java stuff goes about 2x slower than C++.
As for correctness, it's serious when an app crashes;
but it's far more serious when an OS kernel crashes.
And it's harder to debug kernel problems than most
app problems, which gives kernel developers a strong
(or if you prefer, an even stronger) incentive to get
it right earlier in the development process, in design
and code review.
>And productivity of programmers does not become
>_less_ important when you have hundreds maybe thousands of >developers working on
>a code base (most of them are paid, by most surveys).
I was unclear. I meant "productivity" in the narrow
sense of being able to write a lot of functionality
per man-month. But in kernel development (and development
of other large/highly-entangled/parallel systems) most of
the developer time goes on debugging obscure interactions,
rather than on actually writing code. So the choice of
language (and coding practices) matters only inasmuch as
it affects the speed with which such obscure interactions
can be understood and fixed. It's not clear that the
features of C++ offer much help with that. What matters
more in the linux kernel would seem to be the ruthless
rejection of code that doesn't meet high standards (and
a willingness to throw out inadequate old code).
>I think these attributes are more due to good design than >choice of language.
Yes, and as I said, the key is to get really good people.
The main advantage I see for C++, under most circumstances,
is that, with good design, it can allow you to get by
with substantially fewer lines of code, and thus with
substantially fewer people. And fewer people means both
*much* less time spent on interactions and meetings; *and*
a much better chance of assembling a team that's 90%
excellent rather than more normal large teams which are
20% excellent (or less).
However, the way C++ achieves that trick of more
functionality with less code is largely by doing a lot
of clever stuff implicitly. And in the context of an OS
kernel, that implicit stuff may well be confusing,
memory-hungry, and slow, unless you're really really
rigorous. [Aside: I just got done fixing an issue in a
big C++ app where a bunch of code was doing unnecessary
implicit copying of hashtable iterators. You just
couldn't have that kind of issue in C].
