Hacker News new | past | comments | ask | show | jobs | submit login
How can you be so certain? (2019) [pdf] (open-std.org)
190 points by gpderetta 26 days ago | hide | past | web | favorite | 23 comments

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

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

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.

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

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.

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.

This absolutely doesn't explain C++'s weirdness. Those template parameters don't make anything faster, its broken seeding ends up pretty slow, and a Mersenne Twister is hardly performance- (or anything-)optimal. Heck, some of those template parameters are probably used by a sum total of zero people in production code.

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.

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

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.

Could say we're in a certainty epidemic

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.

Always love to read some Bjarne.

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

yes, he does come out as a proper engineer.

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

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

should (2019) be added to the title?

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

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.

Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact