There are two stories about Microsoft that stick in my mind, after working
there for 6 years.

One is that they relied heavily on market and customer research, far
more than other companies. While my company was writing software for users
like ourselves, Microsoft actively talked to customers and got
their feedback and direction. And they did much better than we did. With
one caveat: when a Microsoft engineer suggested doing 3-D charts for Excel,
customer research rejected the idea because few customers wanted it. Then
Lotus 1-2-3 implemented it, and suddenly 3-D charts become the
top-requested feature. The lesson: if you base your direction on customer
requests, you'll tend to be a follower rather than a leader. Steve Jobs
had an interesting way to put it: "How will customers know what they want,
if I don't tell them?"

The other story, which is more relevant to your message, also concerns the
top-10-most-requested features, circa 1998 or so, just a few product
revisions later. To put it simply: about half of the features that
customers wanted in Microsoft Office... were already in Microsoft Office.

I typically feel that way about C++: while some of the things that the
standards committee wants to add are often truly new, the things that users
want, are typically already there; it's just that they don't know how to
use them. lambdas, for example, are just structs with operator() methods -
something that I often explain to new users. range-based for loops are
purely syntactic sugar for something the language could already do, albeit
in a more simple, elegant way. Even coroutines - yes coroutines - I can
write most coroutine examples in C++11! [Side note: to the folks who
presented the night session at the standards meeting about coroutines,
thankyou so much, I never really understand coroutines until your
presentation; it was awesome.]

And to really drive the point home: I have an ongoing problem with a team
at my dayjob that implemented something using templates and private virtual
inheritance, that could have been done just as well with function
pointers. No, I take that back: it would have been much more efficient
with function pointers. Much, much more efficient. And I wouldn't have
had to deal with functions whose names are 8,000 characters long after
mangling - and multiple times longer after demangling - yet consist of only
2 or 3 instructions. There's a surprising tendency to use advanced
features of the language just because they're there... so I wish they
weren't.

When I daydream about C++, I don't dream of a new C++ with all these cool
new features. I dream of a C++ where the old unneeded cruft is gone. A
C++ without preprocessor macros. A C++ without int_type(expression), or
(int_type) expression, because if you want that, use reinterpret_cast or
static_cast, as appropriate. A C++ without the ability to declare a
function inside the scope of another function (to eliminate the most vexing
parse). A C++ without C's ", ..." vararg style for variadic function
parameters. A C++ without ADL (unless you explicitly opt into it).

Of course, while I would love such a C++, I'm not sure who would use it,
other than me. I do know that students of the language are often brought
up learning C and then transitioning from there to C++, bringing all those
bad habits with them. Perhaps they'd be interested in a leaner language
without all the things we don't use much anymore? Surely they would be
better served by a language that teaches modern idioms rather than the
deprecated ones?

But enough dreaming... time to go get some sleep. :-)

On Wed, Sep 25, 2019 at 7:02 PM Jefferson Carpenter via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> As tempting as it is to add new and powerful features to the language,
> for various reasons from simplifying existing code to 'keeping up' with
> other languages out in the field, it's a dangerous and bloody art to do so.
>
> The C++ spec may define the syntax and evaluation semantics of the
> language, but what breathes life into it is the compiler. The more
> complicated the spec is, the more complicated the compiler must become.
> We're fortunate to have a diverse set of c++ compilers from the
> proprietary to the open source, but the more features get added, the
> higher the initial cost to creating a new viable c++ compiler project.
>
> Slow and steady wins the race. There does not exist a language feature
> (except maybe value semantics) that will not, at some point in the near
> or far future, become invalidated by cleaner ways of doing the same
> thing. Adding too many features kills languages. Optimally, the rate
> at which features are added should be equal to the rate at which they
> are deprecated and removed, over long time spans. This ensures that
> compiler writers will not have to do too much up-front work to learn to
> maintain a compiler or to write a new one.
>
> To pick on coroutines (although they certainly can be useful), co_await,
> co_yield, and co_return can be implemented as library functions
> abstracting and making platform-independent the existing functions
> setjmp and longjmp, with only the overhead of keeping a reference to
> some state holding the continuation in the calling code and the
> continuation in the coroutine. Additionally, while coroutines make
> serial asynchronous operations easier to write, they cannot do the same
> for parallel asynchronous operations without potentially pessimizing
> performance. In "x = co_await y; x2 = co_await y2;" x2 cannot be
> assigned before x has been assigned - even if y2 completes before y -
> unless the compiler can come up with a proof that such re-ordering does
> not change the visible behavior of the program. Instruction reordering
> and the as-if rule already indicate that the semantics of C++ place too
> much emphasis on the sequencing of operations over the dependency graph
> of data.
>
> As excited as I am for new C++20 features including concepts and
> coroutines, I'm more excited for the deprecation of most of volatile. I
> want the language to be well understood as-is so that it can be reasoned
> about, the real pain points identified, and the spec slowly changed to
> meet new needs with the patience of a community that deserves to
> continue to beat until the last program is written and the last rock is
> dust.
>
> Peace,
> Jefferson
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>