The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
For example, adding a yield <sub-iterator> statement to avoid extra object overhead in iterator routines
I guess the main problem is that for every revision of the language, there are a couple hundred such proposals that all should be done before any of the others. If ten out of two hundred new features are added in a revision, the backers of the one hundred and ninety will be barking about the uselessness of the update.
For software of all sorts I have read through the revision log describing some new feature, shrugging "Fair enough - but I am not going to spend any time to learn how to use that properly; I see now need for it in my work.
Is there a single person in this world who makes use of, or even knows how to make use of, every single feature provided by MS-Word? Is there a single programmer who has ever as much as tried out every single call line option of gcc? (If you actually did: Was that part of some bet or competition, like "I have visited more countries than you have, so there!"? "I have used more gcc options than you have!"...)
So what? I can live with a tool providing features that I don't need, but others do, as long as it doesn't strangle me. If someone tells you that the reason why you can't have what you want, or in the way you want, because that would conflict with another mechanism that you do not use, then is the time to consider if your chosen tool is the right one for you. (It still may be the least bad one, even after the consideration.)
Lots of tools today - languages, editors, debuggers - are so complex that even if you consider yourself fluent in its use, you shouldn't be ashamed of admitting "No, I never used that feature".
My argument for C++ is that they've spent years and years creating a cathedral to containers, but they've ignored the most important thing, which is that, unlike C#, you can't just install C++ and write realistic applications. You are immediately into a world of having to select third party tools to do even a fairly modest realistic program, even a back end one without UI issues.
That's a vast advantage that languages like Java or C# have over C++, and it's just not addressed at all, and probably never will be. So C++ remains fractured in a fundamental way, where any given developer might come into a company and never even have seen half the tools they are using.
I've spent most of my life addressing that problem, so I know what it's like to have a full featured, tightly integrated system in C++ that is very much like what C# has. And it's a whole other world.
But the C++ community has been this way so long, that they actually will react negatively to a system such as mine and start yelling about not invented here syndrome. They consider it the normal state of things to have to piece and part together a system to write a real program.
I have created everything for myself. However, sub-optimally in my opinion, they have more and more begun to tie the language to the libraries, so that fundamental features are not available unless you use their libraries. That really sort of undermines one of the things that was always nice about the language, that it could be used in tabula rasa mode to create something unique and consistent.
And some of the template stuff is just really bad. A lot of it isn't actually supported by the language, it's dependent on knowing how the compiler fails. And a lot of the way you have to do things (generic templatized callback parameters for instance) can cause enormous lists of errors that have little to do with the actual problem.
There are a number of bits related to determining types of things and type traits and such that are now tied to the standard libraries, i.e. they are in library headers, not intrinsic parts of the language. But they are required to do various fancy template'ish type things. So you can't do those unless you include the standard library stuff.
Actually, it's more advanced static type info, for doing template stuff at compile time really. Basically to let you do a certain amount of logic at compile time to select this or that bit of template code, set that size value, etc...
hmm, well that's neat, actually. the only question is do you have to use the libraries or are they only invoked if you use that language feature? (you don't have to answer) - if it's not, then i am hesitantly okay with it.
The rationale being that the more you can get a C++ compiler to do for you, the better.
I love that it can solve equations for you and the like, but more importantly, it's critical for offloading absolutely as much as possible to the compiler.
a little bit of special knowledge of the standard libraries is about as much of a hack as parsing C languages is in general, see for example, the "type problem" requires a backchannel from the syntax analyzer back into the lexer, and these are as old as C itself.
if it's targeted and optional to use, and helps the compiler do more at compile time, I'd side-eye it, but i think the pros can outweigh the cons. I'm guessing the standards committee came to more or less the same rationale.
Here's a different take on this problem -- the IDE vendors have run out of real additions to the languages so they are pushing their people to create snazzy new but ultimately unnecessary "features" to sell the next version of the IDE. That explains languages like C# -- every time I see a list of new "features" I find a small percentage that is actually useful.
Open source has a different part of that same problem -- they need to be seem as making progress. If they are not adding features, the language is seen as stagnant and falling behind, which results in a software version of "keeping up with the Jones". Like IDE vendors, they have run out of real things to add, so they add "features" that impress the vocal fanbois.
I just searched for "C# new features" and looked at a few "top 10" features in C 7#. The lists were virtually identical and each contained 2 things of real use, 2 things of interest, and 6 that made me scratch my head.
C++ has this problem, and it isn't even a product from some corporation. I like many of the new features of C++, but some leave me shaking my head (any, variant, lambdas). They seem to be solutions looking for a problem. And what else they do is shake my mastery of the language, so I don't know any longer if there is a better way.
I think each new generation of PhDs and young professors wants to make a mark on C++ by copying bits from some research language into C++ so it feels more "advanced". That's great for the people who learn C++ with these tools already baked in, but kinda sucks for more experienced developers who already know C++.
I'd like to see the tempo of new features reduced. Maybe a new standard every 5 years is enough?
I think part of it C++'s problem is that it is in danger of entering a death spiral, and maybe a lot of folks think that if it doesn't appear to be moving forward quickly to become 'more modern' that it will just get worse.
Ultimately, I think that may be counter-productive, because it's now so complicated that it probably puts off a lot of new developers looking at it.
Lambdas I get. They can obviously be abused, but they have the one massive advantage in that they can be capturing. So it allows for a range of things that couldn't otherwise easily be done in the way of callbacks.
The downside is that, capturing lambdas cannot be passed to a function pointer parameter. So you can't strictly define the parameter if you want to pass capturing lambdas, you have to use a generic templatized parameter. So you can only use them with other templatized code which is sub-optimal, and you get immediately into 'million errors that mean nothing' land any time you make a mistake, because the compiler has no idea what you really are trying to do.
People have predicted the imminent death of C++ since 2003 or so. Instead of dying, it just gets more users, and remains near the top of the TIOBE index.
The people who think about C++ have observed since 2011 that it is becoming two languages: one very sophisticated language for creators of template libraries, and another language for ordinary users. I'm not sure this is a healthy evolution.
Some day, Rust may overtake C++, but I don't see any other contender today.
There's dying and there's dying. Looking through the job listings out there, C++ seems to me to be suffering, mainly because it's not well suited for the projects that are getting lots of investment. Often C++ seems to be often only even in a listing because it's in the 'experience in one or more of these languages' list, but it's probably not the one you are going to be using, it's just that at least you would have OO development experience if you know it.
I mean I think that the browser and the phone have been amongst the worst things to happen to programming in a long time (let's throw out all of the work done over decades and go back through the exact same ridiculously long and painful process again but even worse), but the fact is that so many development jobs are there. Or maybe they are on the back-end but they related to how can we collect as much data on people as possible and apply AI to exploit that data as much as possible and that's usually not C++ related either. It's more likely to be SQL or Hadoop or Azure experience or some such.
Don't get me wrong. I have a HUGE investment in C++ and it would be to my benefit if it were doing better. But I just really get the impression that it's on a precipice.
I think you are exactly correct. C++ is not the go-to language for writing web pages, web servers, or phone apps. Apple had an investment in Object Pascal, and then Swift, to create a typical Apple lock-in. Google chose Java for Android, probably to take advantage of the many programmers who knew Java and the Spring graphics library, but found C++ difficult.
C++ is always going to be the language for implementing embedded things, for writing operating systems, compilers and databases, and for any place performance is critical.
And of course Microsoft only supports C++ out of obligation and for reputation at this point I think. Most Windows work is C# these days. So, if you backed the Windows/C++ horse, and a lot of people did, it was sort of the worst case scenario. Much of the C++ work that is available is on Linux/Unix.
I think you're right about many general purpose languages out there. I've felt a lot of fatigue with C#/ESNext/TypeScript.
On the flip side, the tempered, thoughtful, and consistent design is something I didn't expect to appreciate when I first discovered Elm. The language and ecosystem becomes simpler and more reliable with new releases. It's a breath of fresh air.