Talk:Functional programming

Template:Vital article

Fixing the lede

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 versus pure functional in lede

The first sentence is

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.

This sounds like "pure functional programming" to me, rather than just "functional". I would say functional programming is a style where you compose functions to get results, as opposed to getting results via a step-by-step process. I would consider the following functional, though not pure functional (or a good idea).

def get_five_ints():
    return list(map(lambda _: int(input("Enter an integer: ")), range(5)))

"Functional" is a manner of abstraction, but "pure functional" gives the nice guarantees like referential transparency and lazy evaluation. --72.226.86.106 (talk) 02:37, 11 July 2015 (UTC)

The lede - as opposed to?

"so calling a function f twice with the same value for an argument x will produce the same result f(x) each time"

As opposed to all those other computer languages where calling f(x) produces different results each time for the same x? Perhaps there is an important idea there but if so it is pretty fucking badly expressed. Is it just that there are no global variables? If so, yawn. Greglocock (talk) 06:41, 24 April 2017 (UTC)

@Greglocock: I've tried to clarify, let me know if that's enough. It's not just about global variables, but having no state that is not captured in the arguments and return values. Diego (talk) 12:45, 24 April 2017 (UTC)

P.S. Technically you can have global variables in a pure functional language, as long as they're immutable. "Global" is a term describing the scope of a variable, not its changes in state. Having no state changes in any variable in the whole program is a rather strong requirement, which changes the programming paradigm significantly with respect to imperative programming. Diego (talk) 12:52, 24 April 2017 (UTC)

Thanks. So b=2*a is ok, but a=2*a is not? I can see that that is more robust in general, if a tad inconvenient for incrementing indices. Greglocock (talk) 00:31, 25 April 2017 (UTC)

Yes, that's pretty much the essence; destructive updates to named variables are not allowed. The typical way of "incrementing indices" is passing the increased value to a recursive call; functional programming depends heavily on recursion. Diego (talk) 06:16, 25 April 2017 (UTC)

@Greglocock: rand() will produce different results each time. scanner.nextInt() can produce new results each time. With a pure function, a compiler could theoretically decide that a result isn't used so the call is unneeded, or that a result is used a lot and it can be cached. A skipped call to rand() or scanner.nextInt() will affect the results of a program, while a skipped call to fibonacci(n) should not.

Most uses for incrementing indices are made unnecessary in functional programming languages. You would typically use a higher-order function like map, which roughly corresponds to the head of a for-loop, and give it another function, which roughly corresponds to the body of a for-loop. Many other languages have support for these concepts. C++'s <algorithm> library, Java's Stream interface, and Javascript's Array methods all have some kind of map/filter/reduce equivalent, which take a sequence and a function and return a transformed sequence or an aggregate value.

It is theoretically possible to allow updates to named variables within the body of a function, as long as the variables are local. The D programming language allows such updates in its pure functions.[1] --96.232.200.75 (talk) 20:20, 13 June 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Functional programming. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.aquabu.com/2008/02/16/fibonacci-sequence-recursion-in-erlang
• Added archive https://web.archive.org/web/20110629183752/http://www.mactech.com/articles/mactech/Vol.03/03.1/SchemeWindows/index.html to http://www.mactech.com/articles/mactech/Vol.03/03.1/SchemeWindows/index.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 22:04, 8 October 2017 (UTC)

Idempotent or injective?

Any thoughts on this?

"Removed the inaccurate use of idempotent. Having the same function output for a value x is injectivity, not idempotency. The article declared that calling f twice with the same value x produces f(x) each time. This is just a claim on uniqueness. This is equivalent to saying that: for x, y in D and function f: D -> co(D), that if f(x) = f(y), then x=y. This is precisely injectivity. If functional languages acted as f(f(x)) = f(x), then for any value x, a function of x would be identical to its..."

@2600:1009:B112:79C8:75D8:597D:23FC:A3A4: Andy Dingley (talk) 21:22, 15 April 2019 (UTC)

@Andy Dingley: it's neither. The article wants to say that if x f y and x f z, then y = z. That is, it satisfies the properties of functions in mathematics.

On the other hand:

• Idempotent means f(f(x)) = f(x).
• injective means if f(a) = f(b), then a = b. In the relational notation, if a f c and b f c, then a = b. Notice that this is in the other direction of the function properties I described above.

These two are irrelevent. So yes, this should be changed. --Nullzero (talk) 19:36, 9 September 2019 (UTC)

Coding Styles section mostly detracts

Coding styles are different opinionated approaches to the same problem. For example, the Haskell section of Coding Styles effectively illustrates different coding styles. Implementing the same code in different languages is not an example of different coding styles, as the different languages may use the same coding style.

Languages that only feature one coding style should be removed from this section (or have another coding style added), as they have nothing to compare/contrast and therefore only confuse and detract from the actually beneficial sections. — Preceding unsigned comment added by 64.141.80.20 (talk) 05:45, 3 June 2019 (UTC)

Agree. This section should be cleaned-up. No point in listing non-functional languages. Sure, any imperative language can have `fib(n) = fib(n-1) + fib(n-2)` defined, but that's not the point, or else this list will grow indefinitely. bungalo (talk) 22:19, 27 November 2019 (UTC)

Would anyone mind if I add an example for R?

Functional Programming is such a core aspect of R and how R is different. I read this article and thought it was a little sad that there was not example for R. Can I add one? The simple example would be this:

fibonacci <- function(n){ 
x = numeric(n)
x[1:2] = c(1,1)
for(i in 3:n)
x[i] = x[i-1] + x[i-2]
return(x)}

fibonacci(10)

As the syntax implies there is no non-functional version of the basic function in R. R simply assumes.

Historically R as Hadley writes in advance R (https://adv-r.hadley.nz/), R actually started out as a pure functional programming that by the necessity of statistics became impure in order to add objects and classes that were mutable. mlane --2600:1700:F840:1E40:6DE5:E5C1:F398:6CCC (talk) 22:22, 7 June 2019 (UTC)