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.
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.
“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.
I'm not sure where this definition is coming from. Let's look at this code:
vec.len()
- 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
self.first_name + " " + self.last_name
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.