4 ms·

What a useful breakdown! It seems like the narrow definition of “explicit” that the author uses is equivalent to “deterministic”. If that’s true, then “explici

by scribu 9y ago

What a useful breakdown! It seems like the narrow definition of “explicit” that the author uses is equivalent to “deterministic”. If that’s true, then “explicit” could always be replaced with a more precise alternative.

bad_user 9y ago
No, I don’t think that’s what the author is saying, but to make it clear the definition is: “In computer science, a deterministic algorithm is an algorithm which, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states” In turn what the author is saying is precisely what he says, no more, no less - explicit code is code whose behavior you can understand just by reading it, with no external context, like how the runtime currently works on a particular hardware. The examples he gives are very clear as well. For example he claims to know the stack allocations that will happen just by looking at the definitions of the data types. You can’t know this on the JVM for example because the JVM does optimizations under the hood that the programmer cannot control or reason about. This doesn’t yield non-determinism. What happens is that the developer ends up programming for a higher level machine that hides some details of the underlying hardware. Explicit isn’t always better than implicit, an argument that the author also makes. Overall I find the article very compelling and I’ll be sure to use it for reference, as it’s what I also think, but with better words.
- judofyr 9y ago
  > In turn what the author is saying is precisely what he says, no more, no less - explicit code is code whose behavior you can understand just by reading it, with no external context, like how the runtime currently works on a particular hardware. I'm not sure where this definition is coming from. Let's look at this code: vec.len() I understand this behaviour very clearly. This will invoke the method given the following rules: - Look for `len` on the type of `vec` - If `vec` implements Deref it will look for `len` there - Look for `len` on traits that the type of `vec` implements - And so on… Yes, the behaviour is conditional, but it's still well-defined and easy to understand, although complex. "Implicit" is usually used when you want to describe situations where there are multiple interpretations, and one is chosen due to context. In Ruby: first_name + " " + last_name In this example `first_name` can either be a local variable or a method call (which can either be in the same class, an included module, or a method_missing). Here it turns out it was a method call, and we therefore call this an "implicit method call". I can rewrite: self.first_name + " " + self.last_name In this case there is a single interpretation: It can only be a method call. However, while this code is explicit on whether or not it's a method call, it's not explicit about which method is being invoked. Usually this implicitness is considered a good feature since it allows abstraction, polymorphism and so on.
masklinn 9y ago
Not really, programming languages behaviours are almost always deterministic (UB + compiler shenanigans aside). For instance the weirder corners of JS value coercions are exhaustively documented and deterministically followed by browsers, but I would argue they're not explicit, unless you're bi-classed language lawyer or have already been bitten several times, you don't "see" this (again completely deterministic) process when reading the usually innocent-looking code which ends up invoking it.

by scribu 9y ago

bad_user 9y ago

No, I don’t think that’s what the author is saying, but to make it clear the definition is: “In computer science, a deterministic algorithm is an algorithm which, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states” In turn what the author is saying is precisely what he says, no more, no less - explicit code is code whose behavior you can understand just by reading it, with no external context, like how the runtime currently works on a particular hardware. The examples he gives are very clear as well. For example he claims to know the stack allocations that will happen just by looking at the definitions of the data types. You can’t know this on the JVM for example because the JVM does optimizations under the hood that the programmer cannot control or reason about. This doesn’t yield non-determinism. What happens is that the developer ends up programming for a higher level machine that hides some details of the underlying hardware. Explicit isn’t always better than implicit, an argument that the author also makes. Overall I find the article very compelling and I’ll be sure to use it for reference, as it’s what I also think, but with better words.

judofyr 9y ago
> In turn what the author is saying is precisely what he says, no more, no less - explicit code is code whose behavior you can understand just by reading it, with no external context, like how the runtime currently works on a particular hardware. I'm not sure where this definition is coming from. Let's look at this code: vec.len() I understand this behaviour very clearly. This will invoke the method given the following rules: - Look for `len` on the type of `vec` - If `vec` implements Deref it will look for `len` there - Look for `len` on traits that the type of `vec` implements - And so on… Yes, the behaviour is conditional, but it's still well-defined and easy to understand, although complex. "Implicit" is usually used when you want to describe situations where there are multiple interpretations, and one is chosen due to context. In Ruby: first_name + " " + last_name In this example `first_name` can either be a local variable or a method call (which can either be in the same class, an included module, or a method_missing). Here it turns out it was a method call, and we therefore call this an "implicit method call". I can rewrite: self.first_name + " " + self.last_name In this case there is a single interpretation: It can only be a method call. However, while this code is explicit on whether or not it's a method call, it's not explicit about which method is being invoked. Usually this implicitness is considered a good feature since it allows abstraction, polymorphism and so on.

masklinn 9y ago

Not really, programming languages behaviours are almost always deterministic (UB + compiler shenanigans aside). For instance the weirder corners of JS value coercions are exhaustively documented and deterministically followed by browsers, but I would argue they're not explicit, unless you're bi-classed language lawyer or have already been bitten several times, you don't "see" this (again completely deterministic) process when reading the usually innocent-looking code which ends up invoking it.