Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Fri, 22 Nov 2024 17:06:19 +0100
Organization: A noiseless patient Spider
Lines: 121
Message-ID: <vhqa5r$17oi0$2@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vg37nr$3bo0c$1@dont-email.me> <vg3b98$3cc8q$1@dont-email.me>
 <vg5351$3pada$1@dont-email.me> <vg62vg$3uv02$1@dont-email.me>
 <vgd3ro$2pvl4$1@paganini.bofh.team> <vgdc4q$1ikja$1@dont-email.me>
 <vgdt36$2r682$2@paganini.bofh.team> <vge8un$1o57r$3@dont-email.me>
 <vgpi5h$6s5t$1@paganini.bofh.team> <vgtsli$1690f$1@dont-email.me>
 <vhgr1v$2ovnd$1@paganini.bofh.team> <vhic66$1thk0$1@dont-email.me>
 <vhins8$1vuvp$1@dont-email.me> <vhj7nc$2svjh$1@paganini.bofh.team>
 <vhje8l$2412p$1@dont-email.me> <vhl1up$5vdg$1@dont-email.me>
 <vhlg53$8lff$1@dont-email.me> <vhnasl$l8h5$1@dont-email.me>
 <vhpogu$14mb6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 22 Nov 2024 17:06:20 +0100 (CET)
Injection-Info: dont-email.me; posting-host="05babf2ed3977eb75892bdd0e2d0437e";
	logging-data="1303104"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18lE6rDYXpVo12M/KxSAGBBG144nlgJ8Tc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:Yu1sYiPFTnLxoUADqhwebXLWVRk=
Content-Language: en-GB
In-Reply-To: <vhpogu$14mb6$1@dont-email.me>
Bytes: 7041

On 22/11/2024 12:05, Bart wrote:
> On 21/11/2024 13:00, David Brown wrote:
>> On 20/11/2024 21:17, Bart wrote:
> 
>> Your development process sounds bad in so many ways it is hard to know 
>> where to start.  I think perhaps the foundation is that you taught 
>> yourself a bit of programming in the 1970's,
> 
> I did a CS degree actually. I also spent a year programming, working for 
> the ARC and SRC (UK research councils).
> 
> But since you are being so condescending, I think /your/ problem is in 
> having to use C. I briefly mentioned that a 'better language' can help.
> 

I use better languages than C, when there are better languages than C 
for the task.  And as you regularly point out, I don't program in 
"normal" C, but in a subset of C limited by (amongst many other things) 
a choice of gcc warnings, combined with compiler extensions.

My programming and thinking is not limited to C.  But I believe I have a 
better general understanding of that language than you do (though there 
are some aspects you no doubt know better than me).  I can say that 
because I have read the standards, and make a point of keeping up with 
them.  I think about the features of C - I don't simply reject half of 
them because of some weird prejudice (and then complain that the 
language doesn't have the features you want!).  I learn what the 
language actually says and how it is defined - I don't alternate between 
pretending it is all terrible, and pretending it works the way I'd like 
it to work.

> While I don't claim that my language is particularly safe, mine is 
> somewhat safer than C in its type system, and far less error prone in 
> its syntax and its overall design (for example, a function's details are 
> always defined in exactly one place, so less maintenance and fewer 
> things to get wrong).
> 
> So, half the options in your C compilers are to help get around those 
> shortcomings.

What is your point?  Are you trying to say that your language is better 
than C because your language doesn't let you make certain mistakes that 
a few people sometimes make in C?  So what?  Your language doesn't let 
people make mistakes because no one else uses it.  If they did, I am 
confident that it would provide plenty of scope for getting things wrong.

People can write good quality C with few mistakes.  They have the tools 
available to help them.  If they don't make use of the tools, it's their 
fault - not the fault of the language.  If they write bad code - as bad 
programmers do in any language, with any tools - it's their fault.


> 
> You also seem proud that in this example:
> 
>    int F(int n) {
>        if (n==1) return 10;
>        if (n==2) return 20;
>    }
> 
> You can use 'unreachable()', a new C feature, to silence compiler 
> messages about running into the end of the function, something I 
> considered a complete hack.

I don't care what you consider a hack.  I appreciate being able to write 
code that is safe, correct, clear, maintainable and efficient.  I don't 
really understand why that bothers you.  Do you find it difficult to 
write such code in C?

> 
> My language requires a valid return value from the last statement. In 
> that it's similar to the Rust example I posted 9 hours ago.

If you are not able to use a feature such as "unreachable()" safely and 
correctly, then I suppose it makes sense not to have such a feature in 
your language.

Personally, I have use of powerful tools.  And I like that those 
powerful tools also come with checks and safety features.

Of course there is a place for different balances between power and 
safety here - there is a reason there are many programming languages, 
and why many programmers use different languages for different tasks.  I 
would not expect many C programmers to have much use for "unreachable()".

> 
> Yet the gaslighting here suggested what I chose to do was completely wrong.
> 
>> And presumably you also advise doing so on a bargain basement 
>> single-core computer from at least 15 years ago?
> 
> Another example of you acknowledging that compilation speed can be a 
> problem. So a brute force approach to speed is what counts for you.
> 

No, trying to use a long-outdated and underpowered computer and then 
complaining about the speed is a problem.

But if I felt that compiler speed was a serious hinder to my work, and 
alternatives did not do as good a job, I'd get a faster computer (within 
reason).  That's the way things work for professionals.  (If I felt that 
expensive commercial compilers did a better job than gcc for my work, 
then I'd buy them - I've tested them and concluded that gcc is the best 
tool for my needs, regardless of price.)

> If you found that it took several hours to drive 20 miles from A to B, 
> your answer would be to buy a car that goes at 300mph, rather than doing 
> endless detours along the way.

Presumably, in your analogy, the detours are useful.

> 
> Or another option is to think about each journey extremely carefully, 
> and then only do the trip once a week!
> 

That sounds a vastly better option, yes.

Certainly it is better than swapping out the car with an electric 
scooter that can't do these important "detours".