- ???Microsoft Azure CTO Mark Russinovich: C/C++ should be deprecated??? - 6 Updates
- "Richard Stallman Announces C Reference" - 2 Updates
- Never use strncpy! - 1 Update
| gazelle@shell.xmission.com (Kenny McCormack): Sep 22 04:15PM In article <871qs3za1l.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: ... >> readability? You are saving typing a whopping 4 characters! >And C has int, struct, enum, char, const, extern... I think there is a >bit of a double standard here. I think the implication is that, as a new language, Rust could and should do better. We don't NEED to keep re-implementing the mistakes of the past. C/C++ is, of course, constrained by those mistakes, because of their long history, but a new language isn't. That said, I *would* like to see in what ways the language itself reinforces these habits. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/Snicker |
| David Brown <david.brown@hesbynett.no>: Sep 22 08:43PM +0200 On 22/09/2022 17:46, Ben Bacarisse wrote: >> readability? You are saving typing a whopping 4 characters! > And C has int, struct, enum, char, const, extern... I think there is a > bit of a double standard here. Rust is supposed to be /better/ than C. It is supposed to look at how C has evolved over the decades, and pick a better starting point. So saying C is as bad, or worse, is not an excuse for poor design choices in Rust. I don't know if I'd agree entirely with Juha here, but I'd certainly agree to some degree. But the point is that /if/ you think it is better to have clearer names, keywords, and language syntax in general, then Rust as a modern language should have done better. Whataboutism is not an acceptable defence, nor is it double standards to use a different language that is worse. Rust definitely scores points (IMHO) for having "mut" and "fn", even if I too would have preferred something a little longer. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 22 08:15PM +0100 > C has evolved over the decades, and pick a better starting point. So > saying C is as bad, or worse, is not an excuse for poor design choices > in Rust. Well all I can say is that's not how I read the remarks. I didn't get any sense of it being a disappointment, just that these things are worthy of criticism. Anyway, short keywords are, to my mind, a complete non-issue. I don't mind them in C and I don't mind them in Rust. > agree to some degree. But the point is that /if/ you think it is > better to have clearer names, keywords, and language syntax in > general, then Rust as a modern language should have done better. It's odd, but I'd never go that far. Maybe I am just not assertive enough for the modern world! If I had this view, I'd express some disappointment in a wasted opportunity, but I could not bring myself to say that the designers should have done better. > Whataboutism is not an acceptable defence, Sure. I was not defending Rust's choice. > nor is it double standards > to use a different language that is worse. Nor was I suggesting the double standard came from making such a multi-faceted choice as which language to use. I was remarking on never having seen this objection raised about C or C++. -- Ben. |
| David Brown <david.brown@hesbynett.no>: Sep 22 10:56PM +0200 On 22/09/2022 21:15, Ben Bacarisse wrote: > worthy of criticism. > Anyway, short keywords are, to my mind, a complete non-issue. I don't > mind them in C and I don't mind them in Rust. It's very much a subjective thing. Unless someone can show real, relevant statistical evidence that one style of keyword length is better than the other in terms of fewer mistakes in code, then it will always be a matter of personal preference and familiarity. (Perhaps people will agree that extremes such as APL and Cobol are not ideal for most programmers.) So I am certainly not saying there's anything wrong with thinking Rust's "mut" and "fn" are fine. I am merely pointing out that it is also fine to think Rust missed an opportunity here and would have been better if the names were more descriptive. And it is fine to think that and also enjoy programming in C and C++ despite their sometimes short (or even non-existent) keywords. (As I have not used Rust for more than a brief "hello, world" style test, it would be unfair for me to express a strong judgement about the lengths of its keywords or library identifiers. But my knee-jerk reaction is that I'd prefer them to be longer.) > enough for the modern world! If I had this view, I'd express some > disappointment in a wasted opportunity, but I could not bring myself to > say that the designers should have done better. For those that think the language could easily have been improved with more longer keywords, or in other ways be "better" than C (for whatever subjective meaning of "better" they choose) it is perhaps wrong to blame Rust's designers. Clearly they /could/ have done better, but it is a lot less clear that they /should/ have done better. One could perhaps blame those promoting Rust as a safer and better alternative to C. Many people would like to see a language that has the efficiency of C but lower risks of code errors. The people, projects and companies of influence who promote a candidate for such a language have a responsibility to ensure it really fits the bill. > Nor was I suggesting the double standard came from making such a > multi-faceted choice as which language to use. I was remarking on > never having seen this objection raised about C or C++. I interpreted your comment as a more direct response to Juha - accusing him personally of double standards. But it looks like I was reading too much into a general comment. Perhaps people are just so used to C and C++ programming that its keywords are considered "normal" or "standard", and everything else is judged in relation to them. "mut" is short because it is shorter than "mutable", rather than being viewed as how well it fits in Rust programming. |
| Bart <bc@freeuk.com>: Sep 22 11:15PM +0100 On 22/09/2022 21:56, David Brown wrote: > test, it would be unfair for me to express a strong judgement about the > lengths of its keywords or library identifiers. But my knee-jerk > reaction is that I'd prefer them to be longer.) I've done a bit more than you then in porting a 70-line benchmark to it: https://github.com/sal55/langs/blob/master/fannkuch.txt (From line 670 and done during a brief period when I had a fully working implementation.) But this apparently is not idiomatic Rust. 'Proper' Rust code has most lines starting with "." (chained method calls I believe, split across lines) and is generally indecipherable to me. Having short keywords (they couldn't even stretch 'fn' to 'fun') is the least of it. (WTH is a borrow checker, and why do I have to concern myself with it instead of writing my app? Either the language should care of it, or give me full control.) It also seems to be one of the slowest languages to compile on the planet. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Sep 23 12:08AM +0100 > On 22/09/2022 21:15, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: <cut> > I interpreted your comment as a more direct response to Juha - > accusing him personally of double standards. But it looks like I was > reading too much into a general comment. Kind of. I was not specifically accusing Juha but saying that his remarks were part of a larger double standard. -- Ben. |
| legalize+jeeves@mail.xmission.com (Richard): Sep 22 07:21PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >"Richard Stallman Announces C Reference" >> It isn't in a common format as GNU TexInfo was used to create it. I like a lot of the stuff that the GNU Project has done, but TexInfo is an abomination and a failure. Nobody[*] has adopted it for use outside of GNU projects. [*] I'm sure someone will post a link to some dinky project that uses it, but I'm making a statement fit for human consumption not writing mathematical axioms. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Sep 22 07:24PM [Please do not mail me a copy of your followup] Opus <ifonly@youknew.org> spake the secret code >What's exactly the point of keeping trolling [...] Why, to improve your KILL file, naturally. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 22 11:44AM -0700 > it gets extremely easily confused with strcpy(), as if it were a "safer" > variant of it, in the same was as strncat() is a "safer" variant of > strcat(). It's already been pointed out that the source argument to strncpy() does not need to be a pointer to a (null-terminated) string. And yes, the name is misleading (also already pointed out). -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment