4 ms·

Wiki sums up the term well enough: "In computer science, functional programming is a programming paradigm — a style of building the structure and elements of c

Wiki sums up the term well enough: "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." To that end map-reduce fits and can be referred to as 'functional programming'. The other things you mention are just great language features, but not specific to functional languages. Imperative C++ also has type safety, Swift has non-null types, etc.

seanwilson 9y ago
> The other things you mention are just great language features, but not specific to functional languages. Imperative C++ also has type safety, Swift has non-null types, etc. All those features in combination are shared by the vast majority of languages called functional programming languages. They're pretty much the defining features of functional languages was my point. Other languages can have a subset of the features but it doesn't make them functional languages. See: https://wiki.haskell.org/Functional_programming https://wiki.haskell.org/Functional_programming The Wikipedia quote is really vague.
- hacker_9 9y ago
  > and expected of functional languages Clojure uses dynamic typing, yet it is still considered a functional language. I agree though that the combination of features results in a better experience when using functional primitives, but not having them doesn't mean this isn't functional programming still.
- dahart 9y ago
  None of pattern matching, algebraic data types, strong typing, type inference and types that can't be null are specific to functional, nor do they make it any more functional. Purity isn't a language feature, it's a measure of how functional a language is, so it's tautological to say functional languages share purity. Currying is a byproduct of first class functions, not of functional programming, and currying is common in JavaScript and Python and other non-functional languages including C++. Forced recursion instead of loops would just be a byproduct of not having mutable state. And a good alternative to a recursive loop is a call to map() or reduce(). > The Wikipedia quote is really vague. I think the Wikipedia quote is clearer and FAR more precise than a common feature set. Functional programming "treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data." That is the definition of functional, and it's the whole definition. No mutation, that's it. Including the features you wrote about is not functional programming, it's other things. That's important to consider the precise definition if you're going to critique someone for talking about functional programming in a certain way. The author was pretty clear that this is functional programming concepts as applied to arrays in JavaScript, he never claimed that this post covers functional programming in general. Map, filter & reduce are examples of functional programming, and if they were all you used, and you had only const and no var, then you might have a functional program. @zabana didn't claim that this is all you'll ever need.
  - seanwilson 9y ago
    > Functional programming "treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data." That is the definition of functional, and it's the whole definition. No mutation, that's it. Including the features you wrote about is not functional programming, it's other things. Are you meaning that "no mutation" is the definition of functional programming? That's such a vague definition I can't see how it is useful personally. "Stateless" is already a word that covers that. If you're going to quote Wikipedia, keep going to the "Concepts" section that lists language features: "A number of concepts and paradigms are specific to functional programming, and generally foreign to imperative programming (including object-oriented programming). However, programming languages are often hybrids of several programming paradigms, so programmers using "mostly imperative" languages may have utilized some of these concepts.[40]" > The author was pretty clear that this is functional programming concepts as applied to arrays in JavaScript, he never claimed that this post covers functional programming in general. I even said I accept it's common usage of the phrase and I was just wondering why that was.
    - dahart 9y ago
      > Are you meaning that "no mutation" is the definition of functional programming? You can see that I was intentionally summarizing wikipedia's definition in one word to make my point more clear that functional does not mean type inference or currying, right? > That's such a vague definition I can't see how it is useful personally. "Stateless" is already a word that covers that. Since I'm not offering "immutable" as the complete and final definition for functional programming, maybe you can find a better one to make your original point clear? Because the list of features you offered as defining functional programming doesn't define functional programming very well. IMO, the entire first paragraph of Wikipedia's article on functional programming is pretty good. It repeats the concept of immutability in a bunch of different ways with clarifying examples, to make it more concrete and less vague. I don't personally like "stateless" because it's not strictly true. Functional programs have state, and the state is contained in the stack. The point of functional programming is that the language avoids side effects, and the most direct word for something that avoids side effects is "immutable", not "stateless". I can accept that common usage of stateless is sometimes referring to immutability. Note that WP's definition of "state" agrees with that, and talks about declarative state being indirect, as opposed to being stateless: "In declarative programming languages, the program describes the desired results and doesn't specify changes to the state directly." https://en.wikipedia.org/wiki/State_(computer_science) https://en.wikipedia.org/wiki/State_(computer_science) > I even said I accept it's common usage of the phrase and I was just wondering why that was. Because it's true and meets the definition? Your objection is too vague. What, exactly, is wrong with calling map/filter/reduce "functional"? In my book, referring to map as an example of functional programming doesn't stretch the strict definition of functional programming at all. map() and reduce() were some of the very first things I learned about when I was introduced to the concept of functional programming in Scheme, more than 20 years ago. The post didn't claim that map, filter & reduce were 'enough for code to be called "functional programming"'. He only ever implied that map, filter & reduce are part of functional programming. That is absolutely true, always has been, and isn't a matter of common usage.
bryanrasmussen 9y ago
they can be referred to as techniques often found in functional programming, techniques that can obviously be used in non-functional manners.

seanwilson 9y ago

> The other things you mention are just great language features, but not specific to functional languages. Imperative C++ also has type safety, Swift has non-null types, etc. All those features in combination are shared by the vast majority of languages called functional programming languages. They're pretty much the defining features of functional languages was my point. Other languages can have a subset of the features but it doesn't make them functional languages. See: https://wiki.haskell.org/Functional_programming https://wiki.haskell.org/Functional_programming The Wikipedia quote is really vague.

hacker_9 9y ago
> and expected of functional languages Clojure uses dynamic typing, yet it is still considered a functional language. I agree though that the combination of features results in a better experience when using functional primitives, but not having them doesn't mean this isn't functional programming still.
dahart 9y ago
None of pattern matching, algebraic data types, strong typing, type inference and types that can't be null are specific to functional, nor do they make it any more functional. Purity isn't a language feature, it's a measure of how functional a language is, so it's tautological to say functional languages share purity. Currying is a byproduct of first class functions, not of functional programming, and currying is common in JavaScript and Python and other non-functional languages including C++. Forced recursion instead of loops would just be a byproduct of not having mutable state. And a good alternative to a recursive loop is a call to map() or reduce(). > The Wikipedia quote is really vague. I think the Wikipedia quote is clearer and FAR more precise than a common feature set. Functional programming "treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data." That is the definition of functional, and it's the whole definition. No mutation, that's it. Including the features you wrote about is not functional programming, it's other things. That's important to consider the precise definition if you're going to critique someone for talking about functional programming in a certain way. The author was pretty clear that this is functional programming concepts as applied to arrays in JavaScript, he never claimed that this post covers functional programming in general. Map, filter & reduce are examples of functional programming, and if they were all you used, and you had only const and no var, then you might have a functional program. @zabana didn't claim that this is all you'll ever need.
- seanwilson 9y ago
  > Functional programming "treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data." That is the definition of functional, and it's the whole definition. No mutation, that's it. Including the features you wrote about is not functional programming, it's other things. Are you meaning that "no mutation" is the definition of functional programming? That's such a vague definition I can't see how it is useful personally. "Stateless" is already a word that covers that. If you're going to quote Wikipedia, keep going to the "Concepts" section that lists language features: "A number of concepts and paradigms are specific to functional programming, and generally foreign to imperative programming (including object-oriented programming). However, programming languages are often hybrids of several programming paradigms, so programmers using "mostly imperative" languages may have utilized some of these concepts.[40]" > The author was pretty clear that this is functional programming concepts as applied to arrays in JavaScript, he never claimed that this post covers functional programming in general. I even said I accept it's common usage of the phrase and I was just wondering why that was.
  - dahart 9y ago
    > Are you meaning that "no mutation" is the definition of functional programming? You can see that I was intentionally summarizing wikipedia's definition in one word to make my point more clear that functional does not mean type inference or currying, right? > That's such a vague definition I can't see how it is useful personally. "Stateless" is already a word that covers that. Since I'm not offering "immutable" as the complete and final definition for functional programming, maybe you can find a better one to make your original point clear? Because the list of features you offered as defining functional programming doesn't define functional programming very well. IMO, the entire first paragraph of Wikipedia's article on functional programming is pretty good. It repeats the concept of immutability in a bunch of different ways with clarifying examples, to make it more concrete and less vague. I don't personally like "stateless" because it's not strictly true. Functional programs have state, and the state is contained in the stack. The point of functional programming is that the language avoids side effects, and the most direct word for something that avoids side effects is "immutable", not "stateless". I can accept that common usage of stateless is sometimes referring to immutability. Note that WP's definition of "state" agrees with that, and talks about declarative state being indirect, as opposed to being stateless: "In declarative programming languages, the program describes the desired results and doesn't specify changes to the state directly." https://en.wikipedia.org/wiki/State_(computer_science) https://en.wikipedia.org/wiki/State_(computer_science) > I even said I accept it's common usage of the phrase and I was just wondering why that was. Because it's true and meets the definition? Your objection is too vague. What, exactly, is wrong with calling map/filter/reduce "functional"? In my book, referring to map as an example of functional programming doesn't stretch the strict definition of functional programming at all. map() and reduce() were some of the very first things I learned about when I was introduced to the concept of functional programming in Scheme, more than 20 years ago. The post didn't claim that map, filter & reduce were 'enough for code to be called "functional programming"'. He only ever implied that map, filter & reduce are part of functional programming. That is absolutely true, always has been, and isn't a matter of common usage.

bryanrasmussen 9y ago

they can be referred to as techniques often found in functional programming, techniques that can obviously be used in non-functional manners.