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

3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

stroustrup.com

Post reply on HN
Print view View original

161–170 of 231 posts

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#161

Post by Kranar »

HarHarVeryFunny wrote: post #153
Kranar wrote: post #136

Earlier quoted context omitted.

>We write code once, but read it many times, so shorter names (incl. namespaces) seems like a poor efficiency choice. I think it's fascinating how different people can interpret this so differently. I feel like it's precisely because we read code so much more than we write it that we should prefer using names that get to the point, instead of having so much noise and repetitive boilerplate. Reading a soup of std::thi…

> This to me seems like a cargo cult justification, where you've heard the argument ... Well, no, I've been a professional programmer since 1982, and a hobbyist one both before then and to this day. I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ... Of course consise code is nice, and while you're in the heat of development it'…

I am not saying you are cargo cult programming, but being a cargo cult programmer has nothing to do with seniority. There are plenty of people who have been programming for decades who blindly follow rules because that's how they learned things, that's what they were taught is good practice, and they never bothered to question it, reflect on it, and they go along with it because of cultural reasons rather than because they have a genuine understanding of the principles.

>I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ...

But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names?

If it's that long names are better than short names, then by all means continue using std:: everywhere. If instead it's that descriptive names that communicate purpose or intention or actual information are better than non-descriptive names, then having a bunch of std:: everywhere doesn't do much of anything to help readability, it just adds noise.

Now people can and do justify the use of std:: but I've never heard it on the basis of making code more readable. There is nothing self documenting about a bunch of names that all share a common prefix.

And this doesn't even touch on how ironic it is that std is itself non-descriptive jargon that is an abbreviation of standard, but I am almost certain that if everyone had to liter their codebase with standard:: everywhere, no one would think twice about what the right thing to do is.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#162

Post by chuckadams »

Jtsummers wrote: post #154
chuckadams wrote: post #148

Earlier quoted context omitted.

It's certainly not every other language, but Unison has a novel approach to solving the problem of name clashes: function names are just local aliases for a content hash of the function's AST. Compiling involves replacing function names with those hashes, and putting the names back is a matter of pretty-printing. I'm sure there's an arsenal of footguns lurking in Unison's system, but for sure it opens up interesting…

Does that actually solve name clashes? If I have two functions compiled at the same time: def foo(n): return n + 2 def foo(n): return n * 2 foo(3) # which one is called? (I don't know Unison syntax so using Python for the example) It's still a name clash at compile time.

TBH I've only dipped my toe into Unison, but I don't believe it would let you re-bind the same identifier in the same scope in the same compilation unit. It's more that `foo(3)` becomes a call to the hashed version `#e0ca5f(3)` forevermore. Once a function has been compiled, it doesn't care what the names of any functions it uses are afterward, until you explicitly recompile them to use the new names. So it really has more to do with preventing versioning conflicts ... others can explain it much better than me, sorry.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#163

Post by heyoni »

xdavidliu wrote: post #160
aquir wrote: post #147

Great but I am unable to find an IDE or compiler that supports C++ 20 and every one of them complains about import std; Any recommendations?

I ran into this the last time I tried reading this book. It's supposed to be for beginners; how would a beginner get around this?

CLion seems to support it through a mixture of clangd and its own parser: https://www.jetbrains.com/help/clion/c-support.html#cpp-stan...

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#164

Post by justin66 »

iso8859-1 wrote: post #84
tejohnso wrote: post #37

Oh, he switched to QT for the GUI chapter. That's a significant change from FLTK. Should be well received as QT is popular in industry. Not sure how the learning curve will be affected.

I wonder what Stroustrup thinks about the Meta Object Compiler. In a way Qt is its own dialect of C++.

He's name-dropped CopperSpice in some of his speeches, so he's certainly aware that it's not universally adored.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#165

Post by xdavidliu »

I find it really problematic that the "classic first program" in this book includes "import std;" as the very first line, and as far as I know not a single compiler with the possible exception of MSVC supports that out of the box.

Writing this on a debian machine, and trying "g++ --std=c++23 -fmodules-ts" does not work, and from https://en.cppreference.com/w/cpp/23 looks like the "paper" for this is P2465R3, for which clang++ 17 has "partial support". I apt installed clang++17, and it still didn't work, complaining "module 'std' not found"

I understand that "import std;" is a very new feature and not "finalized" or whatever, but this book is supposed to be for beginners to C++; I wonder how the average beginner would react to that?

(I found the same thing a year or two ago when reading "Tour of C++")

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#166

Post by rightbyte »

PaulDavisThe1st wrote: post #159
rightbyte wrote: post #135

Earlier quoted context omitted.

Gotta have those "readfile()", "replace_substr()", "split()" etc! I do have a copy paste string util header. .. I really wish there were more string util functions in Cpp. I mean C had strtok()!

strtok() is one of the most dangerous string handling functions in any language!

strtok() is like a hot art student, smoking a cigarette. I think I've got to it once.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#167

Post by rightbyte »

germandiago wrote: post #144
steve1977 wrote: post #87

Earlier quoted context omitted.

I think Python fell victim to the Peter Principle. It got promoted beyond its competence.

Python does well for several reasons. Some that come to my mind: its versatility binding native code and its easy-to-fit in your brain mental model for many tasks. The fact that you can script with Python without a compilation step also helped a lot to spread its popularity I think.

The way you define the entry point function is so bizarre I assume scripting was the original use case.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#168

Post by PaulDavisThe1st »

rightbyte wrote: post #166
PaulDavisThe1st wrote: post #159

Earlier quoted context omitted.

strtok() is one of the most dangerous string handling functions in any language!

strtok() is like a hot art student, smoking a cigarette. I think I've got to it once.

In the C language, you do not get to strtok(3), strtok(3) gets to you.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#169

Post by HarHarVeryFunny »

Kranar wrote: post #161
HarHarVeryFunny wrote: post #153

Earlier quoted context omitted.

> This to me seems like a cargo cult justification, where you've heard the argument ... Well, no, I've been a professional programmer since 1982, and a hobbyist one both before then and to this day. I might be wrong, but these are the lessons I've learnt over the decades working on a variety of projects of different size and durations ... Of course consise code is nice, and while you're in the heat of development it'…

I am not saying you are cargo cult programming, but being a cargo cult programmer has nothing to do with seniority. There are plenty of people who have been programming for decades who blindly follow rules because that's how they learned things, that's what they were taught is good practice, and they never bothered to question it, reflect on it, and they go along with it because of cultural reasons rather than becaus…

> But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names?

Do you always suppose that the people you are talking to are morons and cargo-cultists?

Rhetorical question - have fun.

Re: 3rd Edition of Programming: Principles and Practice Using C++ by Stroustrup

#170

Post by Kranar »

HarHarVeryFunny wrote: post #169
Kranar wrote: post #161

Earlier quoted context omitted.

I am not saying you are cargo cult programming, but being a cargo cult programmer has nothing to do with seniority. There are plenty of people who have been programming for decades who blindly follow rules because that's how they learned things, that's what they were taught is good practice, and they never bothered to question it, reflect on it, and they go along with it because of cultural reasons rather than becaus…

> But what lesson did you learn? That long names are better than short names, which is what I called cargo cult programming and an instance of mixing up the metric for the principle? Or did you instead learn that descriptive names are better than non-descriptive names? Do you always suppose that the people you are talking to are morons and cargo-cultists? Rhetorical question - have fun.

I like to present questions to people to justify their position so that others reading the advice can better evaluate it, understand the reasons and make a more informed judgement on it.

I am also principled in critiquing an argument and never critiquing a person. I said that the advice you gave is a form of cargo culting, but I also said in the very first sentence that "I am not saying you are cargo cult programming".

I don't think there is anything wrong with getting into the subtleties of whether the advice is what you originally said it was, which is that longer names are better than shorter names, or whether the advice you learned was that descriptive names are better than non-descriptive names.

I think the subtlety between those two statements is not being appreciated and without a clear distinction other people may read that advice and take away the wrong conclusion.

Take care.

Post reply on HN