
"Within C++, there is a much smaller and cleaner language struggling to get out" - mpiedrav
http://www.stroustrup.com/bs_faq.html#really-say-that
======
DoofusOfDeath
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_1...](https://www.brainyquote.com/quotes/antoine_de_saintexupery_103610)

~~~
wvenable
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
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.

------
mpiedrav
«"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.»

------
lmm
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.

------
jariel
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
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
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.

------
einpoklum
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
> _spirit_

I think it would be a good name for the new language (if it ever shows; it
will probably be a lisp).

~~~
paulddraper
That's like saying Rust will turn into Lisp.

There is _way_ too much around memory management to be Lisp.

------
slavik81
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

------
Ididntdothis
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.

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

------
roca
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
...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
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.

------
CriticalCathed
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
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?

------
cryptonector
> 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
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)

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

------
dana321
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
> 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.

------
edoo
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
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
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.

