Slashdot Mirror

← Back to Stories (view on slashdot.org)

Erik Meijer: The Curse of the Excluded Middle

Posted by samzenpus on from the almost-good-enough dept.

CowboyRobot (671517) writes "Erik Meijer, known for his contributions to Haskell, C#, Visual Basic, Hack, and LINQ, has an article at the ACM in which he argues that '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.'"

2 of 237 comments (clear)

  1. Re:Jump through the mirror? by Anonymous Coward · · Score: 5, Informative

    Nobody is trying to pretend that there are no side effects you idiots. The point is that there are a lot of benefits that come when you clearly separate the parts of the program that have side effects from those that are pure and referentially transparent.

    It's trivial to ask a user for input, send packets across the network, query a database in Haskell and various other purely functional programming languages.

  2. Re:Jump through the mirror? by Pseudonym · · Score: 5, Informative

    My impression of "pure" functional programming is that it's roughly like having only static classes and no static members in OOP.

    If you got that impression from TFA, then I can actually understand how you got it. Meijer's article was written for people already using not-fully-pure functional languages, where "class" means something slightly different than it does in a Simula-style OO language.

    The term "class" comes from von Neumann–Bernays–Gödel set theory. Naive set theory had issues like Russell's Paradox, which relies on notions like the "set of all sets". To remove this paradox, NBG set theory distinguishes between a "set" and a "class" (i.e. a collection of sets defined by a property they have in common). Some classes are sets, and some are not. A set is a collection of values, but a "class" is a collection of sets.

    In programming language theory, a "type" can be thought of as a set of values (e.g. "boolean" might be the set {true, false}). A "class" is a collection of types.

    When you write class Foo in (say) Java, you're actually doing three separate things.

    • You are declaring a new type, called Foo.
    • You are declaring a new collection of types (also confusingly called Foo), which will turn out to be the type Foo and all its subtypes.
    • You are declaring that the type Foo is a member of the collection Foo.

    In the Haskell class system, these three things are separated. This is why Haskell classes look more restrictive than classes that you might find in Java: a Haskell class only contains the parts that make it a class, not the parts that make it a type.

    Did that help?

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});