
How can you be so certain? (2019) [pdf] - gpderetta
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1962r0.pdf
======
gpderetta
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. "

~~~
amelius
> “Say not ‘This is the truth’ but ‘So it seems to me to be as I now see the
> things I think I see.’ “

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

~~~
gmfawcett
But it's a translation in two parts, at least it would be for me:

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.

~~~
amelius
As long as you apologize whenever what you said turns out to be false, I don't
see the problem.

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

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

~~~
klodolph
This is not the full explanation. The key problem here is that C++ runs on
nearly everything, from your garden variety x86 to bizarre DSP architectures.
The many, many template parameters are there so you can simultaneously say
“you don’t pay for what you don’t use” and provide a library that works on
weird systems.

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

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

~~~
jcelerier
> A story we collectively tell ourselves about it — how it should be used,
> which people it is for, etc.

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.

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

Could say we're in a certainty epidemic

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

------
emmelaich
Always love to read some Bjarne.

His books on C++ are as much about programming in general as C++.

~~~
gpderetta
yes, he does come out as a proper engineer.

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

------
psv1
I'm not a C++ developer but I really enjoyed reading this.

------
dgellow
should (2019) be added to the title?

~~~
ferdek
Is this a hard rule? I didn't see all submissions on 1st of January to have
(2019) tags, and this paper is not that old (Nov 2019).

~~~
gpderetta
FWIW, I did submit this in 2019, but it did get no traction; it got
resubmitted by the mods as they thought it was interesting.

