I knew it was by Conal before I got to the end, as soon as I saw the phrase "denotational semantics" ;)
I should really learn what that means one day...
I should really learn what that means one day...
This fits well with the functional paradigm, where values are immutable and therefore 'timeless'.
In contrast, imperative code, if it has any actual semantics at all, tends to be operational:
Operational semantics: the "meaning" of code is how it affects the behaviour of the machine that's interpreting it.
The problem with operational semantics is exactly that of imperative code: in order to understand what some code will do, you need to know everything which 'happened before' (ie. the current state of the machine).
But in Haskell, say, because of lazy evaluation, it's easier to lose track of how much CPU effort something is going to cost, and when you're going to have to pay for it.
This is becoming less true, of course. Java getting lambdas hides a TON of places where you just managed to allocate a ton of memory and/or perform a ton of operations.
And note, I do think this downside can be oversold. So, don't take this as a condemnation of "functional" languages and methods. It definitely exists, though.
Granted, I am almost certainly simply infatuated with what is essentially an "anti immutable" algorithm. http://taeric.github.io/Sudoku.html
It isn't even that I don't think they have a good product. They certainly do. One need only actually read SICP to realize just how bloody amazing some of these ideas are. (Granted, they didn't use all of the modern names. But they certainly seem to have hit all of the modern ideas.)
Wouldn't knowledge of everything within the current scope be sufficient?