C++ is a language that was expressive enough to have inside the mechanic that is useful for _implementing_ another language for template metaprogramming, but that another language is built from weird building blocks and they do not look natural at all.
that when I did watch for the first time did remind me A LOT the memes about different levels of haskell engineers writing factorial function, with people somewhere in the middle implementing their own numerics based on basic number theory things. This presentation is literally exact scenario - you take one thing and start building poor man's programming language using it. And it's horrific.
Problem with C++, that it is extremely slowly addressing is that it doesn't have many facilities to improve that nested informal templated language built on top of templating constructs. C++ is getting them, but it at glacier pace. And when I see that presentation after having exposure to other languages, I just feel that this is so much waste here, it could've been much better if language had better thought put into metaprogramming part, instead of letting random crazy geniuses to build hacks on top of hacks to get something useful.
Unfortunately for C++, it gives significant problem for starting. Because to learn something, it is very useful to look into how standard things, like stdlib is implemented. But what you see, often, is not C++, it is that another _thing_ that is using c++ constructs to have its own thing. That has its own patterns and quirks (and there are many of them, so many).
C++ went into local maxima by letting to do many things by various template tricks, but in the end I think that this is dead end. C++ need real metaprogramming, type level programming, you name it - that can be done in (constrained) C++, not in some fungus that has grown on top of template language.
This seems kinda backwards? C++ has gotten as complex as it has mostly because it’s been the pragmatic default for big, performance sensitive applications consistently for like 30 years and the clear up-and-comer for ~10 more.
Java can be really fast and handle big codebases too, and it’s also been huge for long enough it can buy a beer, and it’s also getting a little hairy.
Uh, other languages in the niche seem to be starting their runs at comparable levels of complexity, if they’re as successful as it looks like, writing them will be quantum chromodynamics in another 30.
> Java can be really fast and handle big codebases too, and it’s also been huge for long enough it can buy a beer, and it’s also getting a little hairy.
IMO Java is so simple you can teach it to any programmer in a day or two. I'm not sure which part are "hairy", maybe frameworks?
Memory order is hard but that's only very rarely used in idiomatic Java, and mostly through the atomic wrappers. Synchronized is simpler than equivalent barriers in almost all other languages.
There aren't that many keywords, no operator overloading, barely any metaprogramming (just annotations), almost no compile flags, etc.
I guess tuning the runtime can be hairy, and some of the standard lib stuff is weirdly over complicated (nio vs io), but as far as languages go, Java has been incredibly conservative. In fact, a lot of Java app dev would probably be easier in practice if it had more features.
I think i understand what you say, but i don't think this is in contrary to my statement of C++ having become a language of which features are often reasoned about for the sake of the language itself in stead of for the sake of the goal of the language, namely writing and maintaining computer programs.
Luckily, one can just ignore all the modern C++ shenanigans and use it as not much more than C with classes and some basic templates for generic containers. Those are too useful to give up.
Is everyone on a team of one in C++ land? I kind of want to learn a bit of C++ but to be honest, I’m a bit scared off by the fact that it’s only workable if you stick to a specific style. If I learn C++, will I be completely lost the moment I change teams? Presumably they’ll have their own set of practices they like to follow that I’ll be expected to be productive with.
Most large teams totally ignore whatever the standard library is doing, because it's largely just bad, over engineered and slow, both to compile and at runtime. They then have their own developed from scratch. It would be funny if it wasn't so sad.
For example, even though both Chromium and Unreal Engine are using C++, good luck finding basically anything high level in common. All of the naming schemes are different, the formatting is different, the high level libraries are unrecognizable. It almost feels like these projects are written in different languages.
Beneath all of that, they do make use of the same low level mechanics. A pointer is still a pointer, no matter what libraries you build on it. A stack allocation is still a stack allocation, passing something by a const reference is still the same, passing universal references to container templates is still the same. Includes work the same everywhere. And so on.
Basically, unlike most other languages, you want to have a solid understanding of these underlying mechanics so you can then quickly understand whatever high level libraries the project decided to build on top and hit the ground running using those. There's gonna be some kind of resizable array thing in every project.
But yes, you're basically starting over re-familiarizing yourself with the language on every large project or framework you explore. I've been using C++ for many years and never once used a std::string, since each framework has its own clearly superior string...
You want to be on a team that contains a C++ expert or two, and they should conscientiously and continuously evolve your code base to incorporate more static time correctness checks and to be more in line with where the standard library is heading.
C++ was accidentally highly expressive. Since it was accidental, much of this expressiveness was only available via convoluted and inscrutable metaprogramming. Nonetheless, this expressiveness turned out to be highly useful in practical scenarios, which established the value of that expressiveness.
If you fast-forward to C++20, metaprogramming is mostly, though not always, concise and easy to follow. The language was redesigned to make template hacks that people found highly useful into first-class features of the language. For reasons of backward compatibility, you can still express these things the old ways. But it isn’t required anymore, there are concise and direct ways of expressing most metaprogramming things you might want to do.
The extreme expressiveness of modern C++ in application domains with unusual requirements remains its greatest strength. For pure systems languages, nothing else can express as much in a type-safe way in so few lines of code, almost entirely due to its metaprogramming facilities.
It often feels like math professors discussing math for the fun of it, not for solving practical problems.