Deutsch English Français Italiano |
<vhqa5r$17oi0$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
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".