Re: What is this "Beman Project Development"?

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-05-10 04:47:52

On Thu, May 9, 2024 at 7:13 PM Arno Schoedl <schoedl_at_[hidden]> wrote:

> I am watching this discussion from the sidelines, and I am little involved
> in the standardization. But I think judging from the outside, Vinnie has a
> point.

Thank you.

Some recent additions to the standard made questionable design choices,
> which if a library had been implemented and widely used prior to
> standardization like in Boost, design choices may have been made
> differently.
>
> Some examples:
>

I'm trying to be very careful here and not just drag up obvious examples
like the loss of Networking TS. Doing so is easy but hasn't produced
results for me in the past. Instead I prefer to look at behavioral
incentives and feedback mechanisms. In my previous posts on this subject I
alluded to perfect competition as the behavior and feedback system which
rewards good libraries and punishes bad ones.

What WG21 system incentives technical excellence? How is the technical
excellence measured? What WG21 process ensures that the good solutions are
brought forward? If a mistake is made what is the process for discovering
the mistake and fixing the system? In business this is called a "postmortem
analysis" [1] and it is crucial for helping projects get back on track if
they veer off course. The committee process does not incentivize anyone to
do such things. No one can get "fired" from the committee unless they
basically commit a crime like assault.

Imagine a business that cannot fire employees, or even deploy metrics for
calculating if their workers are effective! WG21 is the equivalent of a
totally dysfunctional business. It can't respond to market pressure, it
can't go bankrupt, it doesn't know when it makes mistakes and even if it
did it can't correct them (muh ABI). There are no requirements placed on
attendees. No one has to submit a resume they are just "hired" on the spot,
determine their own role in the "company", and their performance is never
measured or held to account. This of course often attracts a certain kind
of person, who craves acceptance, enjoys the illusion of productivity
afforded by make-work, and cannot withstand the pressure of being held to a
particular standard.

This is why I no longer bother to argue about any undesirable outcomes of
the WG21 process in particular. It is because the system itself is set up
with the wrong incentives. There is nothing to reward technical excellence
and discourage poor engineering. Important features like networking are
viewed as a land-grab riddled with political intrigue and jockeying for
position.

For all its drawbacks, stackful coroutines are an incredibly important tool
in the programming toolbox. They don't require changes to the language, the
rules surrounding lifetime are dead simple to understand, and for a broad
range of use-cases they are perfectly adequate. The underlying technology,
which is the ability to save and restore the context, is perfectly
understood and there is overwhelming field experience. In other words,
stackful coroutines are a solved problem. There is little to no controversy
surrounding them.

The paper to add coroutines to C++ has been around for eleven years:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3708.pdf

This is just one instance which illustrates why WG21 is not set up for
consistent success. Many such examples exist.

[1]
https://www.linkedin.com/pulse/importance-post-mortem-analysis-chad-m-peterman-c1xkf/