User: Password:
|
|
Subscribe / Log in / New account

Quotes of the week

So I'm doing an inverted reverse polish bisection search to find out which patch preemptively fixes clockevents-fix-resume-logic.patch. Try doing that with git, suckers.
-- Andrew Morton

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
-- Linus Torvalds
(Log in to post comments)

Gits

Posted Sep 13, 2007 2:12 UTC (Thu) by ncm (subscriber, #165) [Link]

I wonder where Linus got the idea that Monotone is "a horrible and unmaintainable mess". I expect he just made it up. The mass of stunningly ignorant remarks (the more ignorant, the more vociferous) posted in that thread makes me less inclined to try Git.

Linus played with Monotone before

Posted Sep 13, 2007 7:24 UTC (Thu) by khim (subscriber, #9252) [Link]

Linus first tried to play with Monotone - before he wrote Git. It was back when kernel developers tried to choose what to do when BitKeeper was pulled out... More about it here

So no, it's not the case where Linus just blindly badmouth other project - he actually tried to use it and some concepts looked good while some other were horribly bad.

P.S. Of course what Linus knows about Monotone is two years old info but I do not think Monotone was rewritten since then...

Monotone

Posted Sep 13, 2007 18:35 UTC (Thu) by ncm (subscriber, #165) [Link]

Actually, much of it has been rewritten.

I recall Ken Thompson unimpressed with Linux in 1999: "Microsoft is really unreliable but Linux is worse. In a non-PC environment, it just won't hold up." Much of Linux has been rewritten since then, too.

Ultimately, this is just trash-talk. It goes over well with the posse, but it's low. Brian Kernighan has never indulged.

Linus played with Monotone before

Posted Sep 15, 2007 19:06 UTC (Sat) by nlucas (subscriber, #33793) [Link]

Linus is badmouthing C++ use, not Monotone. In his view, C++ is unmaintainable, so Monotone is also, but remember that is his view, not the view of any Monotone developer, and never heard anyone who actually programmed in C++ criticizing Monotone code base.

Linus looked at Monotone when the project was just starting and most of the defects were things not implemented and/or not optimized yet. I would say 50-70% of the core git ideas come from what Linus saw in the Monotone design.

There are still many things left to do on Monotone, but now you can't compare the rate of development of a "Linus sponsored" project against low-profile ones as Monotone.

IMO Monotone is a great CVS, but it's not optimized for such a big project as the Linux kernel, and the developers are not in the final optimization steps yet, as they still have things left to do on the design.

Linus played with Monotone before

Posted Sep 16, 2007 4:31 UTC (Sun) by graydon (guest, #5009) [Link]

I tire of this discussion. It's such trash-talk. It doesn't even relate to our project. Our code is neither OO nor remotely messy or hard to maintain; it's in an idiosyncratic style, but I hardly think kernel developers should be throwing stones there. It's absolutely packed with staic and dynamic checking code, so you're unlikely to screw it up too badly if you make a mistake.

I'm not going to leap to defend C++. It's just a language. It's got a few advantages over C -- exceptions, destructors, strings, vectors and maps in the standard library -- but honestly it's still covered in warts. Show me a mature language that isn't. Languages are all tradeoffs. I picked it at random from an uninspiring set of choices.

Git is smaller and leaner because of a variety of hard-wired design decisions that we've intentionally rejected, just as they rejected our design decisions. Our history structure is richer -- including better merging -- we don't have as many trust failure modes, our disk, memory and network formats are decoupled, each is independently field-upgradable, and we compile and run on more toolchains and platforms than git. The rest of the discussion is just random flame rhetoric.

Gits

Posted Sep 13, 2007 15:16 UTC (Thu) by nix (subscriber, #2304) [Link]

It's your loss. git really is terribly good. (And no, I didn't agree with
a while pile of Linus's C++ comments, but ye gods! look at what he was
responding to!)

Gits

Posted Sep 16, 2007 12:07 UTC (Sun) by njs (guest, #40338) [Link]

> ye gods! look at what he was responding to!

That's the irony of his closing slam at monotone -- as a monotone hacker, I actually sympathize with most of his earlier comments, even if their phrasing is a bit over-the-top. Beating off the OOlier-than-thou crowd with sticks can get tiresome at times. It's unfortunate that a nice rant ends with what's clearly question-begging -- he uses monotone to support his claim that C++ makes projects unmaintainable, and he knows that monotone is unmaintainable because it uses C++...

Gits

Posted Sep 16, 2007 17:05 UTC (Sun) by nix (subscriber, #2304) [Link]

And yet, as others in this thread have pointed out, he uses KDE, which has
as time has gone by expanded the subset of C++ it uses until it
encompasses most of the language and libraries...

Yet KDE seems to be maintainable :)

Quotes of the week

Posted Sep 13, 2007 2:14 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Aw, c'mon, Linus: lousy schmucks have been writing Fortran in any number of languages for decades.
Of course, given that Gosling fixed all of C++'s weaknesses with Java...

Quotes of the week

Posted Sep 13, 2007 2:32 UTC (Thu) by lysse (guest, #3190) [Link]

...not to mention almost all of its strengths too...

Quotes of the week

Posted Sep 13, 2007 2:57 UTC (Thu) by kjp (subscriber, #39639) [Link]

I'm bigger than to get drawn into this flamewar :)

Quotes of the week

Posted Sep 13, 2007 3:16 UTC (Thu) by JoeBuck (guest, #2330) [Link]

But then Linus likes KDE, which is a big C++ framework. Go figure.

Quotes of the week

Posted Sep 13, 2007 4:19 UTC (Thu) by AJWM (guest, #15888) [Link]

KDE is an application (okay, it's a bit more than that, but...), Linus was talking about system level code (okay, he was actually talking about Git, but...)

Having worked on massive graphically-intensive and interactive apps (in particular, GIS systems) in both C and C++ (I was an early adopter; I still have nightmares about some of the code that cfront generated <g>), I'll take the latter for the application framework any day.

Most of the bottlenecks in such systems hinge on algorithm design rather than finely tuned optimization anyway; if you're retrieving 10,000 features from a database and then rendering them according to some parametric symbology definition, you need to focus on getting rid of some of those inner loops altogether rather than just making them faster. (And also splitting the task into multiple threads so that eg the graphics can be rendering while waiting on the next records from the DB, etc)

Desktop app code is just different from OS and backend utility code, the use cases are different, the priorities are different (eg user-perceived response time vs actual resource usage). Of course, as has been said before, one can write crappy code in any language.

Quotes of the week

Posted Sep 13, 2007 6:47 UTC (Thu) by MisterIO (guest, #36192) [Link]

I completely agree with Linus.C++ is an horrible language,and it really amaze s me how the most beautiful language, the C language, gave birth to such an horrible son.

Quotes of the week

Posted Sep 13, 2007 11:20 UTC (Thu) by jengelh (subscriber, #33263) [Link]

You do not have to use the bad things C++ offer. (libstdc++ for one...)
There are a few things in C++ that do make it useful, e.g. the new cast operators, and inheritance, and sometimes (but rarely) templates. Everything else you really do not need.

Quotes of the week

Posted Sep 13, 2007 15:22 UTC (Thu) by nix (subscriber, #2304) [Link]

The problem is that everyone's idea of which bit is useful differs from
everyone else's, so that while you may not pay for what you don't use, you
still have to *learn* it if you want to maintain code written by anyone
else.

In practice projects aren't written in `C++'; they're written in `some
subset of C++', and developers familiar with one subset can find it quite
a hump to get over to switch to some other project using a different
subset. (This is true of all large languages to an extent, and of course
every big project has its own internal APIs that you have to learn: but
this does increase the burden a bit more.)

Quotes of the week

Posted Sep 15, 2007 18:13 UTC (Sat) by pphaneuf (subscriber, #23480) [Link]

C does try hard to avoid people using different subsets, by the simple solution of providing so little that you have no choice but to have a very large common subset between different projects (some stuff is not that used, like C99 variadic macros, and other not at all, like trigraphs).

Me, I like type checking (no, this filetype_t enum is not compatible with that filemode_t enum, thank you!).

Quotes of the week

Posted Sep 15, 2007 21:06 UTC (Sat) by nix (subscriber, #2304) [Link]

Variadic macros do get used, but mostly in header files, often below
comments reading something like

/* Deep magic below. No user-serviceable parts inside.
You have been warned. */

Quotes of the week

Posted Sep 16, 2007 2:35 UTC (Sun) by pphaneuf (subscriber, #23480) [Link]

For sure, but in my opinion, this is also where something like the implementation of the C++ "function", "bind" and "lambda" go. They are incredibly easy to use ("function" behaves just like a function pointer, basically, only better), but yow, here be dragons in the implementation! I'm responsible for at least one pre-"function" implementation of that idea, I suggest using the standard one over implementing your own any day of the week!

While I am myself a C++ programmer, and I feel that nowadays, C has more or less been obsoleted by C++ for what I do (if you're careful about the subset you're using, you can even use it for most kernel programming, there are only very few specific exceptions, like the tendency of GCC of putting things it could put in the text segment in the data segment instead), I have to agree 100% with Linus there. C is harder, but forces people to think things thorough, and while that raises the barrier to entry for contributors, that's good.

It's kind of frustrating, because I'd like to make it easier for myself, but when it's easier, the idiots come out of the woodworks with braindead patches up the wazoo... It's one thing I've observed over and over, that it's simple to see what's easy to do, you'll find a bunch of them, all poorly implemented. Visual Basic made GUI applications easy, and PHP/ASP did the same for web applications, see what happened there...

Quotes of the week

Posted Sep 13, 2007 6:53 UTC (Thu) by feyd (guest, #26860) [Link]

good that Linus noticed him being a substandard programmer and doesn't use it :-p

Quotes of the week

Posted Sep 13, 2007 16:33 UTC (Thu) by Nick (guest, #15060) [Link]

Ahh, Linus... I bet you thought you'd finally seen the end of
"let's rewrite your project in C++" crowd, seeing as they seem to
have finally been stamped out from lkml.

It's like 1999 all over again :)

But there already is a Free kernel in C++.

Posted Sep 13, 2007 18:29 UTC (Thu) by dmarti (subscriber, #11625) [Link]

For anyone who wants a kernel hacking project in C++, there's always K42 .

C++ ... iokit?

Posted Sep 23, 2007 23:25 UTC (Sun) by mattmelton (subscriber, #34842) [Link]

imo, and I've seen it stated many times, Apple's IOKit trumps linux in driver development.

this is probably my 5th comment announcing linus' increasing irrelevance to the rest of the world, but it's comments like this - a reiteration of an older one i know - that showing he's not willing to adapt to the needs of the other type of user... the commercial developer.

Linux needs a native C++ runtime to allow an easier development cycle (linux-macos drivers!)... we're bitching we cant get drivers out on time, but we're not exactly helping the hw developers!

iirc, someone did write a cpp runtime and model for 2.4... shame it didn't catch on.

C++ ... iokit?

Posted Sep 24, 2007 20:55 UTC (Mon) by nix (subscriber, #2304) [Link]

Your terms are sufficiently vague as to make it unclear what you're
talking about (Linux *has* a native C++ runtime library, it's called
libstdc++).

However, if you're suggesting what I think you are, you seem to think that
adding the necessary magic to allow kernel drivers to be written in C++
will somehow magically both make `commercial developers' happy, and allow
a single driver to be used that will work with both Linux and MacOS X.

Both these assumptions are untrue.

Firstly, commercial developers mostly don't care about drivers. They're
writing applications: hardware support is way below anything they care
about. Some might care about one or two specialist pieces of hardware, and
writing a so-so driver for one piece of hardware, unless it's viciously
complex, is not terribly hard. Throwing C++ into the mix won't make it
easier.

Secondly, C++ is not magic compatibility sauce. Adding a C++ abstraction
layer to the kernel will have numerous costs --- of which the *smallest*
is the oft-quoted one that C++ does too much behind your back. Much more
significant is that C++ coding works best when everything is wrapped into
objects, which means that huge numbers of (mostly small) abstraction
layers would need to be written to wrap up the existing internal C
interfaces with a C++ facade, and all these layers would need to be
maintained --- yet the people who maintain the C code are mostly not C++
programmers, so wouldn't do it themselves. So the C++ layers would be
broken much of the time.

Thirdly, adding that C++ abstraction layer certainly won't help joint
Linux/MacOSX drivers get written. What you need there is an abstraction
layer to map between the Linux kernel and the (quite different) Darwin
kernel, and that is a *big* job. Feel free to try it: I predict you'll
fail. The kernels are too different and the Linux kernel at least is
changing way too fast to make this remotely practical. Even if it worked,
and even if the runtime overhead of this abstraction layer were nil (a
pipe-dream), such drivers would have the lowest common denominator
problem: they couldn't take advantage of anything Darwin or Linux could do
unless it was in both, which means they'd stick out like sore thumbs on
both OSes.

(And Linus is increasingly irrelevant? You *are* a troll, aren't you? A
troll subscriber, oh dear.)


Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds