31 ms·

"Within C++, there is a much smaller and cleaner language struggling to get out"

54 points by mpiedrav 7y ago

munificent 7y ago
The problem is no one can agree what that language is.
mpiedrav 7y ago
«"Within C++, there is a much smaller and cleaner language struggling to get out". Yes, that quote can be found on page 207 of The Design and Evolution of C++. And no, that smaller and cleaner language is not Java or C#. The quote occurs in a section entitled "Beyond Files and Syntax". I was pointing out that the C++ semantics is much cleaner than its syntax. I was thinking of programming styles, libraries and programming environments that emphasized the cleaner and more effective practices over archaic uses focused on the low-level aspects of C.»
einpoklum 7y ago
We are actually seeing it gradually, but not as the smaller-cleaner language. Rather, as cleaner idioms channeling the spirit of that language - within an ever-widening C++.
- Koshkin 7y ago
  > spirit I think it would be a good name for the new language (if it ever shows; it will probably be a lisp).
  - deleted 7y ago
    [deleted]
  - AnimalMuppet 7y ago
    If by "it" you mean the much smaller and cleaner language within C++, no, it will absolutely not be a lisp.
  - paulddraper 7y ago
    That's like saying Rust will turn into Lisp. There is way too much around memory management to be Lisp.
  - blondin 7y ago
    you are so right! i too love that name for a programming language. i vote for a modern, typed curly-less language, with written end of blocks if that's not too much to ask :)
- paulddraper 7y ago
  Agreed. RAII, smart pointers, optional...C++ is become cleaner and cleaner. Unfortunately, that's not simpler, as the old stuff still works too.
  - favorited 7y ago
    There are competing ideas of how to get to a world where C++ can have both (1) backwards compatibility and (2) the removal of old language features. Some people disagree with that concept entirely (including Bjarne, IIRC) because of the fear it will fracture the language. But luckily the conversations and proposals are actually happening.
- wolfspider 7y ago
  Yes, I can see it too the coroutines in C++20 is a nice step in that direction.
- justAnotherNET 7y ago
  What you call a spirit younger programmers call a decrepit ghost haunting our futures.
DoofusOfDeath 7y ago
Sometimes C++'s evolution reminds me of the quote from Antoine de Saint-Exupery: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." [0] When the topic of C++'s huge and growing complexity comes up, opinions mostly fall into two groups: (a) the language is way way too complex, and (b) ... yeah, but modern C++ is really clean and you can just ignore all the complexity that's been retained for backwards compatibility. I don't find (b) persuasive because every line of C++ code is interpreted by the entire language standard. If (b) really is true, then I'd be interested in seeing a new language that has only the subset of the C++ standard considered "modern". If that language was actually useful, I'd eagerly use it in practice. [0] https://www.brainyquote.com/quotes/antoine_de_saintexupery_103610 https://www.brainyquote.com/quotes/antoine_de_saintexupery_1...
- wvenable 7y ago
  The problem is that everyone's ideal subset of C++ is different because everyone has different requirements! "A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%." https://www.joelonsoftware.com/2006/12/09/simplicity/ https://www.joelonsoftware.com/2006/12/09/simplicity/
  - jchw 7y ago
    C++ is probably a little different. There’s a lot of ways to do things due to accumulated cruft, for example. I’d wager at least a good 20% of C++/STL is to some degree redundant.
  - groby_b 7y ago
    Worth keeping in mind: Joel's pulling stats from a very dark spot, located somewhere behind. In reality, there are common features, and there are rare features - there's just rarely a product manager willing to give up users for clarity of vision.
- FpUser 7y ago
slavik81 7y ago
My favourite Stroustrup quote on the design of C++ is probably from "How can you be so certain?": > One of my fundamental aims for C++ is (from the very start in 1979) to provide equally good support for user-defined and built-in types. For example, I’d like to be able to build an integer type that is as good as the built-in int in every way
edoo 7y ago
I use what I call "C+" which is C plus classes, basic templates, and light polymorphism when it is absolutely perfectly suited. I'd like to explore a lot of the later features but I haven't had the drive to do it. I write a ton of embedded C for money and learning C++ has lifted my C skills tremendously. It forces you into certain paradigms that you can easily do in C if you have the discipline.
- MetallicCloud 7y ago
  As a primarily C++ developer, I absoloutly hate maintaining code that is written like this. C has it's place in the world, but despite the fact that the language has a large amount of overlap in syntax, they are very different languages. Trying to write one in the style in the other will, at least from me, earn you some very bad thoughts.
  - ncmncm 7y ago
    I agree. The more code looks like C or early '90s C++ (not to say Java), the worse it is. The newest language features exist because the language is better with them, and code is better when it used them. That is not to say that every function, or every program, has to use every obscure feature. Many features are there only to support very specialized use cases (which absolutely exist, and are important!). But things like new-style loops, generic lambdas, structured bindings, and little helper templates make writing and reading code enormously more pleasant.
Ididntdothis 7y ago
It would be kind of neat if there was a definition of different levels of the language and you could specify which level you allow in the file. This would be stronger than running a code style analysis tool. Not sure how viable this is but it would be nice to somehow phase out things like auto_ptr and others in projects.
CriticalCathed 7y ago
Why do we need to try to streamline C++ here? What's behind the urge to "cut out the fat"? Would doing this make C++ an even better performing language? What's the upside of gutting the language? I don't understand the impulse here. Yes, the semantics of C++ are more elegant than the syntax. But that doesn't mean that the syntax is actually cumbersome.
- favorited 7y ago
  Having so much syntax makes the language more difficult to learn, and you have to know the edge cases of each. It's universally recognized that, since C++11, you should use the `nullptr` keyword to create a null pointer. `nullptr` solves problems like not being implicitly convertible to integers, so you don't get the wrong overloads or template specializations. However, it's still perfectly valid to initialize a pointer to the NULL macro, etc. There's no benefit, but it's still all throughout codebases, so people will keep using it. Wouldn't it be nice if there was just one way to initialize a null pointer in new code?
dana321 7y ago
If they take the C out of C++ Call it ++ Basically get rid of everything that the legacy of C brings. If you want those things you probably should be coding C. Get rid of the headers .h etc. Build that from the source .pp files Make a standard package library that works properly on all platforms. Standardize the internal symbols. Make templates / everything easier to use, make standard internal map and vector types. Change auto to var. Kinda like the way go did it. Sorry, too late!
- einpoklum 7y ago
  > Basically get rid of everything that the legacy of C brings. This is actually happening, but not literally. That is, most of the things you used to write in a C-like fashion - you no longer write today: * References or plain values instead of pointers. * std::arrays or other containers instead of plain arrays. * std::variant's instead of unions * std::expected instead of returning error codes (although error handling is a really complex issue) and so on. > Get rid of the headers .h etc. This will start to happen in C++20, with modules. > Make a standard package library that works properly on all platforms. The standard library works well on many platforms. If you mean package management systems - that's never part of the language; but you can check out https://conan.io/ https://conan.io/ > Standardize the internal symbols. Sort-of happening with modules, if I understand what you mean. > Make templates / everything easier to use, C++ features are actually easier to use as the standardization progresses. > make standard internal map and vector types. Whaaat?! Ha ha ha, certainly not. You really don't want that. > Change auto to var. That is rather inconsequential... > Kinda like the way go did it. What you suggested is in no way specific to Go.
- 72deluxe 7y ago
  Templates are easy to use? The messages that come about from getting them wrong aren't always the best though. I don't understand why people want to get rid of headers at all? Can anyone explain why? In C# I have no headers and I find it far more difficult to read a class or get an overview. "make standard internal map and vector types" What do you mean by this? I want to be able to use the right container for the job. I don't want a dumb array of any type like PHP arrays. That's appallingly bad because you can above garbage into them and the user of the array has no guarantees about what is in it. Might as well use void* everywhere and chuck the type system in the bin if you really want that? Or have I misunderstood? Also changing auto to var - why??
jariel 7y ago
It's not just language: it's support, tools, compiler etc. I just spent a day trying to get C++ working properly for a specific project in MSVSCode, surprisingly, it won't work, there are arcane and cryptic bits of help on StackExchange, and the sheer amount of inclusion variables, paths, special cases, compiler settings etc.. is beyond bewildering. It takes far too long for someone to develop the competency just to manage anything more than a trival build and this is a failure of the language because there's simply no reason for it - it's 'arbitrary complexity'. We're wasting serious chunks of our lives solving problems that shouldn't exist in the first place.
- btilly 7y ago
  As https://blog.plover.com/Unix/tools.html https://blog.plover.com/Unix/tools.html says: The bizarre mishmash of weirdness exists because so many different people invented so many tools over such a long period. And they wouldn't have done any of that inventing if the compositionality hadn't been there. I think we don't actually get to make a choice between an incoherent mess of composable paraphernalia and a coherent, well-designed but noncompositional system. Rather, we get a choice between a incoherent but useful mess and an incomplete, limited noncompositional system. I agree that C++ development can be a mess. But it is often a mess for good reasons, not bad.
  - jariel 7y ago
    Yea, I agree. That's a good quote. I also would really like a 'strong agent' to just come along and do a 'new C++' without the cruft, kind of along the lines of the 'go' philosophy without necessarily inventing a new language. Maybe Rust is de-facto that. Or maybe D is it and we're not playing close enough attention. I guess your point is further validated by the hot mess of the web as well: javascript is a monster, somewhat tamed by TypeScript ... and I don't think Dart or anything else is poised to replace it.
roca 7y ago
"... and we will find that language, and we will kill it."
roca 7y ago
It's not really true that "the semantics of C++ aren't that complicated". Once you take into account undefined behavior --- which you need to, so you can avoid it --- it's so complicated that researchers haven't yet figured out what those semantics are.
userbinator 7y ago
...and that "smaller and cleaner" language is C. ;-) I'm only half-joking, of course; but while I see the beginnings of C++ were humble and practical, as a way of simplifying common idioms in C, it seems that lately the emphasis is more on turning the abstraction level to 11 with things like deeply-nested deeply-parameterised templates and writing otherwise "opaque" code that is short at a glance but entails considerable and often needless hidden complexity. I think Stroustrup himself is somewhat aware of that, given that he even references the infamous "fake interview" on that page --- and while that was a fake, the sentiments expressed in it certainly have a basis in reality.
- favorited 7y ago
  That's pretty much the opposite of the point he was making. His context is: > I was thinking of programming styles, libraries and programming environments that emphasized the cleaner and more effective practices over archaic uses focused on the low-level aspects of C.
lmm 7y ago
The small clean language wasn't really there. Not having sum types is why exceptions are like they are. Not having had first-class functions until recently is why control flow is like it is. Not having a proper type system is why templates are like they are. Those things between them are why concurrency is the way it is. You can't remove things from C++ to get a nice language - you need to start with a better foundation.
cryptonector 7y ago
> What is "legacy code"? > "Legacy code" is a term often used derogatorily to characterize code that is written in a language or style that (1) the speaker/writer consider outdated and/or (2) is competing with something sold/promoted by the speaker/writer. "Legacy code" often differs from its suggested alternative by actually working and scaling. Oh? To me legacy code is code that's been put into production. The moment it's in production, you have to maintain it, you have to worry about backwards compatibility and interoperability. The moment it's in production the field is no longer green. Perhaps production code is only legacy code the moment you want or have to change it, but since that almost always ends up happening, so the moment it's in production, it's legacy.
kazinator 7y ago
That smaller language is basically the C++ described in the Annotated C++ Reference Manual (a.k.a. Brown Book) by B. Stroustrup and M. Ellis, published in 1990. I landed into my first C++ job not knowing C++. Friday was my last day on the previous job. I helped myself to a stack of paper and printed out the entire ISO C++ draft standard. I also got that ARM. I read the ARM over the weekend, then went to the new C++ job Monday. I was C++ "answer guy" a month later. This one: http://www.stroustrup.com/arm.html http://www.stroustrup.com/arm.html

54 points by mpiedrav 7y ago

The problem is no one can agree what that language is.

«"Within C++, there is a much smaller and cleaner language struggling to get out". Yes, that quote can be found on page 207 of The Design and Evolution of C++. And no, that smaller and cleaner language is not Java or C#. The quote occurs in a section entitled "Beyond Files and Syntax". I was pointing out that the C++ semantics is much cleaner than its syntax. I was thinking of programming styles, libraries and programming environments that emphasized the cleaner and more effective practices over archaic uses focused on the low-level aspects of C.»

einpoklum 7y ago

We are actually seeing it gradually, but not as the smaller-cleaner language. Rather, as cleaner idioms channeling the spirit of that language - within an ever-widening C++.

Koshkin 7y ago
> spirit I think it would be a good name for the new language (if it ever shows; it will probably be a lisp).
- deleted 7y ago
  [deleted]
- AnimalMuppet 7y ago
  If by "it" you mean the much smaller and cleaner language within C++, no, it will absolutely not be a lisp.
- paulddraper 7y ago
  That's like saying Rust will turn into Lisp. There is way too much around memory management to be Lisp.
- blondin 7y ago
  you are so right! i too love that name for a programming language. i vote for a modern, typed curly-less language, with written end of blocks if that's not too much to ask :)
paulddraper 7y ago
Agreed. RAII, smart pointers, optional...C++ is become cleaner and cleaner. Unfortunately, that's not simpler, as the old stuff still works too.
- favorited 7y ago
  There are competing ideas of how to get to a world where C++ can have both (1) backwards compatibility and (2) the removal of old language features. Some people disagree with that concept entirely (including Bjarne, IIRC) because of the fear it will fracture the language. But luckily the conversations and proposals are actually happening.
wolfspider 7y ago
Yes, I can see it too the coroutines in C++20 is a nice step in that direction.
justAnotherNET 7y ago
What you call a spirit younger programmers call a decrepit ghost haunting our futures.

DoofusOfDeath 7y ago

Sometimes C++'s evolution reminds me of the quote from Antoine de Saint-Exupery: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." [0] When the topic of C++'s huge and growing complexity comes up, opinions mostly fall into two groups: (a) the language is way way too complex, and (b) ... yeah, but modern C++ is really clean and you can just ignore all the complexity that's been retained for backwards compatibility. I don't find (b) persuasive because every line of C++ code is interpreted by the entire language standard. If (b) really is true, then I'd be interested in seeing a new language that has only the subset of the C++ standard considered "modern". If that language was actually useful, I'd eagerly use it in practice. [0] https://www.brainyquote.com/quotes/antoine_de_saintexupery_103610 https://www.brainyquote.com/quotes/antoine_de_saintexupery_1...

wvenable 7y ago
The problem is that everyone's ideal subset of C++ is different because everyone has different requirements! "A lot of software developers are seduced by the old ‘80/20’ rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%." https://www.joelonsoftware.com/2006/12/09/simplicity/ https://www.joelonsoftware.com/2006/12/09/simplicity/
- jchw 7y ago
  C++ is probably a little different. There’s a lot of ways to do things due to accumulated cruft, for example. I’d wager at least a good 20% of C++/STL is to some degree redundant.
- groby_b 7y ago
  Worth keeping in mind: Joel's pulling stats from a very dark spot, located somewhere behind. In reality, there are common features, and there are rare features - there's just rarely a product manager willing to give up users for clarity of vision.
FpUser 7y ago

slavik81 7y ago

My favourite Stroustrup quote on the design of C++ is probably from "How can you be so certain?": > One of my fundamental aims for C++ is (from the very start in 1979) to provide equally good support for user-defined and built-in types. For example, I’d like to be able to build an integer type that is as good as the built-in int in every way

edoo 7y ago

I use what I call "C+" which is C plus classes, basic templates, and light polymorphism when it is absolutely perfectly suited. I'd like to explore a lot of the later features but I haven't had the drive to do it. I write a ton of embedded C for money and learning C++ has lifted my C skills tremendously. It forces you into certain paradigms that you can easily do in C if you have the discipline.

MetallicCloud 7y ago
As a primarily C++ developer, I absoloutly hate maintaining code that is written like this. C has it's place in the world, but despite the fact that the language has a large amount of overlap in syntax, they are very different languages. Trying to write one in the style in the other will, at least from me, earn you some very bad thoughts.
- ncmncm 7y ago
  I agree. The more code looks like C or early '90s C++ (not to say Java), the worse it is. The newest language features exist because the language is better with them, and code is better when it used them. That is not to say that every function, or every program, has to use every obscure feature. Many features are there only to support very specialized use cases (which absolutely exist, and are important!). But things like new-style loops, generic lambdas, structured bindings, and little helper templates make writing and reading code enormously more pleasant.

Ididntdothis 7y ago

It would be kind of neat if there was a definition of different levels of the language and you could specify which level you allow in the file. This would be stronger than running a code style analysis tool. Not sure how viable this is but it would be nice to somehow phase out things like auto_ptr and others in projects.

CriticalCathed 7y ago

Why do we need to try to streamline C++ here? What's behind the urge to "cut out the fat"? Would doing this make C++ an even better performing language? What's the upside of gutting the language? I don't understand the impulse here. Yes, the semantics of C++ are more elegant than the syntax. But that doesn't mean that the syntax is actually cumbersome.

favorited 7y ago
Having so much syntax makes the language more difficult to learn, and you have to know the edge cases of each. It's universally recognized that, since C++11, you should use the `nullptr` keyword to create a null pointer. `nullptr` solves problems like not being implicitly convertible to integers, so you don't get the wrong overloads or template specializations. However, it's still perfectly valid to initialize a pointer to the NULL macro, etc. There's no benefit, but it's still all throughout codebases, so people will keep using it. Wouldn't it be nice if there was just one way to initialize a null pointer in new code?

dana321 7y ago

If they take the C out of C++ Call it ++ Basically get rid of everything that the legacy of C brings. If you want those things you probably should be coding C. Get rid of the headers .h etc. Build that from the source .pp files Make a standard package library that works properly on all platforms. Standardize the internal symbols. Make templates / everything easier to use, make standard internal map and vector types. Change auto to var. Kinda like the way go did it. Sorry, too late!

einpoklum 7y ago
> Basically get rid of everything that the legacy of C brings. This is actually happening, but not literally. That is, most of the things you used to write in a C-like fashion - you no longer write today: * References or plain values instead of pointers. * std::arrays or other containers instead of plain arrays. * std::variant's instead of unions * std::expected instead of returning error codes (although error handling is a really complex issue) and so on. > Get rid of the headers .h etc. This will start to happen in C++20, with modules. > Make a standard package library that works properly on all platforms. The standard library works well on many platforms. If you mean package management systems - that's never part of the language; but you can check out https://conan.io/ https://conan.io/ > Standardize the internal symbols. Sort-of happening with modules, if I understand what you mean. > Make templates / everything easier to use, C++ features are actually easier to use as the standardization progresses. > make standard internal map and vector types. Whaaat?! Ha ha ha, certainly not. You really don't want that. > Change auto to var. That is rather inconsequential... > Kinda like the way go did it. What you suggested is in no way specific to Go.
72deluxe 7y ago
Templates are easy to use? The messages that come about from getting them wrong aren't always the best though. I don't understand why people want to get rid of headers at all? Can anyone explain why? In C# I have no headers and I find it far more difficult to read a class or get an overview. "make standard internal map and vector types" What do you mean by this? I want to be able to use the right container for the job. I don't want a dumb array of any type like PHP arrays. That's appallingly bad because you can above garbage into them and the user of the array has no guarantees about what is in it. Might as well use void* everywhere and chuck the type system in the bin if you really want that? Or have I misunderstood? Also changing auto to var - why??

jariel 7y ago

It's not just language: it's support, tools, compiler etc. I just spent a day trying to get C++ working properly for a specific project in MSVSCode, surprisingly, it won't work, there are arcane and cryptic bits of help on StackExchange, and the sheer amount of inclusion variables, paths, special cases, compiler settings etc.. is beyond bewildering. It takes far too long for someone to develop the competency just to manage anything more than a trival build and this is a failure of the language because there's simply no reason for it - it's 'arbitrary complexity'. We're wasting serious chunks of our lives solving problems that shouldn't exist in the first place.

btilly 7y ago
As https://blog.plover.com/Unix/tools.html https://blog.plover.com/Unix/tools.html says: The bizarre mishmash of weirdness exists because so many different people invented so many tools over such a long period. And they wouldn't have done any of that inventing if the compositionality hadn't been there. I think we don't actually get to make a choice between an incoherent mess of composable paraphernalia and a coherent, well-designed but noncompositional system. Rather, we get a choice between a incoherent but useful mess and an incomplete, limited noncompositional system. I agree that C++ development can be a mess. But it is often a mess for good reasons, not bad.
- jariel 7y ago
  Yea, I agree. That's a good quote. I also would really like a 'strong agent' to just come along and do a 'new C++' without the cruft, kind of along the lines of the 'go' philosophy without necessarily inventing a new language. Maybe Rust is de-facto that. Or maybe D is it and we're not playing close enough attention. I guess your point is further validated by the hot mess of the web as well: javascript is a monster, somewhat tamed by TypeScript ... and I don't think Dart or anything else is poised to replace it.

roca 7y ago

"... and we will find that language, and we will kill it."

roca 7y ago

It's not really true that "the semantics of C++ aren't that complicated". Once you take into account undefined behavior --- which you need to, so you can avoid it --- it's so complicated that researchers haven't yet figured out what those semantics are.

userbinator 7y ago

...and that "smaller and cleaner" language is C. ;-) I'm only half-joking, of course; but while I see the beginnings of C++ were humble and practical, as a way of simplifying common idioms in C, it seems that lately the emphasis is more on turning the abstraction level to 11 with things like deeply-nested deeply-parameterised templates and writing otherwise "opaque" code that is short at a glance but entails considerable and often needless hidden complexity. I think Stroustrup himself is somewhat aware of that, given that he even references the infamous "fake interview" on that page --- and while that was a fake, the sentiments expressed in it certainly have a basis in reality.

favorited 7y ago
That's pretty much the opposite of the point he was making. His context is: > I was thinking of programming styles, libraries and programming environments that emphasized the cleaner and more effective practices over archaic uses focused on the low-level aspects of C.

lmm 7y ago

The small clean language wasn't really there. Not having sum types is why exceptions are like they are. Not having had first-class functions until recently is why control flow is like it is. Not having a proper type system is why templates are like they are. Those things between them are why concurrency is the way it is. You can't remove things from C++ to get a nice language - you need to start with a better foundation.

cryptonector 7y ago

> What is "legacy code"? > "Legacy code" is a term often used derogatorily to characterize code that is written in a language or style that (1) the speaker/writer consider outdated and/or (2) is competing with something sold/promoted by the speaker/writer. "Legacy code" often differs from its suggested alternative by actually working and scaling. Oh? To me legacy code is code that's been put into production. The moment it's in production, you have to maintain it, you have to worry about backwards compatibility and interoperability. The moment it's in production the field is no longer green. Perhaps production code is only legacy code the moment you want or have to change it, but since that almost always ends up happening, so the moment it's in production, it's legacy.

kazinator 7y ago

That smaller language is basically the C++ described in the Annotated C++ Reference Manual (a.k.a. Brown Book) by B. Stroustrup and M. Ellis, published in 1990. I landed into my first C++ job not knowing C++. Friday was my last day on the previous job. I helped myself to a stack of paper and printed out the entire ISO C++ draft standard. I also got that ARM. I read the ARM over the weekend, then went to the new C++ job Monday. I was C++ "answer guy" a month later. This one: http://www.stroustrup.com/arm.html http://www.stroustrup.com/arm.html