Talk:Functional programming

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: 18 January 2022).

• 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)

I agree. I do not think that including these examples provide much value at all; there is already an example of imperative vs. functional programming at the top of the section. I don't even think the Haskell part should remain: I don't think that showing different coding styles is particularly relevant to an understanding of FP, and something like that would be better suited for a Haskell tutorial rather than an encyclopaedia article. I would like to remove the entire "Coding Styles" subsection if there are no objections. Quuxbazbarfoo (talk) 21:43, 28 April 2020 (UTC)

Agreed. It provides no value at all. As it currently exists, it simply encourages people to add their own favorite languages to the list. I will remove the section. --Nullzero (talk) 21:57, 28 April 2020 (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)

Criticism section

> Functional programming is also key to some languages that have found success in specific domains, like JavaScript in the Web.

This is rather opinionated and poorly reflected in the current state of the art in Javscript. Javascript tends to be massively used as OOP and not functional despite some trends going on. \\ — Preceding unsigned comment added by 2A01:E0A:5D3:2650:51F0:F3D2:7D33:13D8 (talk) 11:19, 21 November 2021 (UTC)

I've reverted the criticism section for now. I think a criticism section certainly is a good idea, but I don't really understand any of the points in the current one, and it doesn't have any references. If anyone can provide clarification or references for these points that would be much appreciated (@35.137.225.220:).

> it does not really allow the developer to build and manipulate "categories" as first class objects.

Is this really a bad thing? I don't think FP is advertised as a setting for *doing* category theory, it merely uses concepts from category theory.

>Note that a "category" is just a computation graph (not unlike TensorFlow).

Not sure what this means; categories are very general and abstract, they don't encode any specific form of computation. I don't know much about TensorFlow and have just done a very brief search on computation graphs, but I don't see the connection here. If there's a source I'd be interested in reading it.

> "internal" computation graph called the Kleisli category

Also not sure what this means. Kleisli categories are another abstract concept, not tied to computation graphs.

> Developers insert their code into the Kleisli category via monads

Monads have lots of uses in FP, but they're definitely not required, even for pure FP (AFAIK before monads were used in FP, Haskell programs were basically pure functions with inputs/outputs being lists of strings/events). Is this referring to doing impure computation in something like the IO monad?

> (basically 'proxies')

What kind of proxies are these?

> notoriously arcane math terminology.

Complex terminology is certainly a common criticism of FP (especially Haskell), but I think this can be said in a more neutral way.

Quuxbazbarfoo (talk) 19:26, 25 May 2020 (UTC)

I feel like FP terminology is not complex when you use it to compute. It only becomes complex when, ironically, you use it to do category theory, with all complexity coming from category theory. Just my 2 cents. --Nullzero (talk) 03:28, 26 May 2020 (UTC)