Live data from Hacker News

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

stroustrup.com

141–150 of 231 posts

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

#141
A new version is extremely exciting.

Even if you're an experienced programmer or have no interest in C++ you should still read this book.

It's one of the best examples of technical writing and teaching computer programming that I'm aware of.

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

#142
post #115

Earlier quoted context omitted.

Conversely, We write code once, but read it many times, so longer names seems like a poor efficiency choice.

What's the logic of that though? Longer more descriptive names (self-documenting code) help readability, not hinder it. Certainly time to enter code (which is increasingly going to be automated) should be the last consideration - if we're considering full software lifecycle then coding probably takes up some small single-digit percentage of the time we're interacting with the code.

Longer names are harder to read. Think about any math formula. Does energy=mass * math::powerf(speed_of_light, 2) read more fluently? Context matters. Make sure the context is ways clear and code is written there where it belongs. Then names can be shorter while being readable.

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

#144

Earlier quoted context omitted.

Rust is cool now. Python is not cool anymore.

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.

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

#145

Earlier quoted context omitted.

Already teaching you about the maintainability of tightly coupling different parts of your system before you've even opened the book

It would have been awesome if that ISBN issue were an actual ISBN re-use issue. I've run into issues coupling my system's design to the assumption that ISBNs uniquely identify a single edition of a single book. The intent of ISBNs are to be unique, but mistakes are made and resellers lose track or straight up abuse some ISBNs.

Not just that but when ISBNs were first introduced, it was common thought that they were used for cash register price scanning rather than computer-controlled inventory, so a number of early books had ISBNs re-used by publishers and it wasn't caught because they were meant to be the same price. These days you often see two barcodes on books, one is the ISBN and the other is the price.

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

#146

Why does Bjarne only sometimes use a space after #include ? #include #include #include #include #include #include #include https://www.stroustrup.com/PPPheaders.h

Could be missed if there was a mix of typed by hand and auto-inserted by IDE headers, plus maybe a setting that collapses (folds) imports by default... and clang-format wasn't run on save? ;-)

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

#148

Earlier quoted context omitted.

Yep, although I do like not having clashing names. But I mean... somehow every other language solved this.

> But I mean... somehow every other language solved this. Did they? C, Lisp, Rust, Python, Ada, Go, Java, C#, ... They all require you to qualify conflicting names if some other characteristics (for instance the number or types of arguments) don't provide enough information, or outright don't permit it (C, since it has no notion of name spaces). Can you point to the "every other language[s]" which have solved this pr…

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 opportunities (distributed code becomes "grab this function out of cache").

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

#149
post #72

Know what I like about Stroustrup's code? "using namespace std;". The typical convention of sticking std:: in front of std::every std::last std::bloody std::thing drives me std::insane.

You learned to program on Windows, didn't you?

I learned on C on Unix. The naming conventions in Windows are the same kind of syntactic noise I dislike: long identifiers that are just long without actually being descriptive, with extra crap ladled on top in the form of Hungarian notation (which had its uses in the Excel codebase, but doesn't belong anywhere near C++)

BeOS probably had the nicest looking API. Let's hear it for is_computer_on_fire()

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

#150

Earlier quoted context omitted.

Same for me. Mainly due to the packaging fiasco (and to a lesser extent, imports). The actual language is not awful. Some features are even nice, like infinite precision integers by default, and separate / and // operators. Language is ok. Setting everything up is atrocious. The other quite annoying thing is that the docs are extremely badly organised so Google rarely points you directly at what you want. Instead you…

Pixi.sh has been great for me so far, it’s a single binary install that can install Python, conda packages and PyPi packages, maybe give it try!

Looks nice but I can't really require the whole team of like 100 people to use this quite niche tool.

Python needs an official solution.

Post reply on HN