Talk:Functional programming

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Former good article Functional programming was one of the Engineering and technology good articles, but it has been removed from the list. There are suggestions below for improving the article to meet the good article criteria. Once these issues have been addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake.
          This article is of interest to the following WikiProjects:
WikiProject Spoken Wikipedia
WikiProject icon This article is within the scope of WikiProject Spoken Wikipedia, a collaborative effort to improve the coverage of articles that are spoken on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
WikiProject Computing (Rated C-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
WikiProject Computer science (Rated C-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.

In 'Coding Styles' section - the lisp example is for *factorial* NOT *fibbonacci* (it ought to be for fibbonacci)[edit]

Can someone give the lisp code for Fibbonacci please? — Preceding unsigned comment added by Lastoftheoldcontemptibles (talkcontribs) 08:59, 28 May 2012 (UTC)

I'm having trouble saving the edit, but the code looks like this:

(defun fib (n &optional (a 0) (b 1))
  (if (= n 0)
    (fib (- n 1) b (+ a b)))) (talk) 10:46, 27 October 2012 (UTC)

I added the above Lisp code but I'm thinking of removing most or all of those Fibonacci examples (they might be better placed in the separate articles about the individual languages). The SML one in particular is bad, since it uses a double recursion (exponential time). If it stays, somebody should at least fix that problem. As an alternative to Fibonacci, it might be useful to show how to convert a direct recursive version of factorial, to a tail-recursive version using a helper function. (talk) 20:12, 4 November 2012 (UTC)

SML Fibonacci removed[edit]

I removed the SML example for the reason described above. I don't want to try rewriting it without first installing SML on my computer to test the rewrite, and I don't feel like doing that. But I didn't want to leave the existing wording in place, since it gave a wrong impression that SML was somehow unusually capable of directly expressing the mathematical definition of the function. Of course all the other languages could have done it the same way, at the same performance cost. (talk) 00:54, 6 November 2012 (UTC)

Strategy pattern mis-charactersiation[edit]

"for example, the strategy pattern simply dictates use of a higher-order function"

This is incorrect. A strategy interface could have two methods on it, which would require two higher order functions. — Preceding unsigned comment added by (talk) 09:27, 29 January 2013 (UTC)

Fixing the lede[edit]

I've reverted Ruud Koot's lede, as it's against WP:JARGON and WP:TECHNICAL, which requires us to provide a description that can be understood by anyone. If the current English intro contains bad English grammar, then let's work in fixing the grammar, but the article still should start with a description that uses layman terms. The more technical description can also be provided right afterwards, for increased precision.

Can you please exactly identify what are the problems with the current wording? Diego Moya (talk) 19:52, 11 August 2013 (UTC)

"a style of building the structure and elements computer programs" isn't grammatically correct English, nor is "not in the program's state". It is not possible to begin discussing the semantics of a piece of writing if it doesn't even begin to be syntactically correct. Exactingly what do you think is wrong with the original lede? —Ruud 21:41, 11 August 2013 (UTC)
It requires the reader to already understand the concepts of "programming paradigm", "computaton", "evaluation" and "application of functions", "state", "mutable data" and "lambda calculus" in order to begin making sense of the definition. The new definition states earlier the main practical aspect of FP, that functions always return the same value given the same input; this follows the advice to write one level down, providing a definition based on concrete and simple concepts instead of complex abstractions. Diego Moya (talk) 06:27, 12 August 2013 (UTC)
I very much prefer Ruud Koot's lede to the current one. It's much more clearly written, and gives a more informative overview of the topic. Functional programming is a programming paradigm, so I don't understand the aversion to mentioning that in the lead sentence (and I don't see the need for a definition like "a style of building the structure and elements of computer programs" which is so vague that it is useless). If a user can't understand what computation or evaluation of a function is, they are not going to be able to understand what functional programming is, no matter how much you dumb down or oversimplify the lead. It's good to avoid unnecessary jargon, but some subjects simply require the reader to have some prerequisite knowledge. For instance, the article manifold doesn't try to target itself towards users who have no idea what a topological space or neighborhood is -- you just can't talk about the subject without bringing these up. Likewise, you cannot accurately talk about functional programming without discussing evaluation, program state, or the lambda calculus. Anyhow, I support reverting back to Ruud Koot's version, and making whatever improvements you want to that, rather than trying to fix the current one. -- Mesoderm (talk) 08:14, 12 August 2013 (UTC)
It's a matter of style (and the current lede includes the term "programming paradigm", so I don't understand where you see any aversion to mentioning it). Nobody is suggesting removing those terms for precision, it's just that there's no need to have them in the first sentence. Other topics that are not functional programming deal with computation, lambda calculus and evaluation, so those are not definitory of FP; but using functions that always return the same result to build programs is unique to this paradigm, so it's a good definition. (And no, I don't think that FP is an essentially complex subject nor that it requires understanding lambda calculus to grasp it). Diego Moya (talk) 13:17, 12 August 2013 (UTC)
I'm sorry, I misspoke -- I didn't intend to say that you had an aversion to including programming paradigm in the first sentence - I meant an aversion to including it with just a wikilink without the (oversimplified/incorrect) definition. Anyhow, I don't want to argue about this either, but I don't think it's just "a matter of style". I think in this case, it's also a matter of being incorrect, oversimplified, and less readable. But now that I've made my view clear on this, I'll let other editors decide what to do about it. -- Mesoderm (talk) 18:55, 12 August 2013 (UTC)
My holiday is over and I'm not planning to spent much time on pointless arguing over over lede sections the comming months, so I'll keep it brief:
  1. "building the structure and elements of computer programs" is a vague and confusingly worded synonym for "computer programming". Saying that "functional programming is a style of computer programming" carries the exact same information, except that is can be understood instead of misunderstood.
  2. "based on pure functions that produce results that depend only on their inputs and not on the program state":
    • "based on" is one of those ambiguous phrases that should be avoided. As not all functional programming is done purely, "emphasizes" would probably be a more appropriate choice. A verbal noun is missing in this sentence, it should probably be "evaluation".
    • I would say that "pure function" is unnecessary jargon here, one should only have to be thinking about functions in the mathematical sense of the word.
    • "and not on the program state": Depending on how you define program state, this is not even correct. It is mutable state that is avoided in functional programming. But talking about mutable state only makes sense when you are thinking about imperative languages (which wouldn't be an unreasonable assumption to make for most readers, however): an explicit contrast with imperative languages needs to be made, like the previous lede did.
  3. "It is a declarative programming paradigm, which means programming is done with expressions and uses no implicit state.": "Done with" is, again, too vague. This is, as currently phrased, not even an accepted definition of declarative programming. "Used no implicit state" duplicates the previous sentence.
  4. "In functional code," More duplication of what has already been said (although, arguably, this time it is stated more clearly.)
  5. "Eliminating side effects..." Where do these "side effects" suddenly come from? As an expert I know that having functions depend on mutable state is a from of side effect, but we haven't even introduced mutable side effects yet. Any poor PHP programming is going to be hopelessly lost by now.
It would be more effective to improve the previous lede—there certain is much room for improvement there as well—than to continue with this trainwreck: it is even less accessible to layman than the previous lede. —Ruud 17:35, 12 August 2013 (UTC)

Functional programming in non-functional languages[edit]

The elephant in the room is javascript. Readers of this article are most likely using a client with an embedded javascript engine... Javascript/ECMAScript should be at the top of the list of non-functional languages having "functional features". — Preceding unsigned comment added by Kwagmire (talkcontribs) 23:02, 27 July 2014 (UTC)

author bias[edit]

this article is written with a clear bias by the author. — Preceding unsigned comment added by (talk) 20:34, 20 August 2014 (UTC)