6 ms·

Am I the only one who finds the goalposts gave moved for FP? it used to be lambdas/lexical closures that were the big must-have FP feature, then it was immutab

by Pxtl 12y ago

Am I the only one who finds the goalposts gave moved for FP? it used to be lambdas/lexical closures that were the big must-have FP feature, then it was immutability. Now that we're seeing traditionally-OO languages sport a raft of immutable types and good support for lexical closures, now it's all about higher-kinded-types. For a while, the big feature was homoiconicity and tail-call-optimization until lisp fell out of favour with language geeks. Does FP just mean "has features of my favorite self-proclaimed-functional-language"?

tel 12y ago
FP isn't a technical definition—it's a social phenomenon. As soon as you see it that way you'll never be confused by the use of the term again.
- tracker1 12y ago
  I've just tried not to be dogmatic about it... You can use a functional style without relying on immutable types or tail call optimization. I think it comes down more to a personal style... we tend to conflate programming to engineering, which it rarely is. More often it is a craft discipline. It's more style, taste and personal preference. That said, when you have to grow something past a few million users a day, or start to hit C10K/C10M barriers. Even then, there are ways to do that... to break up the load.
Denommus 12y ago
Functional Programming is just composing a program with pure functions, nothing else. Immutability and closures are required for that, because mutability may break homoiconicity (which is required for purity), and lack of closures means you can't pass state around. Higher-kinded types are very useful for helping with lots of functional abstractions, but they are a type system feature and have nothing to do with FP. If someone claims that, this person doesn't understand FP or type systems. OCaml and Standard ML are two examples of languages without higher kinded types but are just as good as Haskell for FP. (Although they have a powerful module system to compensate for that).
- the_af 12y ago
  > because mutability may break homoiconicity (which is required for purity) Are you sure you meant that? My (admittedly weak) understanding of homoiconicity is that it's unrelated to either purity or (im)mutability. Isn't homoiconicity related to the program text and its AST? Aren't there languages such as Haskell which encourage pure functions but are not homoiconic? I'm pretty sure you meant something else...
  - abathologist 12y ago
    I bet "referentiality" was meant. It would make sense as a replacement for "homoiconicity".
    - abathologist 12y ago
      I bet "referential transparency" was meant. It would make sense as a replacement for "referentiality". oops :(
    - Denommus 12y ago
      Yes, that's what I meant, I don't know why I got it wrong.
- abathologist 12y ago
  > they are a type system feature and have nothing to do with FP I suggested in a sibling reply that the use of type-theoretic notions in FP is a natural out growth of the initial motives of the FP paradigm. While I wouldn't think that FP languages must incorporate type-theoretic notions, it does seem to me fitting that many would, since type systems have been involved with the functional understanding of computation since quite early on. Do think that line of reasoning make sense?
- dragonwriter 12y ago
  Mutability directly breaks purity whether or not it breaks homoiconicity. This should be obvious because on of the best known and oldest FP language families is both homoiconic and impure due to mutation (the Lisp family.) So homoiconicity is a non-sequitur.
abathologist 12y ago
I'm not an expert or professional, but I'll offer some few cents here. I think your feeling that the "goalposts have moved" is a result of mistaking 'Functional Programing' as the name for a set of language features. Instead, I understand FP to designate a far reaching paradigm encompassing language design, computer science research, and the design and development of particular programs. As I understand it, the initial motive for FP was the development of an elegant, mathematically grounded programming style in which the human readable forms of expression neatly reflect the underlying computational model. This is evident in John McCarthy's 1962 "A basis for a mathematical theory of computation"[0], where he presents > a formalism based on conditionals forms and recursive functions whereby the functions computable in terms of certain base functions can be simply expressed. The same principles seem to persist right through to the current wikipedia article on FP: > 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. Of course, over the course of 50+ years of ongoing research into FP, and roughly 80 years of research into the functional expression of mathematical foundations, there have been lots of developments and plenty of emergent insights that have altered the reigning implementations of FP languages. The fact that OO languages can keep incorporating features that emerge in FP languages is simply a testament to the fertility of the paradigm. The advent of type-theoretic constructs (like higher-kinded-types) in FP is directly related to the central motives and inspirations of FP. It continues to draw inspiration from developments in maths. Contemporary FP incorporating ideas from type-theory is just like LISP incorporating ideas form the lambda calculus. Since both FP is an ongoing research and design paradigm, the features and approaches associated with it continue to develop. And unless the implementation of FP languages ever overtakes the ongoing research into functional foundations of mathematics, FP will continue to incorporate findings that emerge in the latter. I may be mistaken, but I don't believe homoiconicity was ever a central feature of the FP paradigm. And, as you note, is is only associated with FP because LISPs were the paradigmatic FP language for so long. But homoiconicity is always a feature of the primordial OO and LP languages, SmallTalk and Prolog. [0] - http://dspace.mit.edu/bitstream/handle/1721.1/6099/AIM-031.pdf?sequence=2 http://dspace.mit.edu/bitstream/handle/1721.1/6099/AIM-031.p...
- 12y ago

by Pxtl 12y ago

tel 12y ago

FP isn't a technical definition—it's a social phenomenon. As soon as you see it that way you'll never be confused by the use of the term again.

tracker1 12y ago
I've just tried not to be dogmatic about it... You can use a functional style without relying on immutable types or tail call optimization. I think it comes down more to a personal style... we tend to conflate programming to engineering, which it rarely is. More often it is a craft discipline. It's more style, taste and personal preference. That said, when you have to grow something past a few million users a day, or start to hit C10K/C10M barriers. Even then, there are ways to do that... to break up the load.

Denommus 12y ago

Functional Programming is just composing a program with pure functions, nothing else. Immutability and closures are required for that, because mutability may break homoiconicity (which is required for purity), and lack of closures means you can't pass state around. Higher-kinded types are very useful for helping with lots of functional abstractions, but they are a type system feature and have nothing to do with FP. If someone claims that, this person doesn't understand FP or type systems. OCaml and Standard ML are two examples of languages without higher kinded types but are just as good as Haskell for FP. (Although they have a powerful module system to compensate for that).

the_af 12y ago
> because mutability may break homoiconicity (which is required for purity) Are you sure you meant that? My (admittedly weak) understanding of homoiconicity is that it's unrelated to either purity or (im)mutability. Isn't homoiconicity related to the program text and its AST? Aren't there languages such as Haskell which encourage pure functions but are not homoiconic? I'm pretty sure you meant something else...
- abathologist 12y ago
  I bet "referentiality" was meant. It would make sense as a replacement for "homoiconicity".
  - abathologist 12y ago
    I bet "referential transparency" was meant. It would make sense as a replacement for "referentiality". oops :(
  - Denommus 12y ago
    Yes, that's what I meant, I don't know why I got it wrong.
abathologist 12y ago
> they are a type system feature and have nothing to do with FP I suggested in a sibling reply that the use of type-theoretic notions in FP is a natural out growth of the initial motives of the FP paradigm. While I wouldn't think that FP languages must incorporate type-theoretic notions, it does seem to me fitting that many would, since type systems have been involved with the functional understanding of computation since quite early on. Do think that line of reasoning make sense?
dragonwriter 12y ago
Mutability directly breaks purity whether or not it breaks homoiconicity. This should be obvious because on of the best known and oldest FP language families is both homoiconic and impure due to mutation (the Lisp family.) So homoiconicity is a non-sequitur.

abathologist 12y ago

I'm not an expert or professional, but I'll offer some few cents here. I think your feeling that the "goalposts have moved" is a result of mistaking 'Functional Programing' as the name for a set of language features. Instead, I understand FP to designate a far reaching paradigm encompassing language design, computer science research, and the design and development of particular programs. As I understand it, the initial motive for FP was the development of an elegant, mathematically grounded programming style in which the human readable forms of expression neatly reflect the underlying computational model. This is evident in John McCarthy's 1962 "A basis for a mathematical theory of computation"[0], where he presents > a formalism based on conditionals forms and recursive functions whereby the functions computable in terms of certain base functions can be simply expressed. The same principles seem to persist right through to the current wikipedia article on FP: > 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. Of course, over the course of 50+ years of ongoing research into FP, and roughly 80 years of research into the functional expression of mathematical foundations, there have been lots of developments and plenty of emergent insights that have altered the reigning implementations of FP languages. The fact that OO languages can keep incorporating features that emerge in FP languages is simply a testament to the fertility of the paradigm. The advent of type-theoretic constructs (like higher-kinded-types) in FP is directly related to the central motives and inspirations of FP. It continues to draw inspiration from developments in maths. Contemporary FP incorporating ideas from type-theory is just like LISP incorporating ideas form the lambda calculus. Since both FP is an ongoing research and design paradigm, the features and approaches associated with it continue to develop. And unless the implementation of FP languages ever overtakes the ongoing research into functional foundations of mathematics, FP will continue to incorporate findings that emerge in the latter. I may be mistaken, but I don't believe homoiconicity was ever a central feature of the FP paradigm. And, as you note, is is only associated with FP because LISPs were the paradigmatic FP language for so long. But homoiconicity is always a feature of the primordial OO and LP languages, SmallTalk and Prolog. [0] - http://dspace.mit.edu/bitstream/handle/1721.1/6099/AIM-031.pdf?sequence=2 http://dspace.mit.edu/bitstream/handle/1721.1/6099/AIM-031.p...

12y ago