Guys, do you agree that C++ is getting overly complicated following the updated versions?

At times I wonder whether I should leave C++ and jump to python as my goto programming language.

Python doesn't even have goto.

Somewhat I agree. But that's also C++ trying to stay relevant and ultimately you don't have to use all the newest features immediatelly.

All in all, I don't mind yet

@Fast-Nop not standard sure 🙃

https://github.com/snoack/...

Yes, but you don't really need to use all the things

@C0D4 @iiii That argument is dubious. True, if you code alone from scratch - but that's not the typical situation. Usually, you will come into an existing project and have to know the set union of all features that any of the previous devs ever used at any point as well as the differences between the various C++ standards that have accrued over the lifetime of that project.

Factor in that usually, the staffing goes down in maintenance, and you end up with increasingly unmaintainable projects, and that's not even accounting for architecture rot.

In the long run, you can't use freshers for maintenance programming because they'd need to know several C++ standards at the same time, and you don't want to put freshers on new projects because they'd fuck up.

@Fast-Nop I did not mean that you don't have to know it at least on a surface level. But yeah, legacy code might be pretty hard, but at least it was made with a less feature rich version 🙃

@iiii Not even that. Legacy code can be in the same project so that you have parts of the show in old style idioms, then wherever shit was added later using newer standards. Just about nobody rewrites shit from scratch because that's the single worst strategic mistake a company can make.

As per my experience, what's turning C++ over-complicated is the addition of numerous ways of doing the same task, better, I should call it "syntactic sugar".

I guess it's the wheel of time.

Any programming language suffers from its age, be it by language additions / inconsistent methods | naming that cannot be cleaned up due to backward compatibility, idioms / principles which didn't age well... Yada yada

But I think C++ handles it fairly well, as a compiler for C++ needs to be instructed to use new features and compilers like LLVM/Clang support an excellent static analysis and automated rewrite.

What @Fast-Nop wrote is true, however it was someone's decision to mix and shake several versions and get inconsistent. If you migrate fully to a new language level, you shouldn't have the problem of supporting the universe plus one ;) but that's the core problem of any project - starting stuff and not finishing it for whatever reason.

@IntrusionCM Projects aren't finished, they keep on going, and you can't fully migrate because nobody would pay for that.

On the other hand, you neither want to keep everything in dino-C++ because just how many people even know how to do shit in C++98 these days? That would be seniors by age alone, and you won't waste such expensive staff on maintenance programming.

@Fast-Nop I think you can fully migrate to a specific part of a language convention.

No one pays you to use new features on a whim either - a migration to a new version in any language is always pricy.

I think we mean the same thing, but have two different approaches.

For me, using a new version of a language / compiler doesn't mean all new features can be used, quite the opposite.

Usually I'd target the minimum of required work to fix compatibility so that it just runs on a new feature level.

What actual new features are allowed is then a question of coding guidelines and migration cost vs outcome.

E.g. if a project utilized boosts coroutines and someone wants shiny C++ 20 coroutines it seems to me a no brainer to not allow this, unless the boost coroutines could be all migrated. Mixing different types of the same thing is always dangerous.

You might not be able to migrate a project to use _all_ new shiny stuff, but this should be imho never the goal, as using _alll_ new shiny stuff makes the project an incoherent mess.

@IntrusionCM It's more that nobody will replace all the old, sometimes cumbersome ways with the newer ones just because. It will stay there, and any new programmer will need to parse anything from oldschool C++98 to C++20.

The newer ways are intended to make things easier and more concise, but instead just add more cognitive load because they are not replacements, but additions.

The usual "solution" is that people just muddle through with anything that seems to work, thereby negating the whole point of C++.

Check out Rust, it's basically a sane version of C++

@12bitfloat except it is not.

@iiii In what way is it not though

@12bitfloat it's not sane

@iiii The borrow checker looks a lot saner when you've actually used Rust

I feel like complexity is not one of the key differences between C++ and Python.

The main similarities I can think of are that both are mainly imperative, neither have proper TCE even though there's very little in terms of practical obstacles and both of their ASTs are fucked up beyond repair, although in different ways.

@lbfalvy what is TCE?

@iiii Probably mistyped TCO, tail call optimisation. Used by people who think that recursion is more readable than loops.

@Fast-Nop oh, the muggles who don't know how to make a domain specific stack (if it even necessary)

@iiii If it has gone downhills that far, I'd also prefer to let the compiler handle the stack - but then it's usually neither easy shit that would lend itself to TCO.

@Fast-Nop TCE is the same thing as TCO except a language feature rather than an implementation specific optimization. TCO can save you a few bytes here and there when you remember to rephrase return statements so that if your compiler happens to be smart enough the tail call will be eliminated. TCE can be used to write a recursive algorithm and make statements about its memory usage in all cases, even if copied and compiled with different flags from your project.

@iiii Heap-based stacks are slow and stupid. You already have a stack, why would you want to write a shallow imitation of it on top of an allocation API that specifically hates variable size structures?

@lbfalvy Yeah, using TCO in a language where it's not guaranteed through the language standard would be bad.

Then again, I don't get the new-fashioned hatred for loops, either. If it's so trivial that TCO/TCE even apply, a loop is just as trivial to get right.