A cautionary tale we should all keep in mind.

http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf

https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/

https://news.ycombinator.com/item?id=17172057

On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
> A cautionary tale we should all keep in mind.
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
>
> https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
>
> https://news.ycombinator.com/item?id=17172057

No doubt that all this complexity is partially due to having a religious like zeal when it comes to preserving backwards compatibility.

I mean create a new official file extension, so that it can make much needed breaking changes on it.

For all the faults that D has, it is not afraid deprecate language features if it turns out to be a really bad idea.

On 5/28/2018 6:54 PM, 12345swordy wrote:
> No doubt that all this complexity is partially due to having a religious like zeal when it comes to preserving backwards compatibility.
> 
> I mean create a new official file extension, so that it can make much needed breaking changes on it.
> 
> For all the faults that D has, it is not afraid deprecate language features if it turns out to be a really bad idea.

If I was going to make a proposal to the C++ Standards committee, it would be to deprecate the preprocessor. D has by now shown that all of it that matters can be done with language features in a straightforward, hygienic manner.

Here's the D subthread:

https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/dzpwz76/

On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
> A cautionary tale we should all keep in mind.
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
>
> https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
>
> https://news.ycombinator.com/item?id=17172057

Bjarne  opens with: "Many/most people in WG21 are working independently towards non-shared goals."

I presume, this is essentially a criticism??

If so, I reject that as criticism. There has to be room for allowing people to puruse their individual goals too, and a programming langauge should allow that as well.

The idea that less is more? Well, take a look at golang. Less means less, not more.

When I go out to do a job, a take only those tools I'll need for the job. I'm not expected to take every tool ever created, and know how to use each of those tools. I take, and use, the tools I need for that particular job.

A programming langauge should not restrict the availability of tools, unless is want to be the tool for a particular job.

New features, that people want, are essentially 'tools' that they want. (and typically, tools they already have in one or more other langauges).

Lets not contain complexity, by preventing it from every occurring - otherwise, nothing would exist.

On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
> A cautionary tale we should all keep in mind.
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
>
> https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
>
> https://news.ycombinator.com/item?id=17172057

It seems C++ is following the road of PL/I, which is growing language way beyond the point anyone can understand or implement all of it.

On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
> On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
>> A cautionary tale we should all keep in mind.
>>
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
>>
>> https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
>>
>> https://news.ycombinator.com/item?id=17172057
>
> It seems C++ is following the road of PL/I, which is growing language way beyond the point anyone can understand or implement all of it.

This is ultimately a matter of 'architecture', rather than being a problem of a 'growing langauge'.

A good architecture could allow growth/complexity to arise in a manageable way.

When you have languages that are so low level, you simply cannot create good architecture, beyone a certain point (either from the users point of view, or the implementers).

What we need, is better architecture in langauge design.

This, ultimately, means we need to move away from the von Neumann machine, because that is really what's holding us back, from developing good architecture (for managing the inevitable complexity that arises from change).

Nature shows us the way - we just don't bother to look.

On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
>
> It seems C++ is following the road of PL/I, which is growing language way beyond the point anyone can understand or implement all of it.

but that happened to the linux kernel too, long ago?

and yet...it's everywhere..and increasingly so...

we need to move away from this concept that we need to understand it all, or otherwise.. it must be bad.

On Tuesday, May 29, 2018 03:43:00 TheMightWarship via Digitalmars-d wrote:
> On Tuesday, 29 May 2018 at 01:46:47 UTC, Walter Bright wrote:
> > A cautionary tale we should all keep in mind.
> >
> > http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
> >
> > https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_ remeber_the_vasa_critique_of/
> >
> > https://news.ycombinator.com/item?id=17172057
>
> Bjarne  opens with: "Many/most people in WG21 are working independently towards non-shared goals."
>
> I presume, this is essentially a criticism??
>
> If so, I reject that as criticism. There has to be room for allowing people to puruse their individual goals too, and a programming langauge should allow that as well.

I don't think that it's really a criticism of folks having individual goals. The overall criticism seems to be that while those involved may have varying goals, the resulting language needs to be reasonably coherent and usable by the lay programmer. So, ultimately, when new language features are introduced, you need to examine how they fit in with everything else (both what's already in the language and what's being proposed) and potentially adjust what's being proposed to make it all fit together better. Right now, they're getting a bunch of indpendent proposals that don't take each other into account at all, and it sounds like a lot of them aren't even talking about how this will help or hurt the average C++ programmer. It's more like they're just trying to get their pet feature into the language. So, Stroustrup thinks that they should be trying to make everything fit together better and aim it at how it affects the average C++ programmer who's just trying to get their job done rather than trying to get every stray thing into the language that seems like it would be valuable. He even talks about how the Vasa could have succeeded if a bit more work had been put into making sure how all of the adjustments to the vessel worked together. It didn't need to give up on everything that was done to improve it. Rather, it needed to be more coherent in its parts. C++ is suffering from a major case of being designed by committee.

- Jonathan M Davis

On Tuesday, 29 May 2018 at 04:41:33 UTC, Komplex wrote:
> On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
>>
>> It seems C++ is following the road of PL/I, which is growing language way beyond the point anyone can understand or implement all of it.
>
> but that happened to the linux kernel too, long ago?

Not really.
First - Linux (for the scale) is architectured wuite well.
Second - language are way more composable and complex beasts then systems. I bet I can understand most of Linux kernel in a couple of years (w/o drivers and arch specifics beyond x86). Abstraction and components/interfaces is time-proven technique that actually works for the most part.

 In contradt I will likely never understand or have a good picture of C++20 as a (semi-)coherent whole, not that I really wanted to.

D is probably at the edge of what I can tollerate complexity-wise. And we’ll get to simplify a few things soon I believe.
>
> and yet...it's everywhere..and increasingly so...
>

It has evolved a lot. Yet I believe we can get better things done w/o years upon years of churn. But that’s just a point of view.

> we need to move away from this concept that we need to understand it all, or otherwise.. it must be bad.

On Tuesday, 29 May 2018 at 03:56:05 UTC, Dmitry Olshansky wrote:
> It seems C++ is following the road of PL/I, which is growing language way beyond the point anyone can understand or implement all of it.

A key line from this paper

>  We now have about 150 cooks; that’s not a good way to get a tasty and balanced meal.

I don't think Bjarne is against adding feature to C++, or even constantly adding feature
he even admits to support some of the features he mention in his list

I think he is worried about
1. the huge number of features being targeted at once
2. the features coming from different independent teams, making them less likely to be coherent

This is very different from "lets not grow C++ ever"

D need to add features constantly, but coherently, D is very far from having 150 cooks
I wish D had that many cooks :)