Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus vs C++, again

realworldtech.com

Post reply on HN
Print view View original

181–190 of 209 posts

Re: Linus vs C++, again

#181

Post by grogers »

albertzeyer wrote: post #120
mojuba wrote: post #31

Earlier quoted context omitted.

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 clea…

I can show you a lot more awful looking C code than awful looking C++ code. Edit: Well, seems you don't believe it. Take a look here: http://www.google.com/codesearch?hl=en&lr=&q=lang:c%... And here: http://www.google.com/codesearch?hl=en&lr=&q=lang:c+... Just browse a bit through both, check a few different projects. Check also some of the big projects. (Apache, GCC, glibc, Linux, LLVM, clang, WebKit, Chromium, etc.…

Its all just header comments...

Re: Linus vs C++, again

#182

Post by 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?

Re: Linus vs C++, again

#183

Post by angelbob »

yock wrote: post #182

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 t…

I absolutely could not be the world's first programmer generation gap, because we have had so many before :-)

Re: Linus vs C++, again

#184

Post by tree_of_item »

alnayyir wrote: post #134
KirinDave wrote: post #90

Earlier quoted context omitted.

You can save your spiteful single clicks. That post sinks its own ship plenty well.

It got deleted, a little context so that I understand?

I was under the impression things were easier to understand without context.

Re: Linus vs C++, again

#185

Post by Xurinos »

jpr wrote: post #142
Xurinos wrote: post #141

Earlier quoted context omitted.

This comment made things a bit clearer for me. This seems to also be an argument in favor of a Lisp-1 over a Lisp-2 (same symbol found in multiple packages) as well as an argument against use of generic methods (have to understand the types to find the right implementation). Something to think about.

Lisp-1 vs Lisp-2 is about whether functions and other variables are in the same namespace or not. Packages are orthogonal to this. Also, generic functions in Common Lisp don't suffer from nearly the same amount of complexity as can be found in C++: there is always only one signature (lambda-list) for any function name, whether generic or not, there are no implicit conversions, no memory-allocation details, value/poin…

By your wording, aren't CL packages considered to be just an implementation of a namespace? Is there another way to declare symbol namespaces in CL (outside of rolling our own organisms)?

I was under the impression that the function signature was not the issue raised... but the fact that the same function name could lead to completely different behaviors depending on a context. In the case of generic functions, the specific function implementation is usually (ignoring some of the other matching features) determined by the input types. The input types define the context.

All that said, I realize now that this might be less of a problem in CL if you just group your defmethods in the same area. If the problem is grepping for the definition, it is easy enough to rearrange things so that the related functions are in a close-enough place. In C++, the classes try to own their methods -- with the exception of warily-regarded "friend" methods.

Re: Linus vs C++, again

#186

Post by nitrogen »

sophacles wrote: post #139
nitrogen wrote: post #114

Earlier quoted context omitted.

The kernel does use object-oriented paradigms.

The kernel is also shockingly simple. Sure there are some tricky bits, but writing kernel code is very straight-forward. In fact every time I've written kernel code it has always been a "it can't really be this simple" type moment -- but some of that code is still running production machines today so... it must have been. NOTE: this is not me bragging, it's me suggesting the mystique is a bit undeserved.

I definitely agree. It is the simplicity of the POSIX userspace APIs and the Linux kernel internals that make me enjoy Linux so much.

I still think there is some art to writing simple, efficient code, though. Most system-level code looks quite simple when it's done, but it may have taken several iterations to get it fast, clean, and small enough (particularly on embedded devices -- I once had to find 200 spare bytes to fit a bug fix in a 256KB firmware by hand optimizing various ancient parts of the code base).

Re: Linus vs C++, again

#187

Post by jongraehl »

_0ffh wrote: post #140
jongraehl wrote: post #80

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.

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

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.

Re: Linus vs C++, again

#188

Post by jongraehl »

Daramarak wrote: post #161
jongraehl wrote: post #80

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.

Excuse me but C++ is only vastly superior of C if you are a C++ programmer and do not know C. I am a C++ programmer, and I would never make such a claim. And for time and space efficiency? That doesn't make sense.

I know C and C++ very well. I don't use either language unless I need to be as efficient as possible.

Re: Linus vs C++, again

#189

Post by jshen »

Confusion wrote: post #162
martincmartin wrote: post #60

Earlier quoted context omitted.

How do you explain the success of ActiveRecord? Do you think it's illusory? The exception that proves the rule? Something else? http://blog.objectmentor.com/articles/2009/07/13/ending-the-... "The fact that it took decades for the industry to arrive at something as useful as ActiveRecord in Rails is due primarily to the attitude that some language features [in this case, meta-programming] are just too powerful for ev…

ActiveRecord is godawful as soon as you want to use for something that wasn't in mind when people designed it. I'm working on a Ruby application that has to talk to a legacy database with composite keys and does so via ActiveRecord. Oh, the pain. As others say in this thread: ActiveRecord makes easy/simple things very easy. Unfortunately, it makes harder things damn near impossible. To aggravate matters, people that…

i disagree with the assumption that a good tool will support all or even 90+% of use cases. you lose a lot by piling in feature after feature.

I much prefer a few different tools that do a few different things really well. I don't use active record if I have to deal with legacy schemas. I'll use data mapper or roll my own. If I get to design my own schemas then I love the benefits AR gives me.

Re: Linus vs C++, again

#190

Post by Daniel_Newby »

jafl5272 wrote: post #71
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'll deal with this in order of decreasing insanity: 1) Polymorphism is NOT functional programming. Using function pointers, which you seem to detest, is one aspect of functional programming. If you've only used C++, then you don't know what you're missing from languages like Lisp or JavaScript. (I should know. I was once like that.) 2) I seriously doubt the Linux kernel avoids function pointers. Ever heard of dispat…

1) You can pass around worker objects and apply them to things.

2) Declaring, initializing, and using dispatch tables requires a boat load of syntax, or GTK+ style macro hell. To the best of my recollection, Linux only goes to the trouble for a few large, complex subsystems, like networking and filesystems. Many other areas could probably benefit from it but cannot afford the price.

3) True. But once you climb the hill, you get to offload a lot of crap onto the compiler. Forever.

4) Linus already applies his +18 Axe of Correction to large functions and nesting depth. Anybody who reviews patches without a color-highlighting code browser deserves what they get.

Post reply on HN