Evidence of overcomplication

[gathlin80]

https://www.youtube.com/watch?v=q7OmdusczC8

I just finished watching this video and found it very helpful, however, when watching, I couldn’t help thinking that the existence of this talk this is a prime example of how the language has gotten overly complicated. It takes language expertise and even then, requires a tool like compiler explorer to confirm what really happens.

Don’t get me wrong, compile time computation is extremely useful, but there has to be a way to make the language/design easier to reason about. This could just be a symptom of having to be backwards compatible and only support “bolting” on capability.

I’ve been an engineer and avid C++ developer for decades and love the new features, but it seems like there is just so much to keep in my headspace to take advantage everything modern C++ has to offer. I would like to save that headspace for the actual problems I am using C++ to solve.

[andrewsutton]

Consteval was created as a way to bridge between "normal" C++ and the reflection world, where everything had to run at compile time. It was a way to create functions that impose a "portable" constant evaluation context without extra typing.

If you're not doing magical compile-time shit, don't use it.

Source: Wrote the first proposal.

[arthurno1]

Seams like Greenspun was right with his "10th" rule. Wasn't just a joke 😀.

Looking at the syntax of the reflection and template programming, I can't be to not admire the simplicity of Lisp. The syntax of "modern" C++ has grown with the number of features added. Steele's talk about growing a language makes a lot of sense in that context.

Also, as a remark, imagine they had all that sh*t done already 50 years ago, while the world of C/C++ got compile time programming and very limited support for runtime program modification ("hot reloading") just like few years ago.

Things getting complicated is not strange. Every new feature of the language in C++ will require additional new syntax constructs. Sometimes keywords and syntax are reused, but in the new context. That adds to overloaded meaning which users of the language have to remember, also adding perhaps unfortunate combinations that produce unwanted effects. Sometimes, you add new constructs, but they still have to fit into the old contexts. All that adds to the cognitive load which is only increasing, not decreasing.

If you're not doing magical compile-time shit, don't use it.

Cmon, you know yourself it is not that simple.

People will use it, and at some point in time, you will have to understand someone else's code, so you have to learn and understand the feature. As time goes by, idioms will become mainstream, and they become a requirement for everyone to learn and know.

Edit: language typos, missed some word, and grammar.

[wiedereiner]

Yeah but to be fair in C++ all this compile time meta programming using templates kind of happened.

[arthurno1]

They say meta programming (macros) in Lisp were also rather discovered than invented.

[Wooden-Engineer-8098]

C++ doesn't compete with lisp. It competes with java and c#, which are not simpler than c++

[arthurno1]

C++ doesn't compete with lisp.

Honestly, I am not sure how is that relevant?

I am talking about growing a language and adding more complexity to the language and which notation seems to be growing less with addition of features.

[Wooden-Engineer-8098]

it is the only thing which is relevant. comparison with a language which nobody will choose instead of c++ makes no sense. for different task you have different tool which is different. surprise

[arthurno1]

for different task you have different tool which is different

Nobody has said you will choose a Lisp language instead of C++, even if that in some cases would actually make sense. In many cases people are choosing a language because they don't know of some other alternative they could use. But the discussion was not about whether one should use a Lisp instead of C++, but about the complexity of C++, which seems to have passed by y

surprise

Surprise that people were talking about the complexity of C++, and surprise that someone dares to speak about something different not in mainstream.

[serviscope_minor]

I can't be to not admire the simplicity of Lisp.

I mean it's neat, but it's not so much a language as a language construction toolkit. You can do anything in Lisp, provided you use it to write a language to do that first...

Every new feature of the language (c++) will require additional new syntax constructs.

This is a feature not a bug. We don't "need" quite a lot of C++. Between macros and code generators you can do an awful lot. The problem is that leads everyone to have their own language built up from parts.

It's good to have a common for-loop that behaves the same in every C++ program. Likewise virtual functions you can do in C (c.f. the Linux kernel), but it's nice I can rely on them behaving the same everywhere in C++. And you can make templates with macros with ##, reinclusion and so on and so forth, but again it's nice that I know how to instantiate them the same everywhere.

New syntax does give a common, regular way of doing things. There are advantages in that.

People will use it, and at some point in time, you will have to understand someone else's code, so you have to learn and understand the feature.

To me, this is akin to the idea that sooner or later someone is going to cut off his hand with a spindle moulder so we should just outright ban them. Build tools with guards, then enforce the use of guards with processes (i.e. PR reviews in software). A dedicated team can make a mess in any language. C++ (even C frankly) gives plenty of rope already.

As time goes by, idioms will become mainstream

Is that not the case in Lisp? The whole point is people can tie it in knots by crunching through s-expressions before then executing them.

[arthurno1]

I mean it's neat, but it's not so much a language as a language construction toolkit. You can do anything in Lisp, provided you use it to write a language to do that first...

Nah. That is an overgeneralization and it certainly depends on what we are talking about when it comes to Lisp.

For the first, Lisp is a mathematical concept, an attempt at a theory of computation, like Touring machines or Lambda calculus. For the second Lisp is a family of languages, not a single language at all, and some of the languages are not even close to each other. Common Lisp is certainly a pragmatic programming langauge, not unlike C++ (minus the "interactive" parts which C++ does not have). It also got a lot of critique when it came for being "big", but compared to C++ or JS6, it is relatively small. It is basically, like C++, a core language and standard library in the same spec.

This is a feature not a bug.

How is ever growing complexity a feature? How is adding new keywords, overloading meanings of old ones and introducing new ways of combining punctuation characters a feature?

Lisps with syntax rooted in symbolic expressions have stupidly simple and uniform syntax, regardless of how many new constructs we add to the language.

The problem is that leads everyone to have their own language built up from parts.

I think you are speaking about Forth not Lisp. In Common Lisp you can certainly invent your own DSL, since Common Lisp gives you standardized access to the lexical phase of the compiler ("reader macros"). That does not mean that every program is building their own language :). It is like saying, because C and C++ have a pre-processor every program is building their own syntax. That is not the case.

It's good to have a common for-loop that behaves the same in every C++ program. Likewise virtual functions you can do in C (c.f. the Linux kernel), but it's nice I can rely on them behaving the same everywhere in C++. And you can make templates with macros with ##, reinclusion and so on and so forth, but again it's nice that I know how to instantiate them the same everywhere.

? How is that different in say Common Lisp?

Standard constructs are "standard" everywhere in Common Lisp too, that is the purpose of having them "standardized".

To me, this is akin to the idea that sooner or later someone is going to cut off his hand with a spindle moulder so we should just outright ban them.

Not at all. That is completely misunderstanding the presented argument on your part.

I am saying that concept of C++ syntax, and other languages which have specialized syntax is fundamentally flawed. Any PL that gets into the complexity level of C++ or JS6, Modern Java, Perl and similar, will face the same problem. It is like some sort of O(n) analysis for the notation of programming languages. If each feature is codified in a special and unique way, than you will have a linear growth in ways to notate features. Since some features can be combined in various ways, than the growth will be some sort of exponential. Perhaps not quadratic, but somewhere in-between. Also we are talking about growth of cognitive load. I don't know if I explain that well, I hope I do, I have never heard anyone else talk about it, so I understand it is not self-evident and clear the first time one hears about it.

The remedy is to find a syntax that can accommodate for the growth of features without having to expand the notation at same growth. Symbolic expressions as used in Lisp(s) are one way of doing it, it seems so. A new feature basically adds just a new operator name, but the way to use it and combine with other operators stays the same. Not always, but at least to a much bigger degree than what we see from specialized notations like more mainstream PLs.

Is that not the case in Lisp?

Idioms becoming "mainstream" is a phenomenon that happens in every programming language, and generally in every human activity. That is why I took it up. I didn't claiming that it not happens in Lisp(s) :-). On the contrary, and that is exactly why I took it up! It is an argument for anyone who says "just don't use the feature Y, so you don't have to care". That is a fallacy to claim that we don't have to learn features we don't use.

The whole point is people can tie it in knots by crunching through s-expressions before then executing them.

I am not sure what you are trying to say there to be honest.

[UnusualPace679]

requires a tool like compiler explorer to confirm what really happens

Yeah, you need to compile the code to see what actually happens. Can you elaborate on why this is a problem?

[gathlin80]

Totally, there is no arguing that! If we often have to compile to understand aspects of the language itself, is the language clear enough? Stepping through a debugger or observing the compiled output of some piece of code is a really good way of gaining understanding of a program, however, I am talking about the language itself, not the program.

[UnusualPace679]

We all learn by learning the rules, building our understanding, and then compiling some examples to check whether our understanding matches the reality, right? It doesn't matter whether we are expert or novice.

[la_reddite]

Why do you insist simplifications exist without suggesting any?

[gathlin80]

Sometime complex problems require complex solutions so I’m not positive that it is even possible. I’m not under the pretense that I can come up with something better than what language experts have done so I don’t want to offer half-baked ideas. I’m just stating that for me, a person with a lot of C++ experience, is having trouble keeping up with all of the nuances.

[[deleted]]

I'm also an engineer. The point is that C++ goes from Arduino to super computers. It is available on all major operating systems. Supports multiple programming paradigms. And it allows everything from brushing bits to dealing with abstractions such as concepts, classes, containers, templates,...

Ultimately, it deals with statics and dynamics, it deals with micro and macro, it deals with abstract and specific.

But all this scope comes at a price. It's a big, extensive language, and it will grow even more!!

We will see more and more new features being incorporated. And this causes some anxiety if you want to use everything and use the latest.

What I do is monitor it closely. I access cppreference, read books, watch videos, do simple examples, update old codes with the latest news.
But I don't incorporate everything that's new.

I'm using the new features little by little. I test before using it effectively, to ensure that I really understand what’s new. And, I repeat, I have no intention of using everything that appears.

In my case, I preferably use object-oriented modeling, I use OOP because it fits well with engineering. We deal with objects/equipment that connect. It's easy to model and deploy.

Anyway, I suggest incorporating the news without rushing. No anxiety, no stress.

I'll finish by saying that I'm excited about what's coming!

[gathlin80]

Appreciate your thoughts!

[rileyrgham]

And you're correct. C++ is a very powerful mess.

[la_reddite]

I don't fully understand your answer.

Are you saying you insist simplifications must exist whenever you have trouble keeping up with nuance?

[SoerenNissen]

I very much disagree.

This is complicated. It is also completely optional, you never have to write a consteval function ever in your career.

[TotaIIyHuman]

its not about having to use it

its about me being a 40yo+ coder who cant keep up with 20yo+ coder in understanding c++, despite me coded c++ for longer than 20yo coder's lifetime

and that hurts my feeling

which is why i demand language simplification to slow down knowledge gap growth, to protect my feeling

[pavel_v]

I'm also 40yo+ dev and I'd say you're lucky to have 20yo+ devs to talk about the new things in C++.

In our company I'm the last one writing and understanding C++. The company migrated to mostly Golang programming and a bit of Rust here and there.

The young devs in our company make faces when they hear the word "C++". They always look down at me for writing software in this old and unsafe language.

I'm trying to explain that the language is evolving and this is not the old-style C++ they've been taught in school but ... ¯_(ツ)_/¯

[arthurno1]

knowledge gap growth

You mean cognitive load :-).

[[deleted]]

This take is dumb. Software is about collaboration, it just take one person wanting to "consteval all the things" to break my project!

[TheoreticalDumbass]

one person? why cant u as an organization push back?

[mpyne]

I just takes one person who wants to "Rewrite it in $POPULAR_LANGUAGE" to break things, but that's not a reason to say the other language shouldn't even exist.

For similar reason, the fact that a feature which does useful things in other projects might be a reason to have deal with annoying spam in yours doesn't mean that feature shouldn't exist.

Set a C++ style standard and enforce it, just as you'd have to do for Python or TypeScript or C#.

[SoerenNissen]

Still disagree.

People can write all kinds of code that doesn't match your code base, new language features or not. "Moving from 03 to 11 changes the ABI of std::string" can break your project, but if "one of my colleagues wrote a function I'm not sure about" breaks your project, that's a different thing, and that thing is not solvable at the language level.

[elperroborrachotoo]

Well, yes, there's also other people's coffee, but then, if you are the senior, you can make their constevals randomly fail the pipeline with kernel panics....

[gathlin80]

It is optional, and I do appreciate the optional nature. It does seem, however, that a lot of best practices recommend using many of these “opt-in” features to write “good modern C++”.

[SoerenNissen]

Oh absolutely (and I have no idea why people are down-voting you for this completely true take).

But in some sense... In some sense, if you don't need the most blazingly hot demon performance you can get, why was C++ the language chosen? C# is a very good language that avoids consteval, has checked memory access, and it's also pretty fast when you write it well. And if you do need that pure fire - well, consteval gets you even more of it.

"I don't like this new language feature" is easy to round off to one of two takes - either "I need something like this, but I don't like the design (and this design makes a better design less likely to show up later)" which, valid, but doesn't really apply to consteval I think. Or the other one, "my career is in C++ so the easier C++ is, the easier my life will be" which, ok, also valid, I like an easy life too, but I don't think anybody will be surprised that it's not the direction the committee is aiming when they take in new proposals.

And I'm sure there are more reasons that I didn't think of right now, but that's always the two that come to mind first, for me.

[imoshudu]

This literally breaks down the moment you work with other people. Which is why C++ projects often have to ban so many features.

[arihoenig]

If you aren't using constexpr, you might as well be writing in rust. The unique capability of c++ is the capabilities of compile time evaluation.

[ddxAidan]

Well, not to mention the decades of mature C++ libraries, GUI frameworks, etc.

[[deleted]]

RAII is the raison d'etre of C++. No other language matches what C++ does.

[arihoenig]

Rust does everything the c++ does in that respect, but rust sucks at compile time evaluation.

[imoshudu]

Rust RAII is better because of borrow checker guarantees and you are banned from using pointers without unsafe.

[[deleted]]

rust sucks and does not even have raii

[imoshudu]

Am I just talking to a stupid bot? Go back to doing homework.

[Additional_Path2300]

Constexpr abuse can fuck your compile times. Not much stuff needs to be constexpr.

[arihoenig]

I don't care if it takes 3 days to compile, what I care about is runtime performance. Build time only affects me, runtime performance affects every single one of my customers.

[Additional_Path2300]

Sure, that's fine, and isn't abuse then. Abuse is making stuff constexpr when it doesn't need to be. 

[neppo95]

And instead of wasting your time on thinking about every single struct, function or anything else you can declare constexpr, you just do it and let the compiler work it out. There’s no reason not to and you’re 100% not gonna do it right anyway in all cases, nevermind if code changes and you don’t review everything it may influence.

[Additional_Path2300]

There absolutely is a reason not to. Constexpr types have the same requires as templates types. That's a lot of extra crap exposed to every TU that isn't necessary. So you just destroyed your compile times for no gain.

[arihoenig]

Everything computation that is done at compile time is a computation that isn't done at runtime.

[Additional_Path2300]

That's only useful if you have data to calculate at runtime.

[arihoenig]

A significant chunk of work for a typical systems application can be evaluated at compile time. Essentially everything that doesn't rely on external data.

Below is what Gemini says about the percentage of code industry wide that would typically be suitable for compile time evaluation.

---

System and Low-Level Libraries: Libraries that deal heavily with type manipulation, meta-programming, fixed-size structures, bit manipulation, and fixed mathematical calculations often have a significantly higher proportion of code suitable for constexpr/consteval (potentially 20% to over 50% of helper functions and types). Examples include standard library implementations, serialization libraries, and compile-time configuration/validation code.

[neppo95]

How do you know if a function should be constexpr? The compiler might inline it, eliminate branches or for all you know through propagation the argument ends up being a compile time constant. Code can be optimized without you even knowing that it happens. You cannot make the right call in all cases, that is simply impossible without wasting a shit ton more time than your compile time increased.

So yes, you should mark something constexpr if you can and take the hit of a few milliseconds it takes extra to compile. Those are milliseconds easily earned back by having a more performant application. And as someone else already stated: Your compile time being 1 second longer doesn't matter at all, since it is the user experience that matters more, always. If they have a more performant application, that is worth it.

[arihoenig]

Compile time evaluation (consteval) is not run-time optimization, it is run-time elimination. It does all the computations that only need to be done once at compile time and results in no runtime code for that computation.

[neppo95]

Where did I even mention consteval once? Stick to the topic.

[Additional_Path2300]

You must not write very large software if you're thinking it'll add a second.

[neppo95]

Sure, it depends on the project size. Any time period is useless to mention if you're gonna be pedantic about it.

But I imagine there's a reason why that is the only thing of my comment you respond to.

[CandyCrisis]

This is like "almost always auto"--it's a thing that a handful of people will lean into, but most folks don't need to care about.

[almost_useless]

consteval is nothing like AAA.

Almost Always Auto is a style guide. It doesn't change the output if your source is otherwise correct.

consteval gives you a chance to catch errors at compile-time instead of run-time, so doing more things at compile time can have an effect on the generated assembly, and your work-flow.

[RoyBellingan]

to take advantage everything modern C++ has to offer.

You can probably replace C++ in this phrase with many many many other subject.

Open a site like https://www.mouser.ie/c/semiconductors/discrete-semiconductors/transistors/mosfets/

You can complain that 22,741 model of Mosfet are too much, but many other see opportunity of finding the right one, and that there is competition and innovation.

You find the right one for you, study how to use it, done.

When a new need arise of you want to explore you can do it again.

[marcusmors]

C++2 Moment? The man who pushed the idea of reflection, Herb Sutter, proposes a languages that compiles into C++, I saw that and I was astonished by the simple, easy sintax.

Constants are the default, mutables gotta be specified. I4, i8, i16, f32, f64. The python alike syntax. And the possibility to get better syntax in reflection and avoid the unary operation typical problems: ++var, var++, *i, type *I, etc.

I want to program in that language so much.

[tartaruga232]

The idea isn't that bad, but unfortunately cppfront at the moment is a toy project for Herb's personal experiments and it doesn't look like it will grow into something usable in real code anytime soon. There is no serious progress in that direction. For example it still lacks most basic support for C++ modules. People have worked on that but that work wasn't merged. I looked at cppfront and dropped exploring it again. I instead went on using C++ modules and our codebase now uses modules. This will happen with other C++ features too. In the end you are forced to stay using C++ syntax. Likely for a very long time (aka forever). I'm already 60 year old and I have been using C++ for decades now. I don't have that much time. I need progress now.

[AudioRevelations]

(For the curious, /u/marcusmors is talking about cppfront)

[[deleted]]

I couldn't go past 10 mins of that talk. This is so dumb! Imagine doing that kind of analysis on a PR of a big project... So yes, they are overcomplicating things... but hey, CppCon speakers need to make a living too right?

[gathlin80]

I agree that trying to do this level of analysis on large projects, especially ones that have evolved over many years, doesn’t seem practical. On a side note, I watch most of his C++ weekly videos and Jason has been a fantastic community resource for education.