5 ms·

but mentioning the drawbacks of that kind of approach to language design suddenly requires "scientific studies demonstrating your points"? Are yo

by Ygg2 12y ago

but mentioning the drawbacks of that kind of approach to language design suddenly requires "scientific studies demonstrating your points"? Are you kidding me? That's exactly what I meant with "Rust people are actively hostile toward input". For what is worth, I only meant it in case of underscore, since underscore syntax has scientific proof it's more readable, if you are aware of a better or another study, please list them. Also I asked for examples. But here let me look at your complaints: 1) Not sure what you mean in this case, could you elaborate 2) Type casing is inconsitent. All types are CapitalCamelCase. Only special built-in literals are lower case. 3) Fair point, a bit subjective, but fair. I like the terse syntax tbh. 4) Well, String represents mutable and str represents immutable strings, which also double as string views. 5) Fair point, I prefer [] for generics, but again it still falls under subjective. 6/7) I'm unsure what you mean. [] is used for indexing arrays or slicing a piece of it. I think Python had something similar. If you have foo(x) that's always AFAIK calling function. foo[x] means it's calling index or slice operator on a foo. In either case it's taking a portion of foo. 7) see 6 8) That's actually a fairly good point. I think some kind of optional parameters or varargs were planned, but unsure of current situation 9) Not getting what you mean here? Whenever you add extensibility to language via macros or custom operators, you get weird language DSLs that are incomprehensible. At least putting macro_name! tells you next part is DSL and what's its name is, so you can look it up. 10) Fucking up generics? What? 11) Not sure what your point is? Rust doesn't have objects. It has structs and it has traits. Modules are merely way to organize code. I think you are probably referring to OCaml like modules/objects, but unsure what. 12) Fair point. I'm unsure what alternatives you have in mind? Using URLs?

frowaway001 12y ago
1) You basically have both () and [], wasting one of the scarcest resources in syntax (brackets). Some people might argue that getting a value from an array is totally different from getting the same value from a function or a map, and deserves special syntax. If we look at languages which did away with this made-up difference we see that pretty much no person is missing it. Even if you disagree with this reasoning and consider arrays to be something very special, deserving its own syntax – guess what? Rust developers introduced the traits Index and IndexMut, so all the great ideas about some type being special and knowing what happens when you read [] went straight out of the window. If we dig deeper and try to understand why they did something so astoundingly mis-designed, we basically hit an interesting issue: They overloaded their [] operator to do two completely different things, depending on whether there is an & in front. Thing A: return the value at the given index Thing B: return an address pointing into the indexed data This of course doesn't translate well into the () syntax, given that Rust devs are proud that they don't support overloading. (I guess []'s overloading doesn't count for some reason ... and doing the little dance with traits doesn't count either.) Taking a step back, if it would have been considered acceptable to pick two different names for doing two different things, the whole issue wouldn't exist, e. g.: Thing A: values(1) Thing B: values.at(1) 2) Yes, we agree. Having different sets of rules for a) language designers and b) language users has shown consistent results: It never worked out. 3) Yes. I have nothing against terse syntax, it should just be consistent. (I favor not abbreviating things though, because it's difficult to be both terse and consistent, considering that things can be abbreviated in more than one way.) 4) Yes, I know what they do. I just thought it was a nice example of two related constructs having different casing style and abbreviation style. 6/7) See 1). The sad thing is that [] can do whatever the developer wants. All guarantees went out of the window with Index/IndexMut. 9) What I meant was that not every macro wants to define some weird language DSL. There are plenty of things which only exist as macros because the language lacks varargs. (vec! for instance.) If the language ever adds varargs, vec! can't just stop being a macro, because that would break source compatibility: They would need to keep the macro version of vec and introduce a new non-macro version of vec, and hope people migrate from vec! to the "new" vec. It's a design which makes the common 90% suffer for the benefit of the most complex 10%. Sometimes it is worth it, but in this case I think it is not. 10) I had the combination of picking a symbol which is both hard to read and hard to parse in mind. Every language that chose <> has weird cruft and therefore it shouldn't haven been too surprising that Rust is also suffering issues, but in Rust's case the problems have been shokingly severe. There are loooong discussions about it if you want to read them. (So it's not just me.) 11) Sorry, I meant structs. 12) URLs are an option. There are also alternatives. I think the essence is that it's possible to deal with these issues without entering Java's tld.mycompany.mycontinent.mygroup.myproject.mydogsmiddlename madness. I hope this cleared some things up. :-)
- Ygg2 12y ago
  1) Sure, pair symbols are a bit rare. But they aren't as rare as you set them to be. Symbols like / | or \ can act as substitute for bracket like syntax. > If we look at languages which did away with this made-up difference we see that pretty much no person is missing it. Eh, not sure what languages are these and how you think they relate to Rust. Keep in mind Rust goal almost from the start was something that is familiar to a people that worked with Gecko engine. With that in mind, I can't think of a similar family language that did this. You know what happens when you call Index/IndexMut. To say it isn't so, is outright fallacious. Also Rust takes the probably best road of allowing limited operator overload, which IMO so far proved better than allowing no operator overload or allowing custom operator overload - which is subject to weird rules and/or leads to heavily overloaded code. Also [] always does same thing. For given Index value it returns value found at that index. & is not an address. AFAIK address are never allowed unless you drop into unsafe. It's a borrow reference to Output value. Index returns immutable version, while IndexMut takes mutable version and returns mutable output value. 2) No we don't. I think having user and built-in defined types is perfectly ok. In any non-Lispy langugage there are special literals, which can't be handled by user defined ways, unless you allow for some funky grammar. 4) Related yes, same no. In same way i32 and u32 are related but not the same. As I said in previous question having some subset of language be unable to modify is IMHO a good thing. 6/7) They can't. You can tell by mutability of array which one will be called and which one will be returned. You CAN'T EVER change type of mutability of result. 9) Whenever I see macros/operator overload/syntax being given too much freedom, it always ends up with incomprehensible DSL-s that you can't disentangle from regular code. 10) Subjective opinion. And it could be trivially solved with better type aliases. 12) I don't think it's a big problem and a fix to Cargo that adds a special unique identifier should be trivial to implement, although not necessarily forward/backward compatible.
  - Ygg2 12y ago
    What multiple Rust proponents? Where? What people consider [] superior to <>? How many? Your text have an air of superiority but your arguments leave a lot to be desired or to be more frank [Citation needed].
  - 12y ago

by Ygg2 12y ago

frowaway001 12y ago

1) You basically have both () and [], wasting one of the scarcest resources in syntax (brackets). Some people might argue that getting a value from an array is totally different from getting the same value from a function or a map, and deserves special syntax. If we look at languages which did away with this made-up difference we see that pretty much no person is missing it. Even if you disagree with this reasoning and consider arrays to be something very special, deserving its own syntax – guess what? Rust developers introduced the traits Index and IndexMut, so all the great ideas about some type being special and knowing what happens when you read [] went straight out of the window. If we dig deeper and try to understand why they did something so astoundingly mis-designed, we basically hit an interesting issue: They overloaded their [] operator to do two completely different things, depending on whether there is an & in front. Thing A: return the value at the given index Thing B: return an address pointing into the indexed data This of course doesn't translate well into the () syntax, given that Rust devs are proud that they don't support overloading. (I guess []'s overloading doesn't count for some reason ... and doing the little dance with traits doesn't count either.) Taking a step back, if it would have been considered acceptable to pick two different names for doing two different things, the whole issue wouldn't exist, e. g.: Thing A: values(1) Thing B: values.at(1) 2) Yes, we agree. Having different sets of rules for a) language designers and b) language users has shown consistent results: It never worked out. 3) Yes. I have nothing against terse syntax, it should just be consistent. (I favor not abbreviating things though, because it's difficult to be both terse and consistent, considering that things can be abbreviated in more than one way.) 4) Yes, I know what they do. I just thought it was a nice example of two related constructs having different casing style and abbreviation style. 6/7) See 1). The sad thing is that [] can do whatever the developer wants. All guarantees went out of the window with Index/IndexMut. 9) What I meant was that not every macro wants to define some weird language DSL. There are plenty of things which only exist as macros because the language lacks varargs. (vec! for instance.) If the language ever adds varargs, vec! can't just stop being a macro, because that would break source compatibility: They would need to keep the macro version of vec and introduce a new non-macro version of vec, and hope people migrate from vec! to the "new" vec. It's a design which makes the common 90% suffer for the benefit of the most complex 10%. Sometimes it is worth it, but in this case I think it is not. 10) I had the combination of picking a symbol which is both hard to read and hard to parse in mind. Every language that chose <> has weird cruft and therefore it shouldn't haven been too surprising that Rust is also suffering issues, but in Rust's case the problems have been shokingly severe. There are loooong discussions about it if you want to read them. (So it's not just me.) 11) Sorry, I meant structs. 12) URLs are an option. There are also alternatives. I think the essence is that it's possible to deal with these issues without entering Java's tld.mycompany.mycontinent.mygroup.myproject.mydogsmiddlename madness. I hope this cleared some things up. :-)

Ygg2 12y ago
1) Sure, pair symbols are a bit rare. But they aren't as rare as you set them to be. Symbols like / | or \ can act as substitute for bracket like syntax. > If we look at languages which did away with this made-up difference we see that pretty much no person is missing it. Eh, not sure what languages are these and how you think they relate to Rust. Keep in mind Rust goal almost from the start was something that is familiar to a people that worked with Gecko engine. With that in mind, I can't think of a similar family language that did this. You know what happens when you call Index/IndexMut. To say it isn't so, is outright fallacious. Also Rust takes the probably best road of allowing limited operator overload, which IMO so far proved better than allowing no operator overload or allowing custom operator overload - which is subject to weird rules and/or leads to heavily overloaded code. Also [] always does same thing. For given Index value it returns value found at that index. & is not an address. AFAIK address are never allowed unless you drop into unsafe. It's a borrow reference to Output value. Index returns immutable version, while IndexMut takes mutable version and returns mutable output value. 2) No we don't. I think having user and built-in defined types is perfectly ok. In any non-Lispy langugage there are special literals, which can't be handled by user defined ways, unless you allow for some funky grammar. 4) Related yes, same no. In same way i32 and u32 are related but not the same. As I said in previous question having some subset of language be unable to modify is IMHO a good thing. 6/7) They can't. You can tell by mutability of array which one will be called and which one will be returned. You CAN'T EVER change type of mutability of result. 9) Whenever I see macros/operator overload/syntax being given too much freedom, it always ends up with incomprehensible DSL-s that you can't disentangle from regular code. 10) Subjective opinion. And it could be trivially solved with better type aliases. 12) I don't think it's a big problem and a fix to Cargo that adds a special unique identifier should be trivial to implement, although not necessarily forward/backward compatible.
- Ygg2 12y ago
  What multiple Rust proponents? Where? What people consider [] superior to <>? How many? Your text have an air of superiority but your arguments leave a lot to be desired or to be more frank [Citation needed].
- 12y ago