3 ms·

Rust's design and development was incredibly informed by knowledge of programming language history. People making different judgments and decisions than you wou

Rust's design and development was incredibly informed by knowledge of programming language history. People making different judgments and decisions than you would have made is not necessarily evidence that they are less knowledgeable than you, it is often the case that they have just come to different conclusions than you have. That's why there isn't one perfect version of everything; similarly knowledgeable and well-intentioned people often prefer incredibly different answers to the same questions. It's kind of surprising, maybe, but it's also why humanity is so interesting and varied; why we have so much different kinds of art and music and architecture and stuff. 100% of your examples are things that you seem to think have exactly one correct answer, but which people actually have different preferences on and different reasons for choosing different approaches. I promise you that Graydon Hoare was familiar with the concept of in, out, and in-out parameters when he started working on rust. None of this means that any language is perfect, it's just that you're ascribing things to ignorance that are far more likely to reflect differences of opinion on subjective questions.

adrian_b 3y ago
I agree that many differences between programming languages are differences between programming styles where it cannot be said that one variant or the other is definitely better, but only that one variant is more suitable for some people while the other variant is more suitable for other people. Nevertheless, I have been careful to not choose an example of this kind, but one where there is no doubt about what is right and what is wrong. I am curious how do you justify that it is a good thing for a programmer to waste time to think whether a function should be invoked as f(x) or f(&x) and to waste time and page space with writing and reading "&" symbols, when this wasted time cannot bring any contribution to solving whatever problem needs to be solved. Choosing whether to pass parameters by value or by reference is a problem of the same nature as the allocation of the hardware registers, which does not belong to a high-level language. The C keyword "register" is now obsolete, but the parameter-passing method should have become obsolete at the same time. Of course, for this to become possible, the direction of the parameters must be specified, to allow a correct compiler decision. When the direction of the parameters is specified, "const" no longer needs to be specified, because it is implied by "in". Moreover, like I have said, any language that does not distinguish out parameters from in-out parameters, but which nonetheless allows the definition of new data types, together with mechanisms for their allocation, initialization, and deallocation, becomes excessively complicated, because it must add a special kind of functions that support one "out" parameter, i.e. the constructors, despite the fact that normal functions do not support such parameters, and then for each new type several kinds of distinct constructors and operators are needed, e.g. copy constructor, move constructor, assignment, which would not have been needed otherwise. When out and in-out are distinguished, assignment is not an operator, like in C++, but only a syntactic separator. In languages like C++, the programmer also needs to annotate some operations, so that they will use the kinds of implicit constructors that will be efficient in that context. So if the defined data types can be used in any ways in which primitive types are used, then the mess of C++ is unavoidable. If there are restrictions on how the defined types are used, e.g. when operators cannot be overloaded or when various other such restrictions are enforced, then some of the complications of C++ can be avoided but such restrictions are even less desirable. So between a single super simple rule of specifying in all function prototypes whether the parameters are in, out or in-out and having to keep in mind a great number of rules of how to deal with constructors in general and with several kinds of special constructors, in order to achieve acceptable performance when handling large objects, I do not see how there can be alternative views about which is right and which is wrong, except when they are based on lack of familiarity with the right solution. When out and in-out parameters are distinguished, there are no constructors as a special category and no worries about them. An object can be initialized with any function that has an out parameter of the correct type. The only constructor is the default constructor, which is an ordinary function that needs to be specified only so that the compiler will invoke it implicitly when there is no explicit initializer.
- sanderjd 3y ago
  > I do not see how there can be alternative views about which is right and which is wrong, except when they are based on lack of familiarity with the right solution. Well, I understand that you struggle to see how it's possible, but it just is the case that people disagree with you about this stuff, not out of ignorance, but simply by coming to different conclusions than you. I certainly understand that it's frustrating; I have tons of views of all kinds that I think people should see are objective truths, but maddeningly they do not. But that's just how it is! For what it's worth, if I designed a programming language, you would be a bigger fan of its parameter passing solution. But there would probably be ten other things you wouldn't like! There just isn't a universal truth about this stuff, people have all sorts of different preferences along every axis of language design.

adrian_b 3y ago

I agree that many differences between programming languages are differences between programming styles where it cannot be said that one variant or the other is definitely better, but only that one variant is more suitable for some people while the other variant is more suitable for other people. Nevertheless, I have been careful to not choose an example of this kind, but one where there is no doubt about what is right and what is wrong. I am curious how do you justify that it is a good thing for a programmer to waste time to think whether a function should be invoked as f(x) or f(&x) and to waste time and page space with writing and reading "&" symbols, when this wasted time cannot bring any contribution to solving whatever problem needs to be solved. Choosing whether to pass parameters by value or by reference is a problem of the same nature as the allocation of the hardware registers, which does not belong to a high-level language. The C keyword "register" is now obsolete, but the parameter-passing method should have become obsolete at the same time. Of course, for this to become possible, the direction of the parameters must be specified, to allow a correct compiler decision. When the direction of the parameters is specified, "const" no longer needs to be specified, because it is implied by "in". Moreover, like I have said, any language that does not distinguish out parameters from in-out parameters, but which nonetheless allows the definition of new data types, together with mechanisms for their allocation, initialization, and deallocation, becomes excessively complicated, because it must add a special kind of functions that support one "out" parameter, i.e. the constructors, despite the fact that normal functions do not support such parameters, and then for each new type several kinds of distinct constructors and operators are needed, e.g. copy constructor, move constructor, assignment, which would not have been needed otherwise. When out and in-out are distinguished, assignment is not an operator, like in C++, but only a syntactic separator. In languages like C++, the programmer also needs to annotate some operations, so that they will use the kinds of implicit constructors that will be efficient in that context. So if the defined data types can be used in any ways in which primitive types are used, then the mess of C++ is unavoidable. If there are restrictions on how the defined types are used, e.g. when operators cannot be overloaded or when various other such restrictions are enforced, then some of the complications of C++ can be avoided but such restrictions are even less desirable. So between a single super simple rule of specifying in all function prototypes whether the parameters are in, out or in-out and having to keep in mind a great number of rules of how to deal with constructors in general and with several kinds of special constructors, in order to achieve acceptable performance when handling large objects, I do not see how there can be alternative views about which is right and which is wrong, except when they are based on lack of familiarity with the right solution. When out and in-out parameters are distinguished, there are no constructors as a special category and no worries about them. An object can be initialized with any function that has an out parameter of the correct type. The only constructor is the default constructor, which is an ordinary function that needs to be specified only so that the compiler will invoke it implicitly when there is no explicit initializer.

sanderjd 3y ago
> I do not see how there can be alternative views about which is right and which is wrong, except when they are based on lack of familiarity with the right solution. Well, I understand that you struggle to see how it's possible, but it just is the case that people disagree with you about this stuff, not out of ignorance, but simply by coming to different conclusions than you. I certainly understand that it's frustrating; I have tons of views of all kinds that I think people should see are objective truths, but maddeningly they do not. But that's just how it is! For what it's worth, if I designed a programming language, you would be a bigger fan of its parameter passing solution. But there would probably be ten other things you wouldn't like! There just isn't a universal truth about this stuff, people have all sorts of different preferences along every axis of language design.