5 ms·

In practice, most programming languages are not purely or even mostly functional. So why is everything on this list about functional programming?

by panic 11y ago

innguest 11y ago
Because 20 years ago everything on every list was about object-oriented programming and I didn't complain (too much).
- seanmcdirmid 11y ago
  PL theory has never been dominated by OOP, except for those theories specifically related to it. Just take a look at a POPL '95 proceedings. FP starts from math, for OO math had to be shoe horned into successful existing work that didn't care about it that much.
  - NotableAlamode 11y ago
    The semantics of OO languages is really messy and complicated and probably has the least well understood theory of all sequential forms of computing.
    - seanmcdirmid 11y ago
      Not just that, but we still don't really know how to combine subtyping and generics very well. The soundness question when considering variance is still quite open, and it shows in the poor support for type inference in OO languages (in spite of heroic efforts made in languages like Scala). Much of this has to do with the root: most of our PL theory was basically designed for FP, and applying them to OOP has been predictably difficult. Most PL theoreticians are more interested in FP than OOP, so progress is quite slow (though see work done by Ross Tate, Igarashi, etc...for progress).
      - NotableAlamode 11y ago
        soundness question when considering variance What is this question? Have you got a reference?
        AnimalMuppet 11y ago
        I'm not the one you were replying to, but maybe seanmcdirmid means this: https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29 https://en.wikipedia.org/wiki/Covariance_and_contravariance_... But I thought that was pretty well understood, so I don't know what he thinks is open...
        seanmcdirmid 11y ago
        For many popular type systems with generics, not really; e.g. see http://www.cs.cornell.edu/~ross/publications/mixedsite/mixed-site-tate-2013.pdf http://www.cs.cornell.edu/~ross/publications/mixedsite/mixed...
        deleted 11y ago
        [deleted]
        nrinaudo 11y ago
        It is possible that he's referring to mutable and covariant types being unsound. As an example, let's assume that you have two classes, Cat and Dog, both inheriting from Animal, and that you have a covariant mutable List implementation. Say you have a value of type List[Cat]. Since List is covariant, this value can legally be passed to a function that expects a parameter of type List[Animal]. Now, imagine you have a function that expects a List[Animal] and adds a Dog to it. That's a legal operation: Dog extends Animal and can thus be used this way. Putting the two together, you have a perfectly legal way of adding a Dog to a List[Cat], which a sound type system should not allow. An example of that is Java's Array, which is both covariant and mutable, and that as a result can yield type errors at runtime.
      - mafribe 11y ago
        I suspect that combining generics with subtyping might always lead you into the land on undecidable type-inference. After all, pure genericity (System F) is already undecidable.
exDM69 11y ago
Because imperative programming is not very interesting from a programming language theory point of view. If this was a list about compiler construction, it would look very different. As we're seeing more and more language features originating from functional programming trickle into mainstream languages, this research hasn't clearly gone to waste even though everyone is not programming in functional programming languages.
- mafribe 11y ago
  imperative programming is not very interesting from a programming language theory point of view. I'm afraid I disagree, the opposite is the case. Modern PL theory is mostly about program correctness, and that is much easier for pure functional languages. Until recently, nobody had a handle on program logics for imperative languages, or reasoning techniques for operational semantics. The only available reasoning techniques used to be based on denotational semantics, following Scott's breakthrough domain-theoretic semantics of lambda-calculus. That's why so much theory was developed in a functional programming context, because FP is in some ways much simpler than imperative or concurrent programming (even though compiling FP languages is harder). The available textbooks reflect this state of afairs. All that has changed in the last decade or so, but it will take another decade or so before recent research insights into non-functional languages perlocates down to accessible textbooks.
  - habitue 11y ago
    This is the real answer. The restrictions on functional languages that make them (perhaps) harder to use for everyday programming makes them much easier to reason about and prove properties of.
  - exDM69 11y ago
    Oh, I agree with this. "Interesting" was a poor choice of words. It's definitely interesting but then again, as you say this changed in the past decade or so. Getting introduced to a new topic by exploring the latest state of the art without going through the basic theory first isn't a good way to learn most subjects.
  - 11y ago
AnimalMuppet 11y ago
Note the word "enlightenment" in the title. Everything on the list is about functional programming languages because the author believes that, once you are enlightened, of course you're going to use functional programming languages. If you find that condescending and/or narrow-minded, you're not alone. There are more things in programming language theory than are dreamt of in their philosophy (to steal a line from Shakespeare).
sklogic 11y ago
In practice, most programming languages are compiled via SSA or even Array SSA, i.e., via a pure functional intermediate representation. And understanding it thoroughly is a huge advantage.

In practice, most programming languages are not purely or even mostly functional. So why is everything on this list about functional programming?

by panic 11y ago

In practice, most programming languages are not purely or even mostly functional. So why is everything on this list about functional programming?

innguest 11y ago

Because 20 years ago everything on every list was about object-oriented programming and I didn't complain (too much).

seanmcdirmid 11y ago
PL theory has never been dominated by OOP, except for those theories specifically related to it. Just take a look at a POPL '95 proceedings. FP starts from math, for OO math had to be shoe horned into successful existing work that didn't care about it that much.
- NotableAlamode 11y ago
  The semantics of OO languages is really messy and complicated and probably has the least well understood theory of all sequential forms of computing.
  - seanmcdirmid 11y ago
    Not just that, but we still don't really know how to combine subtyping and generics very well. The soundness question when considering variance is still quite open, and it shows in the poor support for type inference in OO languages (in spite of heroic efforts made in languages like Scala). Much of this has to do with the root: most of our PL theory was basically designed for FP, and applying them to OOP has been predictably difficult. Most PL theoreticians are more interested in FP than OOP, so progress is quite slow (though see work done by Ross Tate, Igarashi, etc...for progress).
    - NotableAlamode 11y ago
      soundness question when considering variance What is this question? Have you got a reference?
      - AnimalMuppet 11y ago
        I'm not the one you were replying to, but maybe seanmcdirmid means this: https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29 https://en.wikipedia.org/wiki/Covariance_and_contravariance_... But I thought that was pretty well understood, so I don't know what he thinks is open...
        seanmcdirmid 11y ago
        For many popular type systems with generics, not really; e.g. see http://www.cs.cornell.edu/~ross/publications/mixedsite/mixed-site-tate-2013.pdf http://www.cs.cornell.edu/~ross/publications/mixedsite/mixed...
        deleted 11y ago
        [deleted]
      - nrinaudo 11y ago
        It is possible that he's referring to mutable and covariant types being unsound. As an example, let's assume that you have two classes, Cat and Dog, both inheriting from Animal, and that you have a covariant mutable List implementation. Say you have a value of type List[Cat]. Since List is covariant, this value can legally be passed to a function that expects a parameter of type List[Animal]. Now, imagine you have a function that expects a List[Animal] and adds a Dog to it. That's a legal operation: Dog extends Animal and can thus be used this way. Putting the two together, you have a perfectly legal way of adding a Dog to a List[Cat], which a sound type system should not allow. An example of that is Java's Array, which is both covariant and mutable, and that as a result can yield type errors at runtime.
    - mafribe 11y ago
      I suspect that combining generics with subtyping might always lead you into the land on undecidable type-inference. After all, pure genericity (System F) is already undecidable.

exDM69 11y ago

Because imperative programming is not very interesting from a programming language theory point of view. If this was a list about compiler construction, it would look very different. As we're seeing more and more language features originating from functional programming trickle into mainstream languages, this research hasn't clearly gone to waste even though everyone is not programming in functional programming languages.

mafribe 11y ago
imperative programming is not very interesting from a programming language theory point of view. I'm afraid I disagree, the opposite is the case. Modern PL theory is mostly about program correctness, and that is much easier for pure functional languages. Until recently, nobody had a handle on program logics for imperative languages, or reasoning techniques for operational semantics. The only available reasoning techniques used to be based on denotational semantics, following Scott's breakthrough domain-theoretic semantics of lambda-calculus. That's why so much theory was developed in a functional programming context, because FP is in some ways much simpler than imperative or concurrent programming (even though compiling FP languages is harder). The available textbooks reflect this state of afairs. All that has changed in the last decade or so, but it will take another decade or so before recent research insights into non-functional languages perlocates down to accessible textbooks.
- habitue 11y ago
  This is the real answer. The restrictions on functional languages that make them (perhaps) harder to use for everyday programming makes them much easier to reason about and prove properties of.
- exDM69 11y ago
  Oh, I agree with this. "Interesting" was a poor choice of words. It's definitely interesting but then again, as you say this changed in the past decade or so. Getting introduced to a new topic by exploring the latest state of the art without going through the basic theory first isn't a good way to learn most subjects.
- 11y ago

AnimalMuppet 11y ago

Note the word "enlightenment" in the title. Everything on the list is about functional programming languages because the author believes that, once you are enlightened, of course you're going to use functional programming languages. If you find that condescending and/or narrow-minded, you're not alone. There are more things in programming language theory than are dreamt of in their philosophy (to steal a line from Shakespeare).

sklogic 11y ago

In practice, most programming languages are compiled via SSA or even Array SSA, i.e., via a pure functional intermediate representation. And understanding it thoroughly is a huge advantage.