5 ms·

I didn't agree with this article's definition of "explicit," which feels tautological: Rust is explicit because you can figure out a lot about your program fro

I didn't agree with this article's definition of "explicit," which feels tautological: Rust is explicit because you can figure out a lot about your program from the source of it. But as long as the source code conveys the information, it is still explicit in the narrow sense I defined above. But if the thing will happen deterministically in a manner that can be derived from the source, it is still explicit in the narrow sense that I laid out earlier. Source code conveys everything possible about your program in any language. The best notion of "explicit" is captured by the critique of "local." Here's some nice ways in which Rust is more "local" than C++: 1. Macros require bang!s instead of C++ surprise-insides 2. References require &s and `mut &`s instead of C++ implicit references. 3. Int -> FP conversions require a typecast In every case, both Rust and C++ allow you to discover the runtime behavior by reading the source code. But I would argue that Rust is more explicit than C++ in every case, wouldn't you agree? A feature of Rust that is not implicit, but also not local, is method resolution Isn't method resolution intimately tied to Deref coercion, which allows a type to implicitly (Rust's language) implement methods of another type? So method resolution seems like one of the more implicit features within Rust. but all of it is explicit if you look at the impl blocks for Vec<T>. Well, all of Ruby's monkey-patching is explicit in the sense that you can find it if you know where to look. It's a good effort to refine the meaning but "local" IMO is the best one!

coderkd10 9y ago
> Source code conveys everything possible about your program in any language. I disagree with this statement. Behaviour of the program will be determined by machine instructions that the compiler generates for a given source plus the machine environment where these instructions will be run. And it is not guaranteed that the generated instructions will be same for a given source across different architectures and environments that the compiler is run (plus I guess there is generally some degree of non-determinism in the compilers as well, because of the different optimizations it can make under different conditions, which are not "explicit" from the source itself). As far I understood, in the notion of explicitness that is defined in the article, it is defined that the language where source almost completely specifies the behaviour of program, irrespective of the compiler environments where it is compiled on, is an explicit language. I think in the sibling comment https://news.ycombinator.com/item?id=16034541 https://news.ycombinator.com/item?id=16034541 bad_user articulates more clearly the point I was trying to make.
- judofyr 9y ago
  The behaviour is usually determined by language specification, and there are many machine instructions that can cause the correct behaviour. There are some cases where languages have machine-dependent behaviour, but most parts of most languages define the semantics independent of the machine it's running on. > As far I understood, in the notion of explicitness that is defined in the article, it is defined that the language where source almost completely specifies the behaviour of program, irrespective of the compiler environments where it is compiled on, is an explicit language. I've never seen anyone use this definition for "explicit". Most people use "explicit" to describe syntactical differences (e.g. "explicit vs implicit self/this"). "Implicits" in Scala is where the compiler inserts a method/function-call that didn't exist syntactically. The behaviour is still well-defined and not dependent on the machine instructions. What you're describing sounds to me more about the language defining its own execution model that's abstracted above actual computers.
viraptor 9y ago
>> but all of it is explicit if you look at the impl blocks for Vec<T>. > Well, all of Ruby's monkey-patching is explicit in the sense that you can find it if you know where to look. There's a big difference. All impls in the first case can be found in a specific module and are listed in the generated documentation. If you want that information, there's one place to look. In case of any monkey patching, that's not the case. It can happen literally anywhere, it can happen conditionally, and the code doesn't even have to mention the patched class since it can receive it as a parameter, which makes it impossible to even grep for.
- jopsen 9y ago
  So the definition of explicit or not has to do with the computability of the question. Method resolution is not computable in a dynamic language with monkey patching. Hence, not explicit. That's a good point.
  - pgwhalen 9y ago
    Another way to think about it is whether the IDE can do it for you. As a Java dev (who is admittedly a bit of a slave to IntelliJ) this is a huge part of my programming experience.
    - nitrogen 9y ago
      A heavyweight IDE is really only necessary because of the unwieldiness of Java patterns for naming and code layout. Autocompletion and navigation leads to code that is only manageable with those features in a vicious cycle.
__s 9y ago
Your example comparing to C++ is something where I think the point of this article is coming out: we can become more explicit about what we're talking about when we bring nuance into our language to describe things like 'local' vs 'statically determined' which in language design discussions are both being labelled 'explicit' despite being distinct concepts. Explicit has been overused to the point of being a bad word
- plumenator 9y ago
  As in "explicit content"?

coderkd10 9y ago

> Source code conveys everything possible about your program in any language. I disagree with this statement. Behaviour of the program will be determined by machine instructions that the compiler generates for a given source plus the machine environment where these instructions will be run. And it is not guaranteed that the generated instructions will be same for a given source across different architectures and environments that the compiler is run (plus I guess there is generally some degree of non-determinism in the compilers as well, because of the different optimizations it can make under different conditions, which are not "explicit" from the source itself). As far I understood, in the notion of explicitness that is defined in the article, it is defined that the language where source almost completely specifies the behaviour of program, irrespective of the compiler environments where it is compiled on, is an explicit language. I think in the sibling comment https://news.ycombinator.com/item?id=16034541 https://news.ycombinator.com/item?id=16034541 bad_user articulates more clearly the point I was trying to make.

judofyr 9y ago
The behaviour is usually determined by language specification, and there are many machine instructions that can cause the correct behaviour. There are some cases where languages have machine-dependent behaviour, but most parts of most languages define the semantics independent of the machine it's running on. > As far I understood, in the notion of explicitness that is defined in the article, it is defined that the language where source almost completely specifies the behaviour of program, irrespective of the compiler environments where it is compiled on, is an explicit language. I've never seen anyone use this definition for "explicit". Most people use "explicit" to describe syntactical differences (e.g. "explicit vs implicit self/this"). "Implicits" in Scala is where the compiler inserts a method/function-call that didn't exist syntactically. The behaviour is still well-defined and not dependent on the machine instructions. What you're describing sounds to me more about the language defining its own execution model that's abstracted above actual computers.

viraptor 9y ago

>> but all of it is explicit if you look at the impl blocks for Vec<T>. > Well, all of Ruby's monkey-patching is explicit in the sense that you can find it if you know where to look. There's a big difference. All impls in the first case can be found in a specific module and are listed in the generated documentation. If you want that information, there's one place to look. In case of any monkey patching, that's not the case. It can happen literally anywhere, it can happen conditionally, and the code doesn't even have to mention the patched class since it can receive it as a parameter, which makes it impossible to even grep for.

jopsen 9y ago
So the definition of explicit or not has to do with the computability of the question. Method resolution is not computable in a dynamic language with monkey patching. Hence, not explicit. That's a good point.
- pgwhalen 9y ago
  Another way to think about it is whether the IDE can do it for you. As a Java dev (who is admittedly a bit of a slave to IntelliJ) this is a huge part of my programming experience.
  - nitrogen 9y ago
    A heavyweight IDE is really only necessary because of the unwieldiness of Java patterns for naming and code layout. Autocompletion and navigation leads to code that is only manageable with those features in a vicious cycle.

__s 9y ago

Your example comparing to C++ is something where I think the point of this article is coming out: we can become more explicit about what we're talking about when we bring nuance into our language to describe things like 'local' vs 'statically determined' which in language design discussions are both being labelled 'explicit' despite being distinct concepts. Explicit has been overused to the point of being a bad word

plumenator 9y ago
As in "explicit content"?