3 ms·

whats it mean

082349872349872 3y ago
imperative programming is like sitting in one chair; pure functional programming like sitting in the neighbouring chair; and Meijer's thesis in TFA is that "mostly functional" programming will turn out to be like attempting to sit in the space between them. for the title, see https://en.wikipedia.org/wiki/Law_of_excluded_middle https://en.wikipedia.org/wiki/Law_of_excluded_middle (given his involvement with C#, I am willing to consider the notion that his views may well reflect having had unpleasant experiences. If Rust moves beyond the "innovator" segment, it would be a counterexample.) Edit: NB (2014) ; he may well have revisited this topic more recently?
- beanjuiceII 3y ago
  thanks, I know erik uses kotlin often, does he think we just have to live in that middle area? is the paper just an observation ? how do you think rust solves the problem?
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 ago
  thanks! 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?

whats it mean

imperative programming is like sitting in one chair; pure functional programming like sitting in the neighbouring chair; and Meijer's thesis in TFA is that "mostly functional" programming will turn out to be like attempting to sit in the space between them. for the title, see https://en.wikipedia.org/wiki/Law_of_excluded_middle https://en.wikipedia.org/wiki/Law_of_excluded_middle (given his involvement with C#, I am willing to consider the notion that his views may well reflect having had unpleasant experiences. If Rust moves beyond the "innovator" segment, it would be a counterexample.) Edit: NB (2014) ; he may well have revisited this topic more recently?

beanjuiceII 3y ago
thanks, I know erik uses kotlin often, does he think we just have to live in that middle area? is the paper just an observation ? how do you think rust solves the problem?

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 ago
thanks! 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?