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

121–130 of 209 posts

Re: Linus vs C++, again

#121

Post by albertzeyer »

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.

Similar thing with C macros.

(Note that my point here is that for sane/good code, you normally can be sure that it does what it looks like -- for C++ just the same way as for C.)

Re: Linus vs C++, again

#122

Post by [deleted] »

huherto wrote: post #44
sliverstorm wrote: post #23

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?

I would like to hear Linus opinion on Go.

[deleted]

Re: Linus vs C++, again

#123

Post by acqq »

albertzeyer wrote: post #82

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

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.

Re: Linus vs C++, again

#124

Post by shadytrees »

tbrownaw wrote: post #101
yonilevy wrote: post #15

Earlier quoted context omitted.

Well, he did create git. Not that your point isn't valid, just pointing out Linus is actively helping forward progress.

Not sure I'd call intertwingling the repository/workspace like that, or conflating branches and repositories, "progress". But I suppose it's better than svn/cvs/etc that it's largely taking its users from. (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :)

> (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :)

Wait, you can't just write that and end your comment! What VCS do you work on?, if you're at liberty to share.

Re: Linus vs C++, again

#125

Post by albertzeyer »

acqq wrote: post #123
albertzeyer wrote: post #82

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

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

What exactly is your point? You have the same problem if you use virtual function tables in C.

Re: Linus vs C++, again

#126

Post by albertzeyer »

acqq wrote: post #123
albertzeyer wrote: post #82

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

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

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.

Re: Linus vs C++, again

#127

Post by tbrownaw »

shadytrees wrote: post #124
tbrownaw wrote: post #101

Earlier quoted context omitted.

Not sure I'd call intertwingling the repository/workspace like that, or conflating branches and repositories, "progress". But I suppose it's better than svn/cvs/etc that it's largely taking its users from. (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :)

> (disclaimer: I work on a VCS that's written in C++ and uses a real database, nice object-oriented libraries, and nice C++ abstractions :) Wait, you can't just write that and end your comment! What VCS do you work on?, if you're at liberty to share.

I work on monotone ( http://monotone.ca/ ) which is older and I think conceptually cleaner, and that was a reference to this earlier rant (last paragraph): http://lwn.net/Articles/249460/ . We've also gotten a few comments about the code being very nice, so I doubt it's really all that messy and unmaintainable.

Re: Linus vs C++, again

#128

Post by dantheman »

martincmartin wrote: post #60
cageface wrote: post #9

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

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…

A little nit pick - "The exception that proves the rule" is commonly misused as above.

It means that by their being an explicit exception a rule must exist for their to be an exception. For example:

"Special leave is given for men to be out of barracks tonight till 11.00 p.m."; "The exception proves the rule" means that this special leave implies a rule requiring men, except when an exception is made, to be in earlier. The value of this in interpreting statutes is plain.

http://en.wikipedia.org/wiki/Exception_that_proves_the_rule

Re: Linus vs C++, again

#129

Post by JustinSeriously »

protomyth wrote: post #53
JustinSeriously wrote: post #37

Earlier quoted context omitted.

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.

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

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

Re: Linus vs C++, again

#130

Post by ANH »

CUViper wrote: post #79
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…

That same write call can exist in C++ too, with exactly the same consequences. Everything ugly in C can be done in C++, but C++ lets you be so much uglier. int i = 42; foo->bar(i); In C, we can tell that foo is either a "struct S* foo" or "union U* foo" which has a member "X (*bar)(Y)". Type X is unknown from this context, but Y is some type compatible with int. We will call the function which bar points to with a si…

This is one reason why idioms and patterns are important. I don't think there are many reasonable C++ coders out there who would override operator-> in such a way as to introduce such ambiguity.
Post reply on HN