Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Kaz Kylheku <643-408-1753@kylheku.com> Newsgroups: comp.lang.c Subject: Re: Loops (was Re: do { quit; } else { }) Date: Tue, 15 Apr 2025 20:37:43 -0000 (UTC) Organization: A noiseless patient Spider Lines: 44 Message-ID: <20250415131726.691@kylheku.com> References: <87a58mqt2o.fsf@nosuchdomain.example.com> <20250413072027.219@kylheku.com> <20250415152550.00007634@yahoo.com> <20250415062839.904@kylheku.com> Injection-Date: Tue, 15 Apr 2025 22:37:43 +0200 (CEST) Injection-Info: dont-email.me; posting-host="16520bcd085ba48f48bf86c676aa114c"; logging-data="513524"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19YsL6WMyRYHK2H/CyjjjPqgOlue4Gq508=" User-Agent: slrn/pre1.0.4-9 (Linux) Cancel-Lock: sha1:XtmGmCxt465wD9vXO0UhaZkzDvQ= Bytes: 3644 On 2025-04-15, Janis Papanagnou wrote: > On 15.04.2025 16:30, bart wrote: >> On 15/04/2025 14:33, Kaz Kylheku wrote: >>> On 2025-04-15, bart 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/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca