3 ms·

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

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?

pjmlp 7y ago
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.
atoav 7y ago
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 7y ago
  > 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.
steveklabnik 7y ago
> 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.

pjmlp 7y ago

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.

atoav 7y ago

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

steveklabnik 7y ago

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