Sujet : Re: Loops (was Re: do { quit; } else { })
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 15. Apr 2025, 21:37:43
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250415131726.691@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-04-15, Janis Papanagnou <janis_papanagnou+
ng@hotmail.com> wrote:
On 15.04.2025 16:30, bart wrote:
On 15/04/2025 14:33, Kaz Kylheku wrote:
On 2025-04-15, bart <bc@freeuk.com> wrote:
* Not having to write the variable 3 times (with C not always being
able to detect if they didn't match)
>
This is indeed a source of errors in C nested loops.
According to Janis Papanagnou, it is 100% the programmer's fault. There
is nothing wrong with the language!
>
No, there is nothing wrong with the language if you make such errors.
>
The programmer selects (or constructs) the algorithm, the language has
clear semantics for such simple loop constructs without any irregular
or hidden semantics, and the programmer's task is to know the elements
of the language and transfer the algorithm to a correct coding. - It's
self-delusion if you try to blame the language for the mistakes you do.
While it would be close to professional misconduct for an engineer
to deflect responsibility for a problem by blaming tools and materials
(which he or she chose!) it is also the engineer's responsibility to
identify how the nature of the tools contributes to problems.
Programming tools contribute to risk. The more details you have to
specify to solve a problem, that are not checked by machine, the greater
the probability of making a mistake. The severity of a mistake
also depends on tools.
Open-coding something detailed tends to be more risky than using a
verified, encapsulated abstraction which does the same thing, but
figures out some of the details.
The main things developers do wrong is choosing the wrong tool for
the job. In such cases, it can be a fool's errand to try to
catalog how the tool contributed to a problem. You wouldn't have
a "post mortem" meeting about why the hammer failed to drive a screw,
and how it could be improved.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca
do { quit; } else { }
Re: do { quit; } else { }