How can you be so certain? (2019) [pdf]
open-std.org
open-std.org
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. "
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 ...
1. They say it's the truth; I interpret that they think it's true, but it might not be.
2. They say it's the truth; this may be a signal of their character or motivations. Perhaps they are a bully or a zealot.
Even if I trust that you'll understand me in the (1) sense, I'd rather you didn't misjudge me in the (2) sense. Therefore, I don't tell people that things are simply true.
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.
> 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?
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.
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.
My personal opinion on this is that this is generally harmful, as there will always be that one corner case which doesn't respect the "idiomatic" rules - and then you have to fight every time to explain the good reason which led these rules to not be respected in that place.
I much prefer to say - any string valid in the language grammar is fair game ; if we don't want a string / construct / etc, then build a language in which the construct doesn't compile (or create a linter which fails the build, etc). Especially, you can't assume how other people learned the language - maybe someone went on C++ from LISP and builds his code around lambdas and std::function, or from Java and creates IAbstractObservableFactoryDispatchers by the dozen, or is a grammarian mostly experienced in Boost.Spirit or any other combination - that's ok, you're a dev, reading their code will enlighten you even if you need to google a bit, and open you to some paradigms which may later turn out to be the best fit for some use case of your code.
Additionally each customer domain tends to be focused on their own area related improvements, without an overall overview.
Could say we're in a certainty epidemic
His books on C++ are as much about programming in general as C++.
The problem of feature interaction is not underestimated by anyone who has had to use C++ for any length of time.