Linus vs C++, again • Hacker News Board

Re: Linus vs C++, again

#151

Post by kscaldef » Fri, Jun 11, 2010, 6:47 AM UTC

c00p3r wrote: post #150

kscaldef wrote: post #69

Earlier quoted context omitted.

I think ActiveRecord has exactly the sort of problems that Linus describes, when you get to large codebases and large teams. For example, what does 'save!' do? Well, it doesn't just update the row in the database; it also runs any validations on the object, and any before/after validation/save hooks. So, in general, you need that context to know whether a patch that updates something is correct or reasonable. And if…

"a tool that make simple things easy" - thank you for this =)

I was quoting Larry Wall who said that a programming language should "make easy things easy and hard things possible". (Or something close to that... the internet seems a little uncertain on his exact wording.)

Re: Linus vs C++, again

#152

Post by c00p3r » Fri, Jun 11, 2010, 7:17 AM UTC

j_baker wrote: post #2

I actually rather like this quote: Anybody can say "yes". Somebody needs to say "no"

It corresponds to Brooks's idea (law?) that one architect (with view) is good, while many is a disaster.

Re: Linus vs C++, again

#153

Post by shin_lao » Fri, Jun 11, 2010, 7:39 AM UTC

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.

Re: Linus vs C++, again

#154

Post by Daramarak » Fri, Jun 11, 2010, 7:51 AM UTC

dkarl wrote: post #76

Daniel_Newby wrote: post #51

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…

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. T…

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?

Re: Linus vs C++, again

#155

Post by loup-vaillant » Fri, Jun 11, 2010, 8:12 AM UTC

sophacles wrote: post #138

joe_the_user wrote: post #117

Earlier quoted context omitted.

If the kernel was written to the common standards of Ruby code, it would come apart completely. -- > That doesn't mean Ruby is bad. Ruby is great. ActiveRecord is a great model for MVC web development. The standards of Ruby aren't good for more performance-oriented, "hard core" development - Ruby's a pretty mature language but Rubinius, the Ruby-in-Ruby project still isn't production-level. One might guess that compi…

There really wasn't much in terms of "good and bad" overall, just "good and bad" for Linux. At the end he says (paraphrased)"I'm not saying this is for every project, but if you are going for more than C, skip C++ and go for ".

Tu put it more plainly, he said that for any possible job, C++ is never the best tool for it.

  ∀job, ∃L | L(job) > C++(job)

This, plus stating that C++ is very complicated amounts to say that C++ is bad. Because even if C++ is "good enough" for a wide range of jobs, it's complexity makes it longer to learn than several, simpler, more specialized languages.

My personal opinion is that C++ is best only when legacy code is involved, or when the team just won't learn other languages. I can understand them. Learning C++ is such an investment that they are more likely to "throw good learning after bad", or may think that learning another languages will be as difficult as learning C++.

I may change my mind when I bother to look at LLVM or V8. Perhaps.

Re: Linus vs C++, again

#156

Post by dan00 » Fri, Jun 11, 2010, 8:14 AM UTC

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.

Re: Linus vs C++, again

#157

Post by [deleted] » Fri, Jun 11, 2010, 8:19 AM UTC

nitrogen wrote: post #114

rpledge wrote: post #34

Earlier quoted context omitted.

Great way to edit my comment, what I actually said was: > Linux will never evolve if the programming paradigm stays in the 60s C is a great language, but I firmly believe that OOP creates more maintainable code that is more robust. Sure, a simple C program is easy to understand, but the kernel isn't an easy program. Don't get me wrong, C++ has major downsides, but C isn't a magic bullet.

The kernel does use object-oriented paradigms.

[deleted]

Re: Linus vs C++, again

#158

Post by Daramarak » Fri, Jun 11, 2010, 8:23 AM UTC

huherto wrote: post #6

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.

Yes, but it is good to have such debates. It allows the Linux community continuously to reassess its choice of a c-only environment. Such introspection is necessary, and when people are ready to move on, I think the community will.

Re: Linus vs C++, again

#159

Post by [deleted] » Fri, Jun 11, 2010, 9:18 AM UTC

kscaldef wrote: post #151

c00p3r wrote: post #150

Earlier quoted context omitted.

"a tool that make simple things easy" - thank you for this =)

I was quoting Larry Wall who said that a programming language should "make easy things easy and hard things possible". (Or something close to that... the internet seems a little uncertain on his exact wording.)

[deleted]

Re: Linus vs C++, again

#160

Post by NickPollard » Fri, Jun 11, 2010, 9:25 AM UTC

wvenable wrote: post #107

tptacek wrote: post #99

Earlier quoted context omitted.

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

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.

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.