3 ms·
Explicit is, as they say, better than implicit.
by zetalyrae 4y ago
Explicit is, as they say, better than implicit.
- kazinator 4y agoNo it isn't. Even machine language has implicit behaviors which make it suck less like the next instruction implicitly being found at the next address after the previous instruction, without which you'd need an explicit indication of where you want to go. We can just about define the concept of a higher level language in terms of how it makes numerous chores and concerns implicit. Good explicit could beat bad implicit in some situations, and vice versa.
- thaumasiotes 4y ago> Even machine language has implicit behaviors which make it suck less like the next instruction implicitly being found at the next address after the previous instruction, without which you'd need an explicit indication of where you want to go. That's not right. There is an explicit indication of where you want to go, the program counter. By default it will increment in an explicit, documented way, but you can also write directly to it. There's nothing implicit about it.
- deleted 4y ago[deleted]
- kazinator 4y agoIf an instruction changes the program counter, but the program counter doesn't appear as an operand of that instruction, then the effect is implicit. "Appearing as an operand" means that the instruction could choose a different register to increment other than the program counter, and to increment it by a different value other than exactly to the next instruction. Indeed, if there is a program counter visible as a register, then it is an explicit representation of where execution is happening. You don't seem to be sensitive to the IMHO critical difference between "explicit representation" and "explicit operation", though. An explicit representation can be subject to the implicit effects of operations. E.g. is is implicit that mkdir("foo", 0755) in Unix will create the directory entries "." and "..". Much of the time you don't worry about them. They are explicitly there, to be sure. A closure object is an explicit representation of a function; the capture of lexical varaible values by a closure is implicit.