Discussion on static reflection syntax in C++

[H. S. Teoh]

On Mon, Feb 22, 2021 at 09:47:48PM +0000, Dukc via Digitalmars-d wrote:
> On Monday, 22 February 2021 at 21:16:07 UTC, H. S. Teoh wrote:
> > That would perhaps put more pressure on C++ devs to switch to a
> > saner language! ;-)
> 
> But who would maintain the C++ programs then? There may be a
> reasonable case to discourage new projects in C++, but's that's hardly
> the same as trying to kill C++ programming.

Relax, nobody is "trying to kill C++ programming". But the more the C++
committee tries to add more fat to an already overweight beast of a
language, its inevitable demise draws nearer, and bystanders like myself
enjoy speculating on the benefits that everyone would enjoy once the
beast is finally, fully, dead.


> Until we can automatically transpile everything I quess.

I don't think you need to worry; the industry has enough C++ code around
that it will last for a *long* time yet.  And if the beast ever actually
dies, I'm sure more than just a handful of clever heads would come up
with a good way of migrating everything over. (More like, everyone and
their neighbour's dog will invent a way, of which may be a handful will
survive the test of real-world code and become widely disseminated as
the solution(s) to the migration problem.)


> > Years ago, I worked in a team project where there was a C++-based
> > infrastructure so fancy and over-engineered, that after a while
> > nobody knew how to use it properly and started spending more time
> > working around it than using it.  Eventually, we ditched the C++
> > portion completely and rewrote it from scratch in C.  It was a
> > refreshing change.  C's relative dearth of features was certainly
> > limiting, but limitation is not a bad thing in a team where people
> > are constantly coming and going. No matter how horribly the code
> > devolved, there was still only a small set of features it could
> > abuse, and the scope of abuse is well-known and manageable.  It
> > wasn't *enjoyable* to go back to C per se (D takes the cake on that
> > one :-D), but it was definitely better than drowning in the ocean of
> > badly-interacting misfeatures that is C++.
> 
> Hmm, I see. The engineer in me says it's foolish to ditch all C++,
> keep the function overloading and simple templates at least (I'm
> thinking something like `T binaryFun<T>(T arg1, T arg2)`).

Some of the programmers on the team were so badly burned by the
experience that they flinch at the mere sight of templates at a distance
of 10 feet away.


> But I can kinda see that rules like that might have weaker authority
> than a simple language change.

We're talking about real world code here, written in a real company by
real people (most of whom have moved on to better things) and running in
real customer environments.  Experience has shown time and again that
such "rules" do not work. Never did work. It's programming by
convention, as Walter often refers to, and everyone knows what happens
when the release deadline is looming and everyone has more on their
plate than they could possibly hope to finish.  You just reach out and
use whatever straw you could grasp to get it working and move on.  If a
feature is in the language, people will use it. The boss isn't going to
stop a release just because somebody broke the rules and as a result got
the code working by the deadline. (As opposed to, y'know, sticking to
the rules and *not* shipping on time.)

Besides, having features in the language that nobody ever uses is really
pointless. Better throw it out and end up with a better, slimmer
language.


> I'm still suspicious about the tradeoff you made but at least I see
> potential reason to accept it.
[...]

I wasn't the one who made the decision.  If it were up to me, I'd have
stuck with C++ somehow. But I can totally sympathize with why the PTB
chose to ditch it.  It's hard not to sympathize when I've had the
dubious privilege of writing a last-minute hack function call that
involved 6 layers of abstraction, one of which involves an RPC bridge
that uses fwrite, fread, and a temporary file in order to bridge the gap
between the C++ and non-C++ parts of the code. (You *know* something has
gone horribly wrong when the act of making a function call involves disk
I/O and a temporary file (a *hard-coded* one...). And that's on top of
several other layers of marshalling/unmarshalling.  Don't ask, you do
*not* want to know.)

The day we finally could delete the entire C++ branch of the source
there was a veritable celebration. We typed every `rm -rf` command with
relish and exquisite delight. :-P


T

-- 
Why do conspiracy theories always come from the same people??