Date: Mon, 4 Dec 2023 11:25:30 +0100
On 02/12/2023 00:58, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Fri, Dec 1, 2023 at 10:43 AM David Brown wrote:
>>
>> How can I put this diplomatically? Your attitude here is just /wrong/.
>> Completely and utterly /wrong/. Nothing you have said would be
>> acceptable as "best practice" in embedded development.
>
>
> I'm listening . . .
>
>
>> To be fair, not all embedded development is done as "best practice".
>> And sometimes even when developers know better, there are other
>> pressures - time, money and management - forcing shortcuts and hacks to
>> be taken.
>
>
> Unfortunately I've had to take more shortcuts since my workload
> increased greatly on account of a sudden unexpected departure from the
> company (and he was in the job for 25+ years).
I can appreciate that sometimes the job is difficult, and sometimes you
feel you need to take shortcuts and compromise on quality. That's not
unusual. We've all released code knowing there is a bug that we haven't
fixed, or knowing that something appears to work but we're not sure why.
But it is completely wrong to try to /normalise/ this. It must be clear
to everyone that this is exceptional, and a very bad situation. Every
time you throw something together that seems to work well enough to make
the sale, you are sending a message to your company management that they
don't need more developers, or more time for testing. You are
prolonging the problem, exasperating it, and increasing the chances of
bigger disasters further down the line. Every time you publicly say
"that's just how we work in this business", you are pushing down the
average quality everywhere. Every time you say "all software has bugs",
you are lowering customer expectations and trust in products, and
demeaning the industry. Every time you push for more utter crap in the
C++ standards, just to make it even easier for you to write stuff
everyone knows is bad code, you are dragging down the reputation of the
software development industry, and trying to drag down the practice of
it. The software industry has enough bad practices and bad
practitioners without people making excuses for them and trying to make
it easier to write worse code.
If you want to release hacks, workarounds and half-tested code as an
attempt to save the company you work for, that's up to your conscience.
It might be the right choice, and a gamble worth taking in the short
term. I can understand that decision. If I knew the details of the
circumstances, I might agree with it. But I will /not/ accept that it
is a /good/ choice. I will not accept that it is a /normal/ choice, or
that it is or should be common practice.
>
>
>> But no, you never "discard" or "drop" a bus. If you have something you
>> want to shut down, and the "normal" shutdown procedure can't work, you
>> support an "abnormal" shutdown procedure.
>
>
> Yeah if ya wanna go opening up the proprietary header files for the
> Bus class and also run the object files through a decompiler.
You are talking nonsense in an attempt to make excuses for writing bad
code. /You/ are responsible. /Your/ job, in this case, is to ensure
there is a controlled shutdown. I don't care if you have to write a
wrapper class with multiple shutdown methods, or re-write the bus class,
or file bug reports with the developers of the "proprietary headers",
whatever those might be. It is /your/ responsibility. You don't just
shovel it under the carpet and hope no one notices. And you certainly
don't campaign to add carpet shovellers to the language standards to
make the process easier!
>
> If I were to adopt your way of thinking, I would think that a watchdog
> timer is a pathetic and bad practise to cover up dodgy coding.
>
The majority of uses of watchdog timers /are/ pathetic attempts to cover
up dodgy coding.
They have real uses, mostly to handle rare hardware problems. (Even the
best designed hardware can be thrown askew by an unlucky cosmic ray.)
And sometimes there are well-reasoned and well-justified grounds for
releasing software that you know or suspect is not bug-free, and a
watchdog timer may reduce the consequences of the bugs.
But it is an unfortunate reality that a lot of developers thing they are
magic protection against software bugs. I read a description of this as
being akin to hitting a dead man repeatedly on the head with a hammer,
in the home that he wakes up.
If you ever feel the urge to have a watchdog enabled in released code as
"protection" against software problems, your code is borked and your
development process flawed. Maybe that is still the least bad option in
extreme and unusual circumstances, but be damn sure it is not standard
practice.
>
>> And, in general, stop making claims about
>> "embedded developers" or "in the real world". You don't speak for
>> embedded developers, and you don't speak for "the real world".
>
>
> I breed axolotls so I can speak for axolotl breeders
No, you can't. You can speak as /an/ axolotl breeder.
If you are voted in as chairman of your regional axolotl breeders'
association, you can speak for axolotl breeders. If you have bred
axolotls for many years, have studied their biology, bred different
species, talked often with other breeders, then you might justifiably
say you speak more broadly than just yourself.
Otherwise, you are a sample of one, and no more than that.
> -- but that isn't
> to say that I'm the sole worldwide authority on breeding axolotls, but
> I can at least share my views from my experience breeding axolotls.
>
>
>> As an embedded developer who wants good, clean, working code, your attitude
>> represents the worst we see.
>
>
> So _you're_ allowed to use the pronoun, 'we', but I'm not.
>
In this case, yes, I am entirely confident that many share my opinion
here. It is possible to know something about a wider community despite
not being able to speak for them.
>
>> I don't want the C++ standards to change here - I want your attitude to change!
>
>
> Irony. I was reading through your post and then thought, "hang on a
> second, who is this?", and then I scrolled up and saw 'David Brown'
> and thought "oh of course". Comp.lang.c++ wouldn't be half as colorful
> without you.
I am glad you think I am a colourful member of that group.
Now, this is all way off-topic for this group. I hope we can return to
a more technical discussion. But I hope it is in terms of features that
can make it easier for people to write good C++ code and harder for them
to write bad C++ code, rather than to make it easier for them to write
bad code.
> On Fri, Dec 1, 2023 at 10:43 AM David Brown wrote:
>>
>> How can I put this diplomatically? Your attitude here is just /wrong/.
>> Completely and utterly /wrong/. Nothing you have said would be
>> acceptable as "best practice" in embedded development.
>
>
> I'm listening . . .
>
>
>> To be fair, not all embedded development is done as "best practice".
>> And sometimes even when developers know better, there are other
>> pressures - time, money and management - forcing shortcuts and hacks to
>> be taken.
>
>
> Unfortunately I've had to take more shortcuts since my workload
> increased greatly on account of a sudden unexpected departure from the
> company (and he was in the job for 25+ years).
I can appreciate that sometimes the job is difficult, and sometimes you
feel you need to take shortcuts and compromise on quality. That's not
unusual. We've all released code knowing there is a bug that we haven't
fixed, or knowing that something appears to work but we're not sure why.
But it is completely wrong to try to /normalise/ this. It must be clear
to everyone that this is exceptional, and a very bad situation. Every
time you throw something together that seems to work well enough to make
the sale, you are sending a message to your company management that they
don't need more developers, or more time for testing. You are
prolonging the problem, exasperating it, and increasing the chances of
bigger disasters further down the line. Every time you publicly say
"that's just how we work in this business", you are pushing down the
average quality everywhere. Every time you say "all software has bugs",
you are lowering customer expectations and trust in products, and
demeaning the industry. Every time you push for more utter crap in the
C++ standards, just to make it even easier for you to write stuff
everyone knows is bad code, you are dragging down the reputation of the
software development industry, and trying to drag down the practice of
it. The software industry has enough bad practices and bad
practitioners without people making excuses for them and trying to make
it easier to write worse code.
If you want to release hacks, workarounds and half-tested code as an
attempt to save the company you work for, that's up to your conscience.
It might be the right choice, and a gamble worth taking in the short
term. I can understand that decision. If I knew the details of the
circumstances, I might agree with it. But I will /not/ accept that it
is a /good/ choice. I will not accept that it is a /normal/ choice, or
that it is or should be common practice.
>
>
>> But no, you never "discard" or "drop" a bus. If you have something you
>> want to shut down, and the "normal" shutdown procedure can't work, you
>> support an "abnormal" shutdown procedure.
>
>
> Yeah if ya wanna go opening up the proprietary header files for the
> Bus class and also run the object files through a decompiler.
You are talking nonsense in an attempt to make excuses for writing bad
code. /You/ are responsible. /Your/ job, in this case, is to ensure
there is a controlled shutdown. I don't care if you have to write a
wrapper class with multiple shutdown methods, or re-write the bus class,
or file bug reports with the developers of the "proprietary headers",
whatever those might be. It is /your/ responsibility. You don't just
shovel it under the carpet and hope no one notices. And you certainly
don't campaign to add carpet shovellers to the language standards to
make the process easier!
>
> If I were to adopt your way of thinking, I would think that a watchdog
> timer is a pathetic and bad practise to cover up dodgy coding.
>
The majority of uses of watchdog timers /are/ pathetic attempts to cover
up dodgy coding.
They have real uses, mostly to handle rare hardware problems. (Even the
best designed hardware can be thrown askew by an unlucky cosmic ray.)
And sometimes there are well-reasoned and well-justified grounds for
releasing software that you know or suspect is not bug-free, and a
watchdog timer may reduce the consequences of the bugs.
But it is an unfortunate reality that a lot of developers thing they are
magic protection against software bugs. I read a description of this as
being akin to hitting a dead man repeatedly on the head with a hammer,
in the home that he wakes up.
If you ever feel the urge to have a watchdog enabled in released code as
"protection" against software problems, your code is borked and your
development process flawed. Maybe that is still the least bad option in
extreme and unusual circumstances, but be damn sure it is not standard
practice.
>
>> And, in general, stop making claims about
>> "embedded developers" or "in the real world". You don't speak for
>> embedded developers, and you don't speak for "the real world".
>
>
> I breed axolotls so I can speak for axolotl breeders
No, you can't. You can speak as /an/ axolotl breeder.
If you are voted in as chairman of your regional axolotl breeders'
association, you can speak for axolotl breeders. If you have bred
axolotls for many years, have studied their biology, bred different
species, talked often with other breeders, then you might justifiably
say you speak more broadly than just yourself.
Otherwise, you are a sample of one, and no more than that.
> -- but that isn't
> to say that I'm the sole worldwide authority on breeding axolotls, but
> I can at least share my views from my experience breeding axolotls.
>
>
>> As an embedded developer who wants good, clean, working code, your attitude
>> represents the worst we see.
>
>
> So _you're_ allowed to use the pronoun, 'we', but I'm not.
>
In this case, yes, I am entirely confident that many share my opinion
here. It is possible to know something about a wider community despite
not being able to speak for them.
>
>> I don't want the C++ standards to change here - I want your attitude to change!
>
>
> Irony. I was reading through your post and then thought, "hang on a
> second, who is this?", and then I scrolled up and saw 'David Brown'
> and thought "oh of course". Comp.lang.c++ wouldn't be half as colorful
> without you.
I am glad you think I am a colourful member of that group.
Now, this is all way off-topic for this group. I hope we can return to
a more technical discussion. But I hope it is in terms of features that
can make it easier for people to write good C++ code and harder for them
to write bad C++ code, rather than to make it easier for them to write
bad code.
Received on 2023-12-04 10:25:42