I study CS at the same university Bjarne studied at. My lecturers know him personally. Hell, one of my professors once phoned him directly to ask a question about C++... Turned out it was a bug and 3 weeks later Bjarne phoned back "Fixed it"
"You want to compose your program from unique parts" so you don't have to solve bugs multiple times. Very succinct and memorable expression of this principle.
It's difficult to master C++, especially with its extreme added complexity of the last three decades (multiple inheritance, smart pointers, rvalue/movie semantics, template metaprogramming, concepts, etc.). It's also difficult to put all these ideas together in a professional setting. Bjarne convinces me that everything is there for a reason and is worth learning.
C++ shouldn't be mastered unless you are interacting with a problem that requires it or you want scott meyers job. Pointers/Smart_Pointers/References/Move_semantics, Vectors/Arrays, and Classes/Structs are more than enough to deal with most problems. Once you have those down (meaning you understand what they mean in terms of hardware) learn only whats necessary to make your codebase more manageable.
C++ was never for the faint of heart. They're working on it to make it simpler but the goal of C++ was always performance. "I'm not a great fan of garbage collection. I would like to put it out of business if I can." - Bjarne @32:27
@@SrIgort There's a lot of people that understand the fundamentals of C++ (> hundreds of thousands), quite a bit fewer that understand the implications of those fundamentals (~tens of thousands), and only a select few (tens? hundreds?) that can layer those implications into a rapidly maintainable code base to achieve a predefined goal. All too often, those from the first or second group assert that they belong to the third, while those from the third (typically) assert that they have barely approached the second.
Ellis and Stroustrup's The Annotated C++ Reference Manual textbook that I purchased in 1990 is the best investment I have made to sustain a Computer Systems Engineering career for another 30 years. Dollar sign emoji.
Incase you have not as a beginner cpp, Bjarne's programming and principles is really the best programming book you can ever get your hands on . He is a great teacher and very intellectual, though you can't expect less from a man that created a language like cpp 😊. But he pampers learners.
The language wars are always around, and CISA is going around telling people not to use C++, but I always find myself going back. C++ is still my favorite language.
Back in the 1960ths. the Software Programming world was divided roughly into Cobol for the business, Fortran for engineering and Algol for Research. Today you'll find C++ everywhere ... ! ... I'd say that the C++ user community today is in a way simply too big to fail. In general there are only two possible pathes for the evolution of any programming language ... you either start from scratch like Ken Thompson did with GO or you focus on improvements in the space of backwards compatibility like Bjarne Stroustrup did and do with C++ ... I think both approaches have their plus & minus points of view, but can perfectly coexist harmonically side by side. Congrats to Bjarne Stroustrup and the C++ user community for this new release of C++20. It sounds really promising!
My wishlist for next standard: - UFCS or sort of: having the possibility to extend an existing closed class with new methods are the most common usage and is autocompletion friendly so a junior dev can see what methods are available. - Single statement lambda: something like: [] (a, b) => a < b expanded to something like [] (auto&& a, auto&& b) -> auto&& { return a < b; }. Just to make simple things simpler and less verbose.
Your first point is handled, I think, by unified calling syntax. If obj.foo(x) is the same thing as foo(obj,x) then writing a non-member function can then be called as if it were a member. This has been discussed for many years but never voted in.
@@JohnDlugosz x.f() -> f(x) mirrors a[i] -> i[a] commutation. You can write x.f().g() instead of g(f(x)) and you can write i[a][b] instead of b[a[i]]. I think it's a good idea. Even removing the dot and making function calls commutative across ( like array access is across [ would eliminate a lot of nesting.
very late reply, but just in case: the comment "Filter out (skip) !pred elements" could be rephrased as "Keep elements for which pred(elem) is true", which is what the code below it does. as an aside, `filter` in all languages (that i'm aware of) usually sticks with that convention.
