Talk:Functional programming

Letters between Beckus and Dijkstra

The section about Beckus delivering a Turing Award lecture about FP should also include the letters surrounding that period between Dijkstra & Beckus. https://medium.com/@acidflask/this-guys-arrogance-takes-your-breath-away-5b903624ca5f — Preceding unsigned comment added by 144.6.170.230 (talk) 09:35, 30 March 2025 (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)

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)

Lead section

The last paragraph of the lead section is way too heavy on citations. Do we really need a citation from 1987 on how to program a text editor? What is that doing there anyway (ref name="hartheimer1987")? Honestly, there should be no citations in a lead section, unless something is so controversial it causes a knee-jerk reaction from newbies to add a citation needed tag without first checking the body of the article. See WP:LEAD. Please get rid of most of them, the article will be easier to deal with. -- GreenC 18:24, 16 May 2024 (UTC)

Remain focused on functional programming

If no one objects I'm going to clean up sections that discuss points unrelated to function vs. other paradigms. For example, the start of Abstraction compared the time it takes to execute an even() call vs calling the mod operator directly. On one compiler. For a language which compiles to java bytecode and was then tested on one jre/jvm. Even if this comparison was more thorough, I don't see how this in any way relates to a definition of functional programming or a comparison to other paradigms. Dontfunkintellme (talk) 15:14, 29 March 2025 (UTC)