2 ms·
In imperative programming, you write statements which change the state of the system. When you go to debug a method, you need to be able to recreate the state
by mrkeen 3y ago
In imperative programming, you write statements which change the state of the system.
When you go to debug a method, you need to be able to recreate the state of the system in order see how the method misbehaves.
But a function always has the same output given the same input. It doesn't matter how big the function gets or how many other functions it calls. So if f(1, "foo", 47) throws an exception on a prod server, you can run exactly that function locally and watch it throw the same exception.
Now someone might come along and change f's source code so that it mutates something, or reads from something which can be mutated. And they might call f 'mostly functional'. But it no longer returns the same output for the same input. f(1, "foo", 47) may or may not equal f(1, "foo", 47), so you're back to debugging methods, not functions.
A method being 'mostly-functional' is like 'int i' being 'mostly-const'.
- beanjuiceII 3y agothanks! so does erik suggest one or the other? or that we must all live in that middle? last I checked he was knee deep in kotlin which I'm assuming is in that middle area?