
Linus vs C++, again - hernan7
http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2
======
cageface
As I get older and grumpier I tend to appreciate Linus' point of view more and
more. It's easy to get swept up by arguments of the expressiveness of a
language, particularly in small examples. However, I think in the long run
it's better to have very explicit code. The less jumping around and inference
I have to do to figure out what a block of code does the more likely it is
that I understand it and that I can quickly verify that it does what it needs
to do. If that makes code a little more verbose I think it's usually still
worth it.

~~~
mojuba

       write(fd, buf, size);
    

Can you list all the caveats, possible side effects, reasons of failure of
this simple C function call? Hint: remember, fd can be a file, as well as a
NFS-mounted file, pipe, network or local socket, FIFO, device, etc. Hint2: I
doubt anyone can give a comprehensive description of the possible consequences
of this call.

Bottom line being, C can be incredibly hard to understand, or C++ can be
clean, succinct and straightforward. Personally, I'm for the second, although
I know probably 99.9% of all existing C++ code is just awful.

~~~
forgottenpaswrd
Hard to understand?

Really? write a block of data of size on bytes "bytes" on the file-pipe-
network... pointed by the file descriptor "fd"??

It is extremely simple to understand, it makes a very simple thing, always
right. I doubt you can make it simpler.

I have been using this all my life for NFS-mounted file, pipe, network or
local socket... Never had any problems, and I have done very complex things.

Of course, in c++ you will use the very same function under a different
calling, you can make it part of a class, whatever, but is going to use the
same backend internally(because the OS only uses one), only that you can add a
lot of abstraction(complexity) from c++ code.

Of course C++ could be clean, but the question is: what will happen if we make
it into the kernel?. Linux thinks it won't work. I agree with him.

~~~
tptacek
He's just pointing out that the first argument to write() is the exact same
kind of abstraction as the "foo" in "foo->perform()".

~~~
wvenable
C++ is one of the few languages where in "foo->perform()" the -> and () can be
something completely different than what you expect. There's almost nothing in
that simple statement you can be completely sure of.

~~~
NickPollard
They can be, but they shouldn't be. Operator overloading is useful when you
want to do something that is semantically similar but implementationally
different.

Even mathematics has different processes for the same operators on different
types. If you see 'a * b' you should be able to assume that it's multiplying
two variables, but if those two are real numbers it's different than if
they're two matrices of real numbers, for example.

Implementing a Matrix class that overrides * to imlement matrix multiplication
seems perfectly fine for me - It's just the same as implementing a Multiply(a,
b) method. Just as someone who writes a Multiply method could in theory make
it do anything, it is assumed by reading the word 'Multiply' that that is what
it does. Just as someone who makes a Multiply() function that does something
other than multiply is an idiot, so is someone who overrides operator * to do
something other than multiply.

~~~
wvenable
The STL overrides the bit shifting operators for output and the deference
operator for accessing the current item in iterators.

------
desponsible
> _One of the absolute worst features of C++ is how it makes a lot of things
> so context-dependent - which just means that when you look at the code, a
> local view simply seldom gives enough context to know what is going on._

Good point. Very good point.

Having spent few years developing for the Linux kernel I can say that the most
cluttered code I dealt with was the network stack. And exactly because it was
done in C++-ish way. It makes an extensive use of tables of function pointers,
which is basically an analog of a C++ virtual table. A socket depending on its
type would get a pointer to a different table and that table would define the
actual flow, say, of the recv() call in the kernel. The concept is very
elegant, and it translates into a more compact code, but it also makes tracing
the code by hand hard.

So, yeah, Linus got a point there :)

~~~
stcredzero
I started designing a language where you had lexically scoped "contexts" to
specify the meanings of words. In general a package/library would be a
context, and could declare its dependency on other contexts. Any words with
conflicting interpretations would have to use its full global specifier to
compile.

~~~
chromatic
Perl does this, Perl 6 especially.

~~~
alnayyir
Sadly x86/arm/mips/sparc/power processors aren't Perl machines and Perl6
thusly can't be used to make a kernel for a Unix derivative.

~~~
stcredzero
One could probably get Scheme to do this and use it to make a kernel. But what
would be the point of making it a Unix machine then? Make it a Scheme machine.

------
johnrob
I think Linus is making the right call here. At a 10,000 foot view, the real
argument is about style. The style of C happens to be one that lends itself to
easier groking of code amongst hundreds of developers (as he illustrated
well). Sure, C++ may be a more modern tool with some more powerful features,
but using it may not be the best thing organizationally.

This kind of thinking is refreshing and is seemingly rare in classrooms.
There, you mostly learn 'what to use' and not 'how to determine what you
need'. Just as I'd expect, over design is the most consistent issue I come
across in co-workers' code. 'Write code to be read' is a metric that seems to
have gone out of style. Code that does X-Z-Y should, in my opinion, look like
code that does X-Y-Z. Otherwise the reader has to invest time and energy
figuring out the design. There had better be a good reason to justify a hard-
to-grok design, because it will continue to be a drain for the life of the
project.

------
j_baker
I actually rather like this quote:

    
    
        Anybody can say "yes". Somebody needs to say "no"

~~~
ecaradec
it's interesting to note that open source works in reverse of entreprise where
any manager can say no, but only the boss can say yes...

------
rpledge
Linus has a touch of what I think makes Steve Jobs great: the ability to say
no and stick by those convictions. No argument from me that Linux is wildly
successful and one of the most important tech developments in the last 10
years.

However, I always cringe when I read some of his comments that seem to reject
any element of forward progress. While C++ certainly has its share of issues,
Linux will never evolve if the programming paradigm stays in the 60s. My gut
feel is there is a lot of opportunity to do better over the next ten years.

~~~
hristov
It is very silly to say that something is bad because it started a long time
ago. I do not see how any of the modern languages of the 21th century would be
even remotely suitable to write an OS kernel with. Considering that most of
those languages are at least partially interpreted and require GCs, a kernel
written in them would be painfully slow.

Just because something is old does not mean it is worse, and just because
something is new it does not mean it is better.

If you think about it, the modern languages are clearly made for programming
higher on the stack (i.e., at application level). That makes a lot of sense.
After all most programming is done at the application level, and it would make
sense to write a language that makes that type of programming easier. And of
course many modern languages are very successful in that respect. But it is
silly to assume that just because they are successful at the application level
they would make good kernel programming languages.

The reason why C++ is the language being considered is that it is also a
relatively low level language which means that it can potentially replace C
for kernel level programming. That of course does not mean that it should, and
Linus does a good job of pointing out the issues with C++.

~~~
ComputerGuru
>. I do not see how any of the modern languages of the 21th century would be
even remotely suitable to write an OS kernel with.

Not true. You just have to be smart enough to implement the stack and
structure properly. Have a look at some of the experimental operating systems
out there. Singularity is especially worth a look.

~~~
Daishiman
Yes, and still hasn't solved its performance problems that span all of the
OS's functionality. Performance is something we might not care about at a high
level, but on a kernel it's a first priority, and a very difficult problem to
solve.

------
xpaulbettsx
Let's put it this way without any subjectivity: every production kernel that
you folks use every day is written in C. NT is, Solaris is, Darwin is, and
Linux is.

Not _one_ production-level kernel that is in wide use as a general-purpose
operating system uses C++. I don't believe that to be a coincidence.

(Nitpicker's corner: Darwin's device tree subsystem is written in Embedded
C++, an extremely cut-down version of C++ that's more like "C with classes"
than C++).

~~~
shin_lao
That's perhaps because all these kernels were written before C++ exists? The
first C++ standard is from 1998, and stable STL/C++ support is even more
recent.

FYI : in NT many device drivers are written in C++

------
dman
I actually liked his point about context very much. In fast moving projects
changes are visualised in terms of diffs, and the closer the code is to what
will be executed, the more chances that obvious flaws will be caught. btw
related discussion in an older thread -
<http://news.ycombinator.com/item?id=1318489>

------
huherto
It is funny how a very simple and innocent looking question by "newbie"
started a big discussion. It is like watching somebody drop a candle in a bed.

    
    
        Can you use C++ in Linux kernel?
        In windows kernel you can, with some restrictions.

~~~
viraptor
What are the chances he's just a troll? A simple google search would show many
similar debates.

I'm pretty sure you could cause the same in a month or two, by asking "I know
there are projects using different languages to create kernel modules - even
crazy ones like haskell. Can I use C++ in the kernel?"

~~~
steveklabnik
Newbies? Not Google before asking a question on a newsgroup? What's the world
coming to?

It's gotten to the point now that when I can't find a question asked
previously, I start getting nervous, and 3/4ths of my initial post to a group
starts off by explaining how I really did Google, honest! This is what I
tried, and I still couldn't find anything, so if it's been asked before,
please just point me to the right place, sorry!

------
yonilevy
There's not much "Linus vs C++" in there (except for several random bashes
with nothing to back them up). It's mostly Linus sharing his POV as the
maintainer of the kernel as to why C++ would be harder to work with in a
project that has many contributors due to code being more context dependent
(i.e member functions, function overloading).

------
shin_lao
There are so many large scale C++ projects that prove Linus wrong every day.
One of them, you probably use it every day. hint: it's a search engine.

Whatever language you use, you need rigor and diligence. You need to manage
the project and follow up on developers.

You need to agree on a subset of the language, that will become your local
dialect. I'm pretty sure that Linus doesn't accept "any C source code".

C++ has got more features than C. That's neither intrinsically good or bad.

I could argue about the merits of templates and what they enable you to do,
and someone would tell me "it's hard to understand".

Well, any language you don't know is "hard to understand". C++ is not "C with
classes" anymore. It's something else. It's a different language.

In the end what _really_ matters is the quality of the developers and the
quality of your process. The language is just how you implement your concepts.

~~~
eps
Main problem with C++ is non-technical. Based on some experience interviewing
a dozen people a week for several months, C++ programmers tend to routinely
overestimate their proficiency with the language, while C programers tend to
have the opposite self-assessment. To put it differently - on average C++ devs
are cocky, eveyone is a guru and C devs are basically modest.

~~~
shin_lao
I agree with you. I often interview people who consider themselves "C++
expert" but struggle to use the STL's algorithms correctly.

------
sliverstorm
This leaves me with a burning curiosity.

Linus, if you could change the Linux kernel to another language, would you?

In a perfect world (i.e. migration concerns and such aside), if you were
changing the Linux kernel to another language, what language would you choose?
If you feel C is still the #1 choice, what would the #2 choice be?

~~~
huherto
I would like to hear Linus opinion on Go.

~~~
mkramlich
Or D.

I had thought D was designed to be, among other things, a reasonable next-
generation replacement for projects that would otherwise use something like C.

~~~
steveklabnik
Yep. I'm actually contributing a bit to an exokernel written in it.

------
ecaradec
Wow, Linus is getting older : he didn't flame the poor guy down.

I feel a bit concern that Linus don't write code anymore but still decide on
how code is written, etc... Happily, he has some experience.

Linus has good reasons, nobody is going to rewrite linux in C++ anyway, this
has been debated to death.

Why I am still loosing my time commenting on this ?

------
dan00
It's right, that in theory I can't know what a C++ function call means.

But that's also the case for C. In C I can assign a function pointer to a
variable. When the function is called through the variable, than I don't know
which function is called.

Almost never the language is the problem, but their usage. There's always
context, and the quantity depends mostly on the complexity of the software.
And regardless which language you use, you have to define a convention for the
usage of the language, also in C.

~~~
shoover
Interesting point about function pointers. Maybe Linus is saying (in many more
words) to use virtual dispatch only in appropriate places but not as a basis
for an entire language? He would be in disagreement with every language
designer who has added some kind of first class dispatch or pluggable modules.
Not that such disagreement would be surprising, but that seems to be what he's
saying. He suggested looking to other languages for GC and concurrency
support, but in that thread I didn't see any desire for dispatch or modularity
beyond what C offers.

------
d0m
I've seen some pretty clean C++ code and some ugly C code. I think what's
important is how a programmer use a language rather than what language he
uses. I mean, if someone enjoy writing clever one liners, he/she will probably
do it in all languages, might it be Perl or C. However, the important point
here is that C does a good job and the programmers are used to it and like it.
THEY, people that submit patches, like it, period.

------
snorkel
Even if the Linux kernel were rewritten in Erlang and it won't change the fact
the vast majority of *NIX systems level code is entrenched in C. The most
popular LAMP stack ingredients are also written in C. Face it; it's a good
language.

~~~
eru
Non sequitur?

------
mkramlich
Regarding C and C++ I sometimes think of them like this:

If you want a language that's like C but better, tough, just use C.

If you want a language that is better than C, do _not_ use C++.

------
pmjordan
It makes a lot of sense if you think about it as optimising code readability
for the case of seeing it through the lens of

    
    
      diff -pu -c 3
    

which is basically what Linus does all day. This also implies that the
argument has little meaning in the context of projects that aren't comparable
in scale (both code size and contributor pool size).

------
matthavener
Could Linux explain spinlock.h then? Depending on which _type_ you give to the
PICK_OP macro, it performs a different operation. Its basically a C template.
Seems a bit weird to complain about type context specific code and then use it
in one of the most important parts of the kernel..

Here's the code: #define TYPE_EQUAL(lock, type) \
__builtin_types_compatible_p(typeof(lock), type _)

#define PICK_OP(op, lock) \ do { \ if (TYPE_EQUAL((lock), raw_spinlock_t)) \
__spin##op((raw_spinlock_t _)(lock)); \ else if (TYPE_EQUAL(lock, spinlock_t))
\ _spin##op((spinlock_t *)(lock)); \ else __bad_spinlock_type(); \ } while (0)

------
jheriko
"And the best way to avoid communication is to have some "culture" - which is
just another way to say "collection of rules that don't even need to be
written down/spoken, since people are aware of it". Sure, we obviously have a
lot of documentation about how things are supposed to be done, but exactly as
with any regular human culture, documentation is kind of secondary."

This is so true - I have zero problems with context sensitivity and difficulty
reading C++ if its all consistently done according to my prefered standards
(which I mostly inherited from an especially well managed employer), avoiding
the "bad practices" that introduce these problems like namespaces and such.
Yet if I dive into some poorly organised and written code I can easily spend a
whole day debugging a trivial problem - simply because the time is wasted
trying to understand what is happening.

The sad truth is that the latter case is more common - its not C++'s fault
though (although it could just /not/ try and provide every imaginable feature)
- its more bad management than anything else. Though I can't help but wonder
if that is just unavoidable for inherently difficult to manage projects like
this...

------
albertzeyer
Many of the arguments he gave are mostly just based on the fact that there
aren't that much powerful tools around which can do what he requests (and what
of course is something you want to have).

Like grepping for all usages of some function. Or getting some code snippet in
a way that it comes with all necessary context. Or whatever.

Though, with recent development (particularly on clang), these things may
become much more easier. Of course, you will not be able to do magic things
(like checking at what places what particular virtual function implementation
is called exactly) but it will be trivial to check for example all calls on
std::string::size etc.

In the same way, you could also implement some small helper tool for sharing
code snippets which will add some meta information about the context. So that
when you share some code like 'a += "foo";' it will contain the meta
information that a is an std::string.

LLVM/clang is anyway also kind of a disprove to his arguments about
maintainability. I would say that one reason that working on/with the
LLVM/clang code is so much nicer compared to working on/with the GCC code is
because it is written in C++.

~~~
acqq
You're wrong. I've actually had to maintain the big C++ projects. That have
Zillion of classes, fully different, but each one has more Read(), Write()
functions. Some are virtual, some are not. Some have two parameters, some have
three, some four. And they even do fully different stuff! Which Read() will be
called depends on anything and everything. I claim you just can't figure out
what some piece of code does in any other way than by actually single-stepping
through the debug build. Any time the debug build pieces of code don't reflect
the source, you're fully lost. Note that Linus usage scenario is "read the
chunk of code outside of the whole source base" and you argumenting "if I use
some hypotetical very clever tool the tool would maybe able to show me what
some line in the chunk of code actually does." I've actually made some "very
clever tools" since some twenty years ago. And I wouldn't want to have to use
them on the really big projects.

~~~
albertzeyer
Btw., I was describing basically two tools:

1\. Some replacement for grep to search through the code. Where you can search
for "std::string::size()" or sth like this and it will show you exactly all
calls to that function. This tool is really trivial to implement. (Probably
someone has done that already.)

2\. Some tool which adds some metadata to a code snippet. Which would just add
exactly those information of the context which is needed to understand the
snippet. I.e. this fully depends on your code. If it is bad code with full of
macros, many operator overloadings and other tricks, there will be a lot of
context around, otherwise, not.

------
protomyth
I know no tool would solve every problem, but I can't help but wondering if
someone developed and IDE that truly got C++ would that allow C++ to be used
by more projects. Seeing grep referenced for code searches reminds me that
grep has no knowledge of the context of anything in a searched file. It almost
seems like C is the only choice if you can't go beyond context-less tools.

//a grep specifically for C++ code - hum

~~~
rpledge
Are you implying C++ isn't widely used? I'm sure that isn't what you truly
believe...

~~~
protomyth
oh no, I know it is widely used (Visual C++ and the ilk). I was more thinking
in these huge C open source projects.

------
MarkPNeyer
C as a context free language? Bullshit. How many global variables are there?
How many functions with ridiculous names like htons?

Edit:

I realize that "context free language" was a poor choice of words; i meant it
in the sense that linus did - his claim that you can 'look at a piece of code
and understand what it does' is laughable in the face of accepted c
programming styles.

~~~
j_baker
I'm not really sure you understand what a context-free language[1] is. I
suppose global variables can be seen as being context-sensitive, but functions
with weird names definitely don't qualify a language as context-sensitive.

[1] <http://en.wikipedia.org/wiki/Context-free_grammar>

~~~
koenigdavidmj
No, what he means is that something like

    
    
        foo * bar;
    

Can mean two different things. If foo is a defined type (typedef int foo, for
example) then that declares a variable bar of type foo. If it is not, then
we're multiplying variables foo and bar.

~~~
j_baker
Yes, that is context-sensitive, but it's pretty tame. First of all, if I look
at that, I can tell it's probably a pointer. After all, it doesn't make much
sense to multiply two variables and then not do anything with the result, does
it?

On the other hand, it can mean a variety of things in C++. Are we multiplying
numbers? Is foo or bar an instance of a class that has the * operator
overridden? Is there a global overload of the * operator? Are we declaring a
pointer?

~~~
kenjackson
But in a well-written program the use of overrides would make sense. Just as
much as this function: ExitProgram(); should be clear in the context of a
program. Now it's possible that this function actually creates a new process
that then plays tic-tac-toe. But in a decent program, it will do its best to
be consistent with what you expect. Likewise, if I see A * B, I expect that
we're multiplying A and B. What does multiplication mean? Depends on the
application, but I expect it to make sense.

And with a decent IDE you should easily be able to get the def for the '*',
just like you'd get the def for any other function.

The problem isn't in the C++ language, but rather the C expectation that many
developers have.

------
yock
I'm immediately skeptical of people who think modularity, inheretance, and
polymorphism are a bad thing. Linus never comes out and says as much, but by
indicating that he doesn't want to jump around to learn how a bit of code
works he's implying it by desiring as few dependencies within code as
possible.

I certainly apprecate Linus' genius and the revolution he brought to
computing, but we live in a different world than when he first took up C
programming. Computers are far more capable than they were decades ago and
we've taken advantage of that by making code much more flexible than in years
past. The result is far more code reuse than early OO programmers ever thought
possible.

Could this possibly be the worlds first programmer-generation gap?

~~~
Daishiman
Who said C isn't modular? You're confusing language features with programming
paradigms. C can and is modular and flexible. Objects are not just a language
construct A struct with corresponding functions is just as much of an object.
And he didn't claim those were bad things. He claimed that the context
dependency, the massive size of the language, the different implementations,
etc., contribute to an environment that's not good for kernel development. On
that count, I must agree.

------
stcredzero
_That is a huge problem for communication. It immediately makes it much harder
to describe things, because you have to give a much bigger context. It's one
big reason why I detest things like overloading - not only can you not grep
for things, but it makes it much harder to see what a snippet of code really
does._

I think this is a limitation of our using flat text to program in. So long as
our primary means of communication is linear speech and flat text, we will
have this communications overhead. Collaborative systems that display the
context to all concerned can overcome this. In fact, this is already
happening! (Exercise for reader.)

~~~
JustinSeriously
I came here to quote that same piece, but for a different purpose. I am in
complete agreement with him.

I think writing grep-friendly code is a good thing. I do my best to make all
my Perl code easily grepped, it just makes debugging infinitely easier.

~~~
protomyth
Would a search tool other than grep change how you write code?

~~~
JustinSeriously
Probably not. I just said "grep" because it's such a basic standard, I really
meant "easily searchable from a command line."

~~~
stcredzero
What about a syntax-aware search? If this were as responsive as grep, wouldn't
that be better? I think so. I use one in Smalltalk all the time.

------
ananthrk
Somewhere down the list, someone asks about Go

 _Hey, I think Go picked a few good and important things to look at, but I
think they called it "experimental" for a reason. I think it looks like they
made a lot of reasonable choices.

But introducing a new language? It's hard. Give it a couple of decades, and
see where it is then.

Linus_

([http://www.realworldtech.com/forums/index.cfm?action=detail&...](http://www.realworldtech.com/forums/index.cfm?action=detail&id=110624&threadid=110549&roomid=2))

------
jongraehl
Because the Linux kernel is so important, and so difficult to replace, people
will put up with whatever language inconveniences they must in order to get
their contribution accepted.

Therefore, I don't see Linus' choice as having any larger significance.

I already know that C++ is a vastly superior language to C for small to medium
scale programs where computational time+space efficiency is paramount.

~~~
_0ffh
Come again, please? All computational time+space efficiency of C++ comes from
the "C", not the "++" part!

~~~
jongraehl
You misunderstand - I'm just qualifying the experience I'm speaking from.

I've used both languages, but only when time and space efficiency can't be
sacrificed.

I've never worked on a large program in either.

Under those conditions, I know from experience that C++ is better. It allows
me to abstract safely (I benefit from some compile time type-checking) with
little or no run-time cost.

------
kqr2
Original Linus rant on C++:

<http://lwn.net/Articles/249460/>

------
henry_flower
Is that Linus post originally comes from some mail list? What is the name of
the list? (google gives me only links to realworldtech, which is weird)

~~~
Symmetry
The post is from the forums attached to the realworldtech website.

------
Shorel
He falls in the same mistake of many people: thinking that because there's
operator overloading in the language, you have to use it. The same for
templates.

Most successful C++ projects never use some features. Some even use C macros
instead of templates, like wxWidgets. It both works and compiles fast.

------
known
Is there anything in C++ that I couldn't do in C from Application pov?

------
johnastuntz
Linus rules! That's right, C ain't for everything

------
Daniel_Newby
This rings hollow. It's like saying "C++ feature X can go horribly wrong when
used without adult supervision, therefore C++ is unusable." This is especially
silly coming from someone who favors a professional stunt language like C.

If somebody uses too much overloading, reject their patch. If somebody makes a
template tarpit, abuses operator(), or gets too fancy with operator
overloading, send it back to 'em.

Context dependency bad? I _like_ having the superclass define a contract so
that you can ignore which subclass is being used. And C++ even rubs your nose
in the name of the superclass, to avoid duck typing (which Python/Ruby use
with near impunity anyway).

Polymorphism also gives you what amounts to functional programming without
touching C's awful function pointer syntax. I suspect a lot of Linux code uses
baroque switch/case or "if" statements just to avoid the pain of function
pointers.

Edited.

~~~
dkarl
I think his main point vis-a-vis C and C++ is that the kernel has a unified C
culture and adding C++ would import a bunch of different C++ cultures. As a
C++ developer in a C++ shop, I can appreciate this. Our shop has a very solid
and consistent C++ culture. We can read each others' code because we all use
the same language features and coding style. You can't do coherent C++
development without having this unity. The only way to develop a unified C++
culture for the Linux kernel would be for it to be grown slowly over time,
starting from a small group of developers, the same way the kernel was. That
can't and won't happen. If C++ is allowed into the kernel, a bunch of
extremely skilled C++ programmers from different C++ cultures will start to
contribute kernel patches written in C++, and it will be a tower of Babel.

However, I don't buy his argument that C++ is unsuitable because it's
linguistically a high-context language. Part of this problem of context is
solved by having disciplined, humble coders who know the limits of human
intelligence. (I do not think these are new requirements that would exclude
existing kernel contributors. C has, and the kernel uses, _macros_.) Part of
the problem is solved by having a unified culture. The rest of the problem of
"context" in C++ is really what would be called "state" in C, and of course
you can't read state in the text of a C program. If you could magically create
a unified and disciplined culture of C++ usage in the kernel, it would be
fine. But that can't happen, so C++ is out of the question.

~~~
Daramarak
Thanks, nice to read a sober judgment of the situation. As a both a C and C++
programmer I really appreciate your point. I would however argue that some
effort should be done to enable the possibility to create some common culture.
I am sure that some unbiased eyes could find subprojects where c++ (or other
compiled oo/functional languages) would be better suited than c. I strongly
believe that the paradigms all have their uses, and that in time the Linux
project would be more powerful if it used the technology available. After all,
isn't that one of the great strengths of openness?

