I don't know what "silver bullet" claims you've heard, but I'm not sure how that is relevant to this thread. I don't think I've made any outlandish claims, or any claims that aren't substantiated by a preponderance of academic literature.

I find this whole thread fascinating because nobody seems to have identified what functional programming is defined as (programmers can just use functions to code and end up with functional programming, it isn't an obscure style), who the advocates are or what they claim.

And yet, without any substance, the debate rages.

> nobody seems to have identified what functional programming is defined as

Nobody asked (until now, so thank you for asking!), and this is a fairly well discussed topic for anyone who cares to search!

You will probably get a lot of slightly different answers depending on who you ask or where you look, but I think a very strong common thread is "referential transparency". Functional programming gives you that, and that is the property that makes FP particularly well suited for parallel computation. Referential transparency is related to the concept of "function purity" (in the sense that either one usually guarantees the other), which you will often hear people talk about as well.

This, along with the fact that FP has been an active area of research (an important part of innovation) for a long time, is why I brought it up.

https://en.wikipedia.org/wiki/Functional_programming

https://en.wikipedia.org/wiki/Pure_function

https://en.wikipedia.org/wiki/Referential_transparency

https://softwareengineering.stackexchange.com/questions/2938...

---

> programmers can just use functions to code and end up with functional programming, it isn't an obscure style

That's not how it works. Note that functional programming has nothing to do with merely "writing functions".

---

> without any substance, the debate rages

The substance is there and there is plenty of it, but learning requires work.

> Referential transparency is related to the concept of "function purity" (in the sense that either one usually guarantees the other), which you will often hear people talk about as well.

Isn't referential transparency (the property of a function that allows it to be replaced by its equivalent output) a consequence of function purity? In other words: could a pure function not be referentially transparent?

Also, I remember Robert C. Martin describing the functional programming paradigm as a "restriction upon assignment". I kind of like this definition as the rest seems to flow from it: if you can't assign, you can't mutate. If you can't mutate, you have pure functions, which are referentially transparent.

"Could a pure function not be referentially transparent?"

Yes there are pure functions which are not referentially transparent. A pure function with side effects, such as printing a result to standard output, is not referentially transparent. You can't replace the function with it's return value, since that doesn't replicate the printing side effect.

I thought that a pure function could not have side effects by definition. Would you mind sharing your definition of a pure function?

A pure function is by definition side-effect free. What you write makes 0 sense. Maybe thinking of total functions?

But not all FP languages have to be so puritan to only allow pure functions, most have escape hatches and it is just good form to prefer purity (even in more mainstream languages!). The most common way to circumvent this problem is through a Monad, which very naively put, just a description of the order of side-effecting functions, and their inter-dependencies. This will later get executed at a specific place, e.g. the main function -- the point is, that a large part of the code will be pure, and much easier to reason about.

Functional programmers regularly claim:

-Haskell is faster than C (lol)

-FP gives you free concurrency

-FP makes code more testable

-FP is easier to read

-FP is easier to consume for people

-FP results in no bugs

-FP is easier to change

-FP will literally suck your peepee

-Actually FP is the second coming for Christ

It’s really funny how you also pretend you’ve never heard of all the silver bullet claims that are incessantly plaguing every programming forum.

I agree with some of these points, but none of them are claims I made in the context of this discussion, so I’m not sure why you’re even arguing about those. It’s irrelevant.

They’re false claims. And I didn’t bring up the false claims FP programmers make until you asked for it to happen. I simply said that rejecting the ridiculous silver bullet claims that FP programmers make is completely fine because they don’t provide any evidence and that which is asserted without evidence can be dismissed without it.

Not that that matter because all of those claims are demonstrably false anyway!

> -FP will literally suck your peepee

> -Actually FP is the second coming for Christ

On a style point, you've rather undermined yourself that these are common claims because there are entries on this list that are clearly fabricated, as well as others that look like wilful misinterpretations of what someone else said. That casts doubt on the more reasonable entries. There are annoying FP evangelists out there, but the overall tone pattern matches straw-manning.

You'd have made it easier for everyone taking the whole list seriously. Transparently mixing fact and fiction just makes it harder for people who aren't already part of a conversation.

> Functional programmers regularly claim:

> -Haskell is faster than C (lol)

If they regularly claim that you should easily be able to point to several recent examples. Can you?

Then why has it been slowly incorporated into literally every mainstream PL? You do know you don't have to be an extremist, and your code can contain both FP, OOP and imperative parts, whichever makes the most sense? FP and OOP are not even opposites.

They absolutely solve real issues, and it's just sticking your head into sand to say otherwise.