4 ms·

I'm not sure who is making those sort of arguments. Aside from many imperative languages that implement functional language features (pretty much all of them th

I'm not sure who is making those sort of arguments. Aside from many imperative languages that implement functional language features (pretty much all of them these days), there already exist hybrid languages. For example, Scala is an imperative/functional programming language hybrid. Yes, you can use Scala as mostly imperative I suppose, but I've found you end up doing some things in a functional manner in many cases because it's far easier.

the_af 11y ago
Erik Meijer is making those sort of arguments, though he tends to change his mind frequently. I'm copying the conclusions of his talk "The Curse of the Excluded Middle" ( https://queue.acm.org/detail.cfm?id=2611829 https://queue.acm.org/detail.cfm?id=2611829 ), which is appropriately subtitled "'Mostly functional' programming does not work": "The idea of "mostly functional programming" is unfeasible. It is impossible to make imperative programming languages safer by only partially removing implicit side effects. Leaving one kind of effect is often enough to simulate the very effect you just tried to remove. On the other hand, allowing effects to be "forgotten" in a pure language also causes mayhem in its own way. Unfortunately, there is no golden middle, and we are faced with a classic dichotomy: the curse of the excluded middle, which presents the choice of either (a) trying to tame effects using purity annotations, yet fully embracing the fact that your code is still fundamentally effectful; or (b) fully embracing purity by making all effects explicit in the type system and being pragmatic by introducing nonfunctions such as unsafePerformIO. The examples shown here are meant to convince language designers and developers to jump through the mirror and start looking more seriously at fundamentalist functional programming."
- pron 11y ago
  I really don't like how some PFP proponents -- as Meijer does in that article -- make a leap from a correct premise to an unjustified conclusion. Even if we accept that unrestricted, unchecked, non-transactional mutation of shared state is a source of many bugs, it does not for one second follow that going fully referentially-transparent must be the only solution to ensure correctness. To me that argument sounds like, "wrist pain is a source of misery for many developers, hence we should chop off our arms and program using gestures with our tongue, which turns out to be a much more elegant solution" (I'm exaggerating, of course). It's as if provably verifiable, safe, imperative programming languages don't exist, and haven't been used to write safety-critical system for quite some time (actually, verifiable imperative languages have been used much more than PFP languages to develop such systems). Also, the appeal to lambda-calculus(/i) as a more "mathematical" approach to computation (as if that is a goal in itself) discounts the fact that LC -- even as a theoretical model -- has some serious drawbacks, such as the lack of a good model of computational complexity.
  - the_af 11y ago
    In this case, I was merely pointing out that some practitioners and theorists are making "this kind of arguments". As for the rest, I guess Erik was being a bit provocative when he gave that talk. From my very limited experience of how he explain topics, he tends to be playful. Keep in mind when I watched a presentation he gave about Reactive Programming, he actually advocated the opposite of this talk! (i.e. that it's best not to be fundamentalist, and take what works from each paradigm). My takeaway from all this is that some of the beauty and power of FP can only be discovered when you go "fundamentalist"; otherwise the temptation to use "escape hatches" and go the familiar route is too strong, and once you do that you miss alternative formulations/solutions of known problems. At least, this is my experience with Scala.

the_af 11y ago

Erik Meijer is making those sort of arguments, though he tends to change his mind frequently. I'm copying the conclusions of his talk "The Curse of the Excluded Middle" ( https://queue.acm.org/detail.cfm?id=2611829 https://queue.acm.org/detail.cfm?id=2611829 ), which is appropriately subtitled "'Mostly functional' programming does not work": "The idea of "mostly functional programming" is unfeasible. It is impossible to make imperative programming languages safer by only partially removing implicit side effects. Leaving one kind of effect is often enough to simulate the very effect you just tried to remove. On the other hand, allowing effects to be "forgotten" in a pure language also causes mayhem in its own way. Unfortunately, there is no golden middle, and we are faced with a classic dichotomy: the curse of the excluded middle, which presents the choice of either (a) trying to tame effects using purity annotations, yet fully embracing the fact that your code is still fundamentally effectful; or (b) fully embracing purity by making all effects explicit in the type system and being pragmatic by introducing nonfunctions such as unsafePerformIO. The examples shown here are meant to convince language designers and developers to jump through the mirror and start looking more seriously at fundamentalist functional programming."

pron 11y ago
I really don't like how some PFP proponents -- as Meijer does in that article -- make a leap from a correct premise to an unjustified conclusion. Even if we accept that unrestricted, unchecked, non-transactional mutation of shared state is a source of many bugs, it does not for one second follow that going fully referentially-transparent must be the only solution to ensure correctness. To me that argument sounds like, "wrist pain is a source of misery for many developers, hence we should chop off our arms and program using gestures with our tongue, which turns out to be a much more elegant solution" (I'm exaggerating, of course). It's as if provably verifiable, safe, imperative programming languages don't exist, and haven't been used to write safety-critical system for quite some time (actually, verifiable imperative languages have been used much more than PFP languages to develop such systems). Also, the appeal to lambda-calculus(/i) as a more "mathematical" approach to computation (as if that is a goal in itself) discounts the fact that LC -- even as a theoretical model -- has some serious drawbacks, such as the lack of a good model of computational complexity.
- the_af 11y ago
  In this case, I was merely pointing out that some practitioners and theorists are making "this kind of arguments". As for the rest, I guess Erik was being a bit provocative when he gave that talk. From my very limited experience of how he explain topics, he tends to be playful. Keep in mind when I watched a presentation he gave about Reactive Programming, he actually advocated the opposite of this talk! (i.e. that it's best not to be fundamentalist, and take what works from each paradigm). My takeaway from all this is that some of the beauty and power of FP can only be discovered when you go "fundamentalist"; otherwise the temptation to use "escape hatches" and go the familiar route is too strong, and once you do that you miss alternative formulations/solutions of known problems. At least, this is my experience with Scala.