CppCast - Reflection TS

Episode Date: May 2, 2019

Rob and Jason are joined by David Sankel to discuss the Reflection TS and more. David Sankel is a Software Engineering Manager/TL at Bloomberg and an active member of the C++ Standardization Committee. His experience spans microservice architectures, CAD/CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He is a frequent speaker at C++ conferences and specializes in large-scale software engineering and advanced C++ topics. David’s interests include dependently typed languages, semantic domains, EDSLs, and functional reactive programming. He is the project editor of the C++ Reflection TS, a member of the Boost steering committee, and an author of serveral C++ proposals including pattern matching and language variants. News ReSharper C++ 2019.1 More Responsive, Better for Unreal Engine, and with New Language Features Top 25 C++ API design mistakes and how to avoid them 2019 Annual C++ Developer Survey David Sankel David Sankel's GitHub Links C++ Reflection TS C++Now 2018: David Sankel "C++17's std::pmr Comes with a Cost" CppCon 2017: David Sankel "So, you inherited a large code base..." Sponsors Backtrace Announcing Visual Studio Extension - Integrated Crash Reporting in 5 Minutes Hosts @robwirving @lefticus

Episode 197 of CppCast with guest David Sengel, recorded May 2, 2019. and gaming platforms. Check out their new Visual Studio extension for C++ and claim your free trial at backtrace.io slash cppcast. And by JetBrains, maker of intelligent development tools to simplify your challenging tasks and automate the routine ones. JetBrains is offering a 25% discount for an individual license on the C++ tool of your choice. CLion, ReSharper, C++, or AppCode. Use the coupon code JetBrains for CppCast during checkout at JetBrains.com In this episode, we discuss ReSharper updates and API design. Then we talk to David Sankel.

David talks to us about the Reflection TS and more. Welcome to episode 197 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how's it going today? I'm all right, Rob. How are you doing? Doing okay. Been working on my house all week, rebuilding my deck. How about you? What are you up to? I have been traveling and teaching. And there is apparently just officially announced, by the way, that I am going to be speaking and teaching at NDC Tech Town in September. I didn't know that that official announcement had been made

until I saw other people tweeting about it. NDC Tech Town, is that the Oslo conference? It's outside of Oslo, but yeah. I'll fly into Oslo. It's outside of Oslo, but yeah. Yeah, okay. I'll fly into Oslo. It's September 2nd through the 5th, two days of workshops, two days of conference. Awesome. I heard that this is supposed to be an outstanding conference, so I am looking forward to it.

Very cool. And that one's not just C++. That one covers other languages and content as well, I believe, right? Yes, it is open to all kinds of things. So I haven't actually looked at the full schedule yet because, like I said, I didn't know that it had been announced until just now. But there's a lot of names that we recognize and have been on the show and a lot of people that we don't recognize, fortunately. So it'll be interaction with other humans. Awesome. It's always good. good always good interact with humans okay well at the top of our episode like through a piece of feedback uh this week we got a tweet from davir yachaki that's i apologize for butchering that name and he writes uh cvcast if you're still looking for a guest for the 200th episode

alex stepanov would be the ultimate choice um i certainly agree uh i think we did try reaching out to him a long time ago and uh did not have success yeah i've kind of been under the impression he doesn't tend to speak at conferences and doesn't tend to do interviews and doesn't tend to you know just do that kind of thing he's fully retired now yeah on top of just not doing conferences and stuff i think he's you know just enjoying his retirement which he has well deserved well sure yeah yeah uh we still need to come up with uh what we're doing for that 200th episode though um we should probably stop talking about it because it might just be a regular episode uh yeah if anyone has any other suggestions of someone we might be able to get uh please let us know it has to be a suggestion that you tell us within the next three weeks yeah right and it

has to be uh a really really good suggestion of someone who we can get yeah that's important and i don't even know i think i might still be traveling for um core c++ you'll be getting back to c++ probably yeah yeah we'll figure it out well we'd love to hear your thoughts about the show you can always reach out to us on facebook twitter or email us at feedback at speedcast.com. And don't forget to leave us a review on iTunes or subscribe to us on YouTube. Joining us today is David Sankel. David is a software engineering manager, team lead at Bloomberg, and an active member of the

C++ Standardization Committee. His experience spans microservice architecture, CAD and CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He's a frequent speaker at C++ conferences and specializes in large-scale software engineering and advanced C++ topics. David's interests include dependently typed languages, semantic domains, EDSLs, and functional reactive programming. He is the project editor of the C++ Reflection TS, a member of the Boost steering committee,

and author of several C++ proposals, including pattern matching and language variants. David, welcome back to the show. Thanks. Good to be here. And how many episodes ago was it again? David was on our episode number four. So it's been quite a while. That was before I joined, right? Yep. It was, yeah. You were our second guest jason and then uh you started

co-hosting like episode 9 or 10 right yeah so i am curious though what visual programming languages have you been involved with so i i was working with a visual programming language which uh i developed and it was um it had twofold applications so. So one was CAD-CAM, and the other one was for computer graphics and gaming. So it essentially is something similar to what you'd see in Houdini, which is a computer graphics software. So you have these nodes, and you connect them with lines and build your software that way. But it was based on a functional programming core.

So it had the power of something like haskell um which was unseen in visual programming languages up until that point so it's pretty cool wow so is that something that's still being worked on at all or not so uh the government has it and i don't know what they're doing with it. But presumably, yeah, it is still being developed, and they continue to use it for their secret things. So it's in the same facility as the Ark of the Covenant, in other words. Yeah, I think it's probably the building next door, but somewhere close. Okay, well, David, we got a couple news articles to discuss. Feel free to comment on any of these.

Then we'll start talking more about reflection and any other topics topics you want to go over okay sure okay so this first one is a resharper c++ update this is their 2019.1 release titled more responsive better for unreal engine and with new language features one of the first things to point out is I think this is the first release for Visual Studio 2019. I've actually been going back and forth between VS 2017 and 2019 when that came out, so it'll be nice to be able to use for Sharper C++ in 2019 now. And some other things to call out here,

they go into Unreal Engine support a lot, which I guess it's just a very large game engine and has some weirdness or differences about it that they're trying to help Unreal Engine developers with with this latest update. Well, did you notice this performance improvement? Yeah, it's pretty significant. 2,000 seconds is how much that's like several minutes to open up this example project um and now it's like more than 20 minutes yeah more than 20 minutes to open your project is what it used to be it's still like four minutes but that's way better and they highlight how it's a difference

mostly between opening up the engine code versus your games code right so they made it from like impossible to use to merely annoying yes yeah yeah um i think they also put in some things where you could just tell it to not index the Unreal Engine code, which maybe makes it even better. That would be handy. I think this is really exciting stuff. This can make C++ not suck worse than C Sharp. I had a discussion with somebody about 10 years ago where I was saying, Vim, you know, probably faster than you can navigate in anything. He's like, oh, yeah, well, check this out.

And he used ReSharper and C Sharp. And I was like, yeah, I can't do that. So I've been excited about this stuff ever since. And I tried it like five years ago. I think it was CLion. And I tried to do one of the refactors where you take a type def and it automatically opens it up

and replaces whatever all your typef usages with the definition. And it totally broke the code and didn't work. And I put in a bug report for it, and it was just this year they marked my bug as being fixed. So it's worth a second chance. So I'm definitely going to try this stuff out pretty soon. One of the things I love about it, and you talked about C Sharp, and when you're in C Sharp and you have all your using namespaces on the top,

ReSharper and maybe even Visual Studio itself without ReSharper can tell you, these ones you're not actually using, and I can just get rid of them for you. You can clean them up with one click. And it now does that in C++ with include headers. It'll tell you you're not actually using this include header. You can get rid of it and clean it up in one click, which is does that in C++ with include headers. It'll tell you you're not actually using this include header. You can get rid of it and clean it up in one click, which is really nice in C++. A bonus points if it could forward declare something that you're not actually using the definition of as well. That would be nice. Right click, fix all of my code. Thank you.

Someday, someday. Okay. Next article we have is top 25 c++ api design mistakes and how to avoid them um and i thought this was a pretty good resource for anyone maybe who's writing their first library and wants to know you know some of the pitfalls to avoid in library design there are any specific things that you liked in this, David? Well, actually, I was quite surprised at what they considered to be the things that make for a good API design. Like this article is really concentrating on like,

oh, you should tweak this with your C++ and you should do your C++ like that and all this. None of that stuff really has to do with API design. API design, I asked a few people around the office, what do you think is the number one most important thing about C++ API design? And nobody said that you put your functions in a namespace, which is number one in this article.

They all said something along the lines of having an API which meets your users' needs or things like being minimally complete and um and so i and this is kind of like this can segue into uh like the talk that i plan on giving uh next week at c++ now about software engineering um i think this is very much focused on programming things you can look at some of the most popular APIs and they don't meet this criteria. Like just take the first one. Probably if it's not number one, it's in the top two most popular C++ API for doing 3D graphics. What is it? OpenGL. And OpenGL doesn't use

namespace. So why is it successful? And obviously it does it because it wants C compatibility, but even so, it's still successful in C++. And I think that the reason is because it meets the user's needs, right? People are looking for a low-level graphics API with 3D graphics, and it has the right functionality. It has the right level of abstraction, and that is what makes something successful, not because you have a header with some of the implementation details in the header right level of abstraction. And that is what makes something successful. Not because, you know,

you have a header with some of the implementation details in the header, or ABI compatibility, these kinds of things. So I was actually quite surprised at what they considered to be the mistakes here. Okay, I've never written OpenGL code. But just to play devil's advocate here just a little bit, is it possible that OpenGL is so successful because it is literally an industry standard and there is no other choice? Whether or not it's a good API? I think that that's a big aspect of it. Another reason as to why an API gets adopted is because it has critical mass or it has the right kind of implementations. So it was successful because it had an implementation which worked really well on all this different hardware.

I mean, if it was just a spec and nobody implemented it, it wouldn't be popular at all. But that has nothing to do with the arguments that were used in the particular functions or naming conventions or anything like that. It has to do with these other factors, and that's what I think really contributes to the success of an API, are these other things. Right. Yeah, that's good points.

The last thing we have here is the 2019 Annual C++ Developer Survey. It's not really much to talk about, but it's definitely worth filling out to help. I guess it's the ISO, C++ Committee committee that winds up looking at these results, right? Yeah.

I think so. Yeah. This is the third year? I think so. Seems right to me. Yeah. So yeah, help out the committee. They do lots for us and they want to know how you use C++.

Okay. So David, you already mentioned you're going to be giving one talk just about kind of engineering, but your keynote is going to be on the Reflection TS. Is that right? Yep, that's right. Can you tell us a little bit about what the current state of the Reflection TS is? I don't think it's something we've talked a lot about to C++. And what this means is, well, the first key thing to keep in mind is that we already have reflection in C++. We just don't call it that.

If you want to take a type and say, is this type marked with const? And then make some compile time decisions based on that. That's something we can already do in C++, right? This is metaprogramming 101. And what the reflection TS does is it gives you the capability of things that weren't previously possible in terms of reflection. So while you could do a lot of reflection with C++, you couldn't, for example, say, given this arbitrary type as a template parameter,

give me the name of that type as a string and then do logic based on that so reflection is providing this this capability so the so the current state of the ts is uh it went through this process where we got national body comments we published the ts and got national body comments and we're taking the national body comments we've decided which ones we want to apply to the working paper and we're modifying the working paper and then we're just going to publish it so it's at the very final stages and it's actually on me to make sure we do all these comments and that'll be out probably before the next standardization meeting so but there's no chance of that actually making it into c++ 20

or how is that going to work yeah so so ts, they generally sit in a TS form for a little while before you merge it into the working draft. Now, reflection is kind of in a special case because there's a lot of desire to modify the API that we've provided into something which is constexpr-based. So what's going into C++ 20 are a lot more constexpr-based. So what's going into C++20 are a lot more constexpr functionality, so you can do allocation at constexpr time. And we need that if we ever want to do something like reflection. We want to be able to say,

give me the data members of this type, and it has to return a vector, as opposed to what it is right now, which is a template metaprogramming list of other types and then inspect things that way. Um, so what will probably end up happening is that after this TS gets published, what we'll see in C++ 23 is using the base, like the core, uh, reflection machinery that's in the TS, but with a different surface syntax, which much more closely resembles constexpr metaprogramming type API.

Okay. So we'll get the TS, and then we'll get a refactor of that based on how things work out for C++20. Yep, exactly. Okay. Yeah, so I guess you kind of already answered this question, but I was doing some research on reflection before the show, and I saw that Her herb sutter actually declared back after rapper's will that the reflection ts was feature

complete um so that's you know you agree with that it's feature complete but we're gonna change it after school plus 20 you're saying yeah i think feature complete in the sense of we know what we're going to be exposing and we know how to write this in wording, and we know how to implement this. So the core functionality that Reflection is going to be providing, at least initially, is feature complete. But the service syntax is definitely something which is undergoing change. We have two different competing proposals. One of them is the same team that I'm on that produced the reflection TS and the other one is another team. And we're trying to see how we can get

consensus by merging the two or just making a decision in terms of what we want the interface to look like. But the big controversy right now is when you reflect on something, do you want that to return a value of a particular type, or do you want it to return some universal type for all reflected entities? And there are benefits and drawbacks to both. The benefit of having specific types is much more like what you would do in normal C++ code. You want to have a specific type.

If I reflect on a type, I want to get a metatype. If I reflect on a type, I want to get a metatype. If I reflect on a value, I want to get a meta value. But the problem is that with the evolution of C++, whatever we choose as our type hierarchy, so to speak, we're potentially locking ourselves in, and we may further restrict

how C++ can evolve. So that's where the proponents of just a single type, that's the main benefit of that approach. So we're seeing if there's somewhere in between or what we can do to kind of like resolve this lack of consensus about this design choice. So at the moment it is multiple types, right? At the moment it's an opaque type because everything is metaprogramming at this point. So what you get when you reflect on something is a type, and that type satisfies certain concepts. So if you reflect on a type, whatever the return type is, you don't get to name it, it satisfies the metatype concept.

And that has certain operations which are associated with it and such. Such as? Like give me your name, give me your data numbers, are you an enum, are you a class, these kinds of things. Okay. So if it's a function, then presumably some of these meta operations are the return type, the number of parameters, types of parameters as well? Yeah, absolutely.

So that was one of the things that we added that we really wanted to see in it before we published, is being able to reflect on function declarations. So you can see what the arguments are, you can get the names of the arguments. So as you can imagine, a very immediate use case for this would be you write a class with a bunch of member functions and you say, make this into a REST API. And then you have all your parameter names and those can be used as the part after the question mark and your REST API things along these lines. So I was immediately actually already thinking of parameter names. We can redeclare a function as many times as we want to with different parameter names. How would that affect reflection?

So that was a very actually important design discussion that we had around that. And we came to the conclusion that the only way that we can do this to where the compilers don't completely blow up is that we give the guarantee that if you're consistent with all of your function declarations, with all the different parameter names, then you're going to get the result that you would expect. If you're inconsistent with all of your function declarations with all the different parameter names uh then you're going to get the result that you would expect if you're inconsistent with your declarations uh we're we're saying you don't really know what you're going to get you're

going to get one of the declarations said but you don't know which one it's not like the first or the last because that's actually hard to define with a delayed template and statiation and stuff like that right interesting back Back to the drama you said with the two competing reflection proposals, which side of that do you lie on? So being someone that... So it's really compiler writers staked against people who design a lot of APIs.

So I'm on the API side, and I want a really good, consistent API that people will recognize as a good API and that they can use, and it's not something really strange. So that's where I fall on that. I like to have the explicit types and to be able to write a function which takes in as a parameter a metatype. And you don't accidentally call that with a meta value or something along those lines. My preference is, like, one of the main goals of this whole approach is that we make this metaprogramming available to mere mortals,

you know, people who don't typically write template metaprograms. So, you know, taking a function with a parameter of type metatype is something they can all understand, whereas with the other competing proposal, you're going to have to write a function which takes in a value of this other type, but you have a concept which constrains the values that can possibly come in. And it's just, it opens up, you can do it, but it opens

up a lot more complexity. Like you have to understand concepts, you have to understand passing of non-type template parameters and things along those lines. I don't like iterating over the elements of a tuple. For example, if that's what we're talking about, if it's a tuple of types or something like that with template metaprogramming stuff, that's painful, it's difficult to work with unless we get the four dot dot dot syntax at some point and C++23 or something. So I see the constexpr side,

but on the other hand, if I'm going to be doing template, or if I'm going to be generating some sort of code at compile time, with the reflection TS, I could see that I need to know the actual type of the return type. Like I need a type right there, not something that just happens to represent a type and gives me the name of the type or something. Yeah, absolutely. And so with what's currently in the reflection ts because we're all in type land anyway it's very easy to provide a meta function which returns the type the type corresponding to a meta type right um using the constexpr time uh meta programming uh we're going to have to have

an unreflect operation so you you can take a metatype and unreflect it to get the corresponding type and then use that in your code. Is it safe to say that that could only be implemented with compiler support, the unreflect? Yes. Okay. All right. So you said you know how to implement it. Is there an implementation? So we do have a demonstration implementation. Matush, one of the co-authors of the Reflection TS,

has that available in his repository. And he's actively working right now on getting this into mainline Clang so that Clang will have a dash, Reflection dash TS, and then other people will be able to use this in a more standard way. Okay. It's exciting. I want to interrupt the discussion for just a moment to bring you a word from our sponsors.

Backtrace is the only cross platform crash and exception reporting solution that automates all the manual work needed to capture, symbolicate, dedupe, classify, prioritize, and investigate crashes in one interface. Backtrace customers reduced engineering team time spent on figuring out what crashed, why, and whether it even matters by half or more. At the time of error, Backtrace jumps into action, capturing detailed dumps of app environmental state. It then analyzes process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. With your work on Linux, Windows, mobile, or gaming platforms, Backtrace can take pain out of crash handling.

Check out their new Visual Studio extension for C++ developers. Companies like Fastly, Amazon, and Comcast use Backtrace to improve software stability. It's free to try, minutes to set up, with no commitment necessary. Check them out at backtrace.io slash cppcast. So your keynote, it says you're going to talk about the exciting new language feature, demonstrate how it's used. I don't want you to give away your whole keynote, but what are some of the exciting things you're looking forward to being able to do with reflection? Yeah, so just, you know, you take your typical, like a typical programmer problem. Let's say you have a type and you want to write a function which can serialize it to JSON and then deserialize it from JSON.

What people are doing right now for this is they're writing a custom function for every single type that they have. Because they need to know the names of the data members, they need to know the name of the class. And then they recurse into these other functions which you know convert to and from json with the reflection ts um someone can write and now with the reflection ts it will have to be an advanced c++ developer can write to json and from json in a generic way that it'll just work with all types so if you have any type and it happens to use standard things like vector inside of it or optional and these core vocabulary types, you get to JSON and from JSON for free. So you're able to scrap that entire boilerplate.

Another interesting example is, one of my favorites actually, is command line argument parsing. So there's so many different ways of doing this, and nobody's like come up with something which is like incredibly satisfying with command line parsing. But what you could potentially do is write the data type of the command line of the parsed command line object.

And say it has like some optional data members and it has some list data members and so on and so forth. And you can say, go, go, gadget, give me command line parser, and it will interpret the names as command line arguments. It will interpret whether or not it's optional to decide whether or not it's an optional argument, and it will parse your command line into the data type directly with just one line of code in main. And you have implemented something like this? Yeah, well, so with the command line pars parsing like we've implemented it on whiteboard i know that uh it's c++ now a couple

years ago um i there was a presenter i forget her name uh but she she she did implement some of the stuff with uh matusha's uh example code and and command line parsing was one of the things that she implemented and and that's And that's just super cool. Because nobody's happy with their command line parsing library. Wait, are you guys happy with your command line parsing libraries? I am actually fairly happy with the one I'm using. I'm keeping it simple at the moment. But I'm using Phil Nash's Clara, which he built for Catch.

So once you see a reflection-based one, then you will be unhappy with your uh command line person you say that was a talk sepals was now a couple years ago yes uh jackie was for that oh jackie jackie k did that yes exactly okay thanks okay yes all right that might have been two years ago then yeah sounds right. And you're also giving a talk titled Engineers Wanted, Programmers Not So Much. What is that talk going to be about? How do you view the difference

between an engineer and a programmer? I'm so glad you asked that. This talk is the one that I am most excited about. I feel like this is an important corrective for the C++ community in terms of the things that we focus on. So one of the things that I'm doing in this talk is I've interviewed several engineers in different disciplines, like a chemical engineer and a mechanical engineer, and tried to understand in these more mature disciplines what they do on a daily basis, what they think about their projects they're working on.

So, like, one example would be a chemical engineer that I know. One of the things that he does is he designs columns for, and the way that columns work in chemical engineering is you put your base substance in the bottom of the column and they go several stories high and at the very top you pull out the good stuff and in between you have all these different devices which um which you know pull out you know various pieces of this uh this prime material and then the very top you get out in this case is uh ethanol like pure ethanol and when when it comes to uh what he does a daily basis, he can design a column and he has to do that as part of his job. But that doesn't happen that often. More often than not, he's trying to work with a living system, a living plant, a living factory, and trying to do changes to it. He has to do renovations or something breaks down and he has to make improvements to it. They have to decide what they want to, if there's a new business need,

they might need to do anything. One thing that was really interesting is he took another plant at a factory that was for sale really far away and he had to move that plant and somehow integrate it with his existing system, like an extremely difficult problem. And that's the kind of work that he has to do. Now, if we translate that to software engineering, what we see is that very infrequently, do we do greenfield development? Do we just like write code from scratch and, you know, put it out there and then we're done? More often than not, what we're doing is we're taking existing systems and figuring out how we can modify them, how we can make improvements and how we keep the thing running. So the software engineer needs to concentrate on things like migration plans and not disrupting production issues. And how is the user going to react if you change their user interface a little bit? These kinds of things. So one of the things that Titus Winter says is he says that software engineering is programming

integrated over time. And I think that's a good approximation. So what we see at a lot of C++ conferences is very much of a focus on programming. But in the real world, or if you have a software engineering job, that's actually not the most important thing. When you care about programming, you care about putting const in the right place. But when you look at it from a software engineering perspective, that actually doesn't really matter that much in the scheme of things. Your focus is on other things. It not it's not unlike you know the little

syntax and and things like that it's about how can we uh how can we apply this to a living system and when you have a large software development organization you have to work within the context of the software developers that you have are people trained in this if you do some crazy template metaprogramming thing when you leave are people going to be able to maintain this you know does it really is are you solving the right problems so these are all issues of software engineering and so the the talk is really how do we focus as a community on the issues that we really face on our in our day jobs which are software engineering issues as opposed to uh programming issues interesting so i mean how do you think we should be changing as a community

to better focus on software engineering versus programming problems? That's a good question. So I think that one of them is we need to have a vocabulary for talking about these issues. When we talk about programming, there's a big concentration on correctness. You write a contract. Does the implementation meet the contract? If it doesn't, there's a bug. And the idea is you want to write correct code. But there's a whole bunch of other issues that are just on the side. What about performance?

Okay, so we have this big O, but whether something meets some particular big O criteria does not tell you whether or not this piece of software is going to actually have the performance it requires for this particular use case. In another sense, you have this idea of security. Is this software secure? How does that fit into our vocabulary? And so the big idea behind this talk is this idea of software fitness. Is a piece of software fit for its purpose? And how do you tell if a piece of software is fit? And like in Darwin theory, the best way to

see fitness is to put something into a hostile environment. Whether that's production, do you see if a piece of software fits in production? Or in the case of security, how do you know a piece of software is secure well if you have a security team of like the best and brightest security people who are constantly trying to break your software and they are unable to do so then you can say well i think the software is pretty secure but if you don't have that then you don't really know i mean you can you can guess and you can hope but the best way to see whether something is fit is to put it in a hostile environment and see if it survives. And I really think that this concept of software fitness covers correctness. It covers security. It covers all the different aspects, whether or not an API

is usable by the people that you're trying to deliver it to. All of this can be encompassed in this idea of software fitness. And if we start talking about and thinking about software in this way, I think we're going to advance the field of software engineering to where we can start to catch up to engineering and other disciplines. Okay. Now you are giving this talk at a C++ conference. I mean, is there anything C++ focused around your ideas with software fitness so or is it more general programming so i think that i think that is definitely applies to general programming um the idea of the audience being c plus plus is i'm going to be speaking in the language of c plus plus and things that c plus plus developers understand but one thing that is

very closely tied to c plus plus and software engineering is the c++ programming language itself because from the very get-go c++ was designed with this fitness idea in mind it wasn't explicitly thought about that but the reason that c++ had c compatibility was because there's a bunch of c code out there if there there wasn't C code out there, there'd be no need to write C++, you know, and make it look exactly like C. So C++ is written in the context of C being widely used. And even today, when we talk about modifying C++, we always very, very much care about this backwards compatibility. Why? The reason why is because that is what is going to make C++ successful is this continual backwards compatibility.

C++ as a language is now tied to all the C++ code, which was already out there. So while other languages, you could take Rust or whatever, they're just like, well, we'll just throw it all out and we'll just start from scratch and we'll do things a lot better.

It's a lot easier to do that, but you're not going to get the kind of adoption that you would get with another revision of c++ so c++ you know it evolves a little bit slower but it's always going to be there at the very top because of this focus on uh software engineering and i don't know i don't know if you guys saw this uh this recent survey result but c++ just got above python in one particular survey in terms of usage it so python deceded it and then c++ came back you know it's like muhammad ali just keeps on coming back and i think that the reason why is because the the standardization committee is very much focused on uh this backwards compatibility in

terms of like improving things in a way in the context that C++ is in right now. Like another example is, you know, C++ does do breaking changes and we will, we're just, we're willing to break like a very small subset of the community. We don't care about, you know, if one crazy metaprogrammer is depending on this really weird thing out there, we'll break them. But if we're talking about 25% of C++ developers are going to have to make major changes to their code, we're not going to touch that. It's not worth it. I could be wrong, but I think the first breaking change was the reuse of auto.

But it didn't actually break any real code. Yes, exactly. When you're talking about the case of an engineer, a chemical engineer, that's talking about buying a plant and trying to integrate it with an existing system and whatever, I was thinking about the fact that an engineer has to do that with a lot of planning. Not like programming, where we change something and see what breaks, and change something else and see what happens and just keep trying things. And I know there's been a couple of well-known speakers who have said things.

I think Sean Parent, maybe someone made a comment about how he'll think about a project for a while before actually writing any code down. I feel like we talked about that on the show relatively recently. That seems like a very different mentality from what we all tend to do. Yeah, I totally agree. Like the planning phase, you know, in big software engineering projects, what you have is you start with a proposal. And then the proposal gets scrutiny by a whole bunch of stakeholders. And only then do you start going into like architectural design. And then that gets scrutiny by a whole bunch of stakeholders. And only then do you start going into architectural design,

and then that gets scrutiny. And then all the way to when you get down to writing the actual code, the code reviews is another degree of scrutiny. So the planning stage in that aspect of software development is much more exaggerated for a software engineer rather than a mere software developer i've only worked on one project that was large and totally designed from the top level you know and then basically a bunch of programmers were hired to just like type in the design effectively um this was a long time

ago actually and it was interesting because the object model they're using like a rational or something to design it right the object model was big enough that they couldn't actually automatically generate the code from the object model because it would crash that part of the system so they just hired a bunch of us to just basically type in the design that could that really honestly could have been automatically generated. That project felt to me highly over-engineered. Like there could have been a simpler way to do this. And maybe that speaks to some of the, like we're a young industry

and we don't really necessarily know what we're doing in a certain sense. I don't know. It kind of ties back to software fitness. So one of the things that we realized really early on is this agile thing seems to get you successful much quicker. And if you're trying to get a prototype to get people to continue to fund your activity,

get the software out there, get this rapid feedback, all of that is what's going to define success in the early stages of a project. But in the later stages of a product, you know, when we're talking about maintainability and integrating with existing systems and things along those lines, you have to take a different approach because you're in a different environment. So agile isn't wrong. It's just you need to know when to use it, when you need to deploy it, and doing more thinking about something beforehand that also has its place. So we need to understand better when

we need to choose which and do which. Right. Okay. Well, it's been great having you on the show today, David. Good luck with your upcoming keynote at C++ Now. Yeah, thanks. Really appreciate it. Yeah, have fun. I'm sad that I won't be able

to make it to the conference this year. Oh, bummer. Yeah, just too close to Core C++, but that's fine. All right, next time then. Yeah. Okay, thanks, David. Thank you. All right, thank you.

Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast

on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.