For those not wishing to read the pdf, these are Bjarne thoughts about the C++ evolution and about reaching consensus.
A couple of notable points:
“Say not ‘This is the truth’ but ‘So it seems to me to be as I now see the things I think I see.’ “ (attributed to geologist David Love,)
"We are defining a language for decades of use. A bit of humility is necessary"
"We need to focus on “what?” and “why?” more than “how?” More on stable interfaces than on optimal performance given current techniques. A standard differs from most products by requiring stability over decades. I am of the impression that we have been focusing too much on detailed controls lately, on getting programmers to be very specific on “How?”, thus making it harder to evolve use patterns and improve implementations. "
C++ suffers this a lot particularly because its paper system rewards pages of meaning-free implementation details with little to no qualitative discussion. Where else can you find a random library that lets you template a Mersenne Twister with (I kid you not) 14 template parameters, but that makes it almost impossible for the average programmer to correctly seed one? Who is served by such a system?
Things don't have to be this way. Take a look at the average Python PEP or Rust RFC; they are 90% what-we-want-and-why, and the implementation details, when they do exist, exist principally to make sure that they are asking for something possible.
C++ is one of the very few performance critical languages, performance will always be it's #1 feature,
even above safety (which can be pushed back to libraries if performance demands it) so implementation details matter a lot more than in other languages.
Everyone here would benefit from giving this a read, if you’re in management or an implementer. My favorite quotes:
> It is not just members of the community who wishes for “just two more features.” We have a committee with 300+ members. It seems that essentially every member has a feature or two that they’d like to get into the language, and many have several. I have not changed my opinion that adding too many features could “sink C++.” Remember the Vasa! [Vasa]. In fact, I think that the flood of new proposals has increased since I wrote [Vasa]. I think we are trying to do too much too fast. We can do much or do less fast. We cannot do both and maintain quality and coherence. We have to become more restrained and selective.
> Every design has advantages, disadvantages, and limitations. We should never present a design without a serious and honest discussion of possible problems and alternatives. It is part of a proposer’s job to examine problems; “pure sales jobs” are not intellectually honest. The joint “pro- and con-papers” on coroutines written by people from “opposing camps” were immensely useful ([Use][Impact]).
And later:
> Setting goals is usually far harder than the detailed design and implementation of features. We are good technicians and we have theory and existing practice to guide us with the necessary work once goals have been established. Unfortunately, we are not good at agreeing on goals and articulating them. Often, we end up in a mess of requirements. Language design is not product development. We don’t have a high management setting fundamental priorities for us. Few of us have workplace experience for that, if for no other reason that our firms are each in a specific business. I think product-development analogies have been seriously overdone over the last few years
The idea that traditional product design mentalities are insufficient for programming language design is very interesting. Indeed, a programming language’s design must answer to theoretical truths in addition to mere user feedback (this is a point brought up in the paper). It sounds obvious that in many ways C++ is not a “product” as it doesn’t have clients in the traditional sense. Where does the “language as product” analogy break down?
> Where does the “language as product” analogy break down?
I think the tricky bit here is understanding that a language is more than a language. You need people focused on the language itself, but also on related things.
You can see a generational gap here when it comes to at least one aspect here: build systems and package managers. Older languages often did not really consider this a part of their domain, and so miss out on one aspect of their product in a significant way: the major interface that their users actually use the product!
Various languages deal with this in various ways. In C++‘s case, various people who work on build systems are involved with shaping the language, but they’re basically two related projects, rather than two sub-projects of some sort of overall structure. This has led to a lack of uniformity. This can be both good and bad, but it certainly is the case.
This is what reading Rust RFCs has thought me: every potential adition can be a liability or something that makes a language inconsistent (the feature feels "bolted on" rather than natural). You can wrestle your way through to good solutions tho — if your community understands the trade offs.
So to mutate your metaphor of language-as-a-product: what if we see languages as a narrative? A story we collectively tell ourselves about it — how it should be used, which people it is for, etc.
As a practical example the idea of something being "pythonic" or "rustic" can help — because it means people form at least a foggy common idea what fits the language and what does not.
Maybe by having the multiple compiler and OS vendors as the tier one customers, with their own agendas, followed by the remaining language users on a second tier.
Additionally each customer domain tends to be focused on their own area related improvements, without an overall overview.
The gutsureness it takes to become a public figure appears to bleed into the certainty of their statements (e.g. causality, predictions). It's hilarious.
I agree. I have always been suspicious of people that project absolute certainty, especially when they do it repeatedly across multiple complex and nuanced topics. For me that behavior is a giant red flag to not trust anything that person says without further evidence.
> No language feature (or library) exists in isolation (or at least it shouldn’t). Feature interaction is among the hardest of problems, and often underestimated both as a problem and as something useful
The problem of feature interaction is not underestimated by anyone who has had to use C++ for any length of time.
[+] [-] gpderetta|6 years ago|reply
A couple of notable points:
“Say not ‘This is the truth’ but ‘So it seems to me to be as I now see the things I think I see.’ “ (attributed to geologist David Love,)
"We are defining a language for decades of use. A bit of humility is necessary"
"We need to focus on “what?” and “why?” more than “how?” More on stable interfaces than on optimal performance given current techniques. A standard differs from most products by requiring stability over decades. I am of the impression that we have been focusing too much on detailed controls lately, on getting programmers to be very specific on “How?”, thus making it harder to evolve use patterns and improve implementations. "
[+] [-] amelius|6 years ago|reply
When someone tells me "this is the truth", my brain already converts it to the longer, less certain phrase; no need to be explicit about it ...
[+] [-] Veedrac|6 years ago|reply
Things don't have to be this way. Take a look at the average Python PEP or Rust RFC; they are 90% what-we-want-and-why, and the implementation details, when they do exist, exist principally to make sure that they are asking for something possible.
[+] [-] lonelappde|6 years ago|reply
[+] [-] flafla2|6 years ago|reply
> It is not just members of the community who wishes for “just two more features.” We have a committee with 300+ members. It seems that essentially every member has a feature or two that they’d like to get into the language, and many have several. I have not changed my opinion that adding too many features could “sink C++.” Remember the Vasa! [Vasa]. In fact, I think that the flood of new proposals has increased since I wrote [Vasa]. I think we are trying to do too much too fast. We can do much or do less fast. We cannot do both and maintain quality and coherence. We have to become more restrained and selective.
> Every design has advantages, disadvantages, and limitations. We should never present a design without a serious and honest discussion of possible problems and alternatives. It is part of a proposer’s job to examine problems; “pure sales jobs” are not intellectually honest. The joint “pro- and con-papers” on coroutines written by people from “opposing camps” were immensely useful ([Use][Impact]).
And later:
> Setting goals is usually far harder than the detailed design and implementation of features. We are good technicians and we have theory and existing practice to guide us with the necessary work once goals have been established. Unfortunately, we are not good at agreeing on goals and articulating them. Often, we end up in a mess of requirements. Language design is not product development. We don’t have a high management setting fundamental priorities for us. Few of us have workplace experience for that, if for no other reason that our firms are each in a specific business. I think product-development analogies have been seriously overdone over the last few years
The idea that traditional product design mentalities are insufficient for programming language design is very interesting. Indeed, a programming language’s design must answer to theoretical truths in addition to mere user feedback (this is a point brought up in the paper). It sounds obvious that in many ways C++ is not a “product” as it doesn’t have clients in the traditional sense. Where does the “language as product” analogy break down?
[+] [-] steveklabnik|6 years ago|reply
I think the tricky bit here is understanding that a language is more than a language. You need people focused on the language itself, but also on related things.
You can see a generational gap here when it comes to at least one aspect here: build systems and package managers. Older languages often did not really consider this a part of their domain, and so miss out on one aspect of their product in a significant way: the major interface that their users actually use the product!
Various languages deal with this in various ways. In C++‘s case, various people who work on build systems are involved with shaping the language, but they’re basically two related projects, rather than two sub-projects of some sort of overall structure. This has led to a lack of uniformity. This can be both good and bad, but it certainly is the case.
[+] [-] atoav|6 years ago|reply
So to mutate your metaphor of language-as-a-product: what if we see languages as a narrative? A story we collectively tell ourselves about it — how it should be used, which people it is for, etc.
As a practical example the idea of something being "pythonic" or "rustic" can help — because it means people form at least a foggy common idea what fits the language and what does not.
[+] [-] pjmlp|6 years ago|reply
Additionally each customer domain tends to be focused on their own area related improvements, without an overall overview.
[+] [-] elevenoh|6 years ago|reply
Could say we're in a certainty epidemic
[+] [-] glitcher|6 years ago|reply
[+] [-] Gravityloss|6 years ago|reply
[+] [-] emmelaich|6 years ago|reply
His books on C++ are as much about programming in general as C++.
[+] [-] gpderetta|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] mnemonicsloth|6 years ago|reply
The problem of feature interaction is not underestimated by anyone who has had to use C++ for any length of time.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] psv1|6 years ago|reply
[+] [-] dgellow|6 years ago|reply
[+] [-] ferdek|6 years ago|reply