4 ms·

Higher-order functions are extremely constrained given that lambdas boil down to fixed interfaces, and there's very few tools for e.g. partial application and c

Higher-order functions are extremely constrained given that lambdas boil down to fixed interfaces, and there's very few tools for e.g. partial application and converting between function types. A lot of that is probably due to primitive variants and checked exceptions causing genericity to be extremely limited, so they capped the utility of lambdas in their design.

pjmlp 8y ago
What is relevant is that lambda calculus can be expressed. Everything else are just variations on "What is FP" and sugar coating.
- bunderbunder 8y ago
  > What is relevant is that lambda calculus can be expressed. That's a criterion that's so broad as to be almost meaningless, though. The lambda calculus can be expressed in any Turing-complete language. I wouldn't personally consider a language to support a paradigm unless programming in that paradigm feels natural in that language. Java supports using a few functional techniques. The experience of trying to write in a truly functional style, though, is painful.
  - pjmlp 8y ago
    Thing is, what does actually "The experience of trying to write in a truly functional style" mean in practice. FP Lisp/Scheme, FP ML, FP Haskell/Miranda, FP Idris, FP Scala, FP Kotlin, FP OCaml, FP ATS, FP .... ? All of them express different views of what Functional Programming is supposed to be like.
    - bunderbunder 8y ago
      True. But I think that you can generally break them down into a few broad categories of functional style, and none of them can be followed comfortably in Java.
      - pjmlp 8y ago
        Comfort is not a programming paradigm. Just because only might need a bit more boilerplate for currying or partial applications, doesn't prevent writing FP libraries in modern Java.
        deleted 8y ago
        [deleted]
        setr 8y ago
        But since its all turing complete... this can be said of anything. There’s nothing stopping you from doing OOP in haskell, or functional in C, or procedural in prolog, if you’re willing to put in the effort. Disregarding “comfort”, or rather, how much the language lends itself to a style, makes the notion of programming paradigms meaningless, and we’re still left with something we all know exists, but have no way to express.
        Jtsummers 8y ago
        Different programming paradigms are not about what can be computed it is about what can be expressed in the syntax and semantics of the language. This is an important distinction. Brainfuck is capable, technically, of computing anything that Haskell can compute. However, it would be foolish to call it a functional (paradigm-sense) language. It lacks higher order functions and many other elements. You could construct a lambda calculus interpreter in brainfuck, but then that language would be functional, but not the underlying implementation language. By the same measure, Haskell implemented in C does not make C a functional (paradigm-sense) language.
        bunderbunder 8y ago
        There's a whole lot of stuff you can do, short of writing interpreters, to construct library-level support for a paradigm in a language that lacks language-level support for that paradigm. For example, I would say that GTK+ is written in an object-oriented style. But, despite that, I would not say that OOP is a member of C's repertoire of language paradigms.

pjmlp 8y ago

What is relevant is that lambda calculus can be expressed. Everything else are just variations on "What is FP" and sugar coating.

bunderbunder 8y ago
> What is relevant is that lambda calculus can be expressed. That's a criterion that's so broad as to be almost meaningless, though. The lambda calculus can be expressed in any Turing-complete language. I wouldn't personally consider a language to support a paradigm unless programming in that paradigm feels natural in that language. Java supports using a few functional techniques. The experience of trying to write in a truly functional style, though, is painful.
- pjmlp 8y ago
  Thing is, what does actually "The experience of trying to write in a truly functional style" mean in practice. FP Lisp/Scheme, FP ML, FP Haskell/Miranda, FP Idris, FP Scala, FP Kotlin, FP OCaml, FP ATS, FP .... ? All of them express different views of what Functional Programming is supposed to be like.
  - bunderbunder 8y ago
    True. But I think that you can generally break them down into a few broad categories of functional style, and none of them can be followed comfortably in Java.
    - pjmlp 8y ago
      Comfort is not a programming paradigm. Just because only might need a bit more boilerplate for currying or partial applications, doesn't prevent writing FP libraries in modern Java.
      - deleted 8y ago
        [deleted]
      - setr 8y ago
        But since its all turing complete... this can be said of anything. There’s nothing stopping you from doing OOP in haskell, or functional in C, or procedural in prolog, if you’re willing to put in the effort. Disregarding “comfort”, or rather, how much the language lends itself to a style, makes the notion of programming paradigms meaningless, and we’re still left with something we all know exists, but have no way to express.
        Jtsummers 8y ago
        Different programming paradigms are not about what can be computed it is about what can be expressed in the syntax and semantics of the language. This is an important distinction. Brainfuck is capable, technically, of computing anything that Haskell can compute. However, it would be foolish to call it a functional (paradigm-sense) language. It lacks higher order functions and many other elements. You could construct a lambda calculus interpreter in brainfuck, but then that language would be functional, but not the underlying implementation language. By the same measure, Haskell implemented in C does not make C a functional (paradigm-sense) language.
        bunderbunder 8y ago
        There's a whole lot of stuff you can do, short of writing interpreters, to construct library-level support for a paradigm in a language that lacks language-level support for that paradigm. For example, I would say that GTK+ is written in an object-oriented style. But, despite that, I would not say that OOP is a member of C's repertoire of language paradigms.