5 ms·

What definition of FP are you using? Because if it's just first-class functions, even Visual Basic has this now.

dmitriid 9y ago
Exactly. Let's take Wikipedia: -- start quote -- In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements. In functional code, the output value of a function depends only on the arguments that are passed to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) each time -- end quote --
- willtim 9y ago
  Only Haskell strictly conforms to that definition. None of your other examples do.
  - dmitriid 9y ago
    No. It only means that other languages support multiple paradigms. Haskell doesn't strictly conform either, because it allows side effects (event though it's "only through escape hatches"). There's no such thing as a "pure functional programming language". Let's take it from the top: "In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data." All of the languages I listed support this style. The moment you write an IO monad inside a function in Haskell, you break the illusion of Haskell's strict conformation to the definition.
    - willtim 9y ago
      Now you have the condescending tone! However, it appears you don't understand the IO monad. Programming using the IO monad is pure functional programming with full referential transparency. Please read Phil Wadler's paper, you will not understand this from that JavaScript snippet. The only backdoors are escape hatches like unsafePerformIO which are used for low-level libraries and FFI, they can be disabled with pragmas and/or compiler switches. It is much harder to stay true to that definition using the other languages, multi-paradigm or not. That is why Haskell is so often mentioned in the context of FP.
      - dmitriid 9y ago
        As soon as you have side-effects (an IO is a side-effect) you can through your assumptions about "strict conformation to definition" out of the window: --- treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. --- > It is much harder to stay true to that definition using the other languages, multi-paradigm or not. I doesn't matter if it's "hard". Your argument was that "Only Haskell strictly conforms to that definition." No. Haskell conforms stricter. It doesn't mean that none of the other languages are not FP, or cannot be used to program in functional style. > That is why Haskell is so often mentioned in the context of FP. Yes. And the problem is that people treat the features that Haskell has as requirements to be considered a functional programming language. - Typeclasses/Liquid types/Dependent types are not FP - Pattern matching is not FP - Laziness is not FP - A whole bunch of anything else is not FP
        willtim 9y ago
        > As soon as you have side-effects (an IO is a side-effect) you can through your assumptions about "strict conformation to definition" out of the window Again, you are unfortunately quite wrong. You do not understand the IO Monad. No IO is ever performed in any code written inside the IO monad (unless using unsafePerformIO). Please take some time to fully understand Haskell before criticising it so openly on a public forum. Perhaps then it might not all seem rather pointless.

Exactly. Let's take Wikipedia: -- start quote -- In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements. In functional code, the output value of a function depends only on the arguments that are passed to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) each time -- end quote --

willtim 9y ago
Only Haskell strictly conforms to that definition. None of your other examples do.
- dmitriid 9y ago
  No. It only means that other languages support multiple paradigms. Haskell doesn't strictly conform either, because it allows side effects (event though it's "only through escape hatches"). There's no such thing as a "pure functional programming language". Let's take it from the top: "In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data." All of the languages I listed support this style. The moment you write an IO monad inside a function in Haskell, you break the illusion of Haskell's strict conformation to the definition.
  - willtim 9y ago
    Now you have the condescending tone! However, it appears you don't understand the IO monad. Programming using the IO monad is pure functional programming with full referential transparency. Please read Phil Wadler's paper, you will not understand this from that JavaScript snippet. The only backdoors are escape hatches like unsafePerformIO which are used for low-level libraries and FFI, they can be disabled with pragmas and/or compiler switches. It is much harder to stay true to that definition using the other languages, multi-paradigm or not. That is why Haskell is so often mentioned in the context of FP.
    - dmitriid 9y ago
      As soon as you have side-effects (an IO is a side-effect) you can through your assumptions about "strict conformation to definition" out of the window: --- treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. --- > It is much harder to stay true to that definition using the other languages, multi-paradigm or not. I doesn't matter if it's "hard". Your argument was that "Only Haskell strictly conforms to that definition." No. Haskell conforms stricter. It doesn't mean that none of the other languages are not FP, or cannot be used to program in functional style. > That is why Haskell is so often mentioned in the context of FP. Yes. And the problem is that people treat the features that Haskell has as requirements to be considered a functional programming language. - Typeclasses/Liquid types/Dependent types are not FP - Pattern matching is not FP - Laziness is not FP - A whole bunch of anything else is not FP
      - willtim 9y ago
        > As soon as you have side-effects (an IO is a side-effect) you can through your assumptions about "strict conformation to definition" out of the window Again, you are unfortunately quite wrong. You do not understand the IO Monad. No IO is ever performed in any code written inside the IO monad (unless using unsafePerformIO). Please take some time to fully understand Haskell before criticising it so openly on a public forum. Perhaps then it might not all seem rather pointless.