[epgui]

> 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. The two concepts are so intimately tied that sometimes I wonder if they're two different perspectives on the same thing.

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.

[arzke]

> 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.

[corinroyal]

"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.

[kaba0]

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.

[arzke]

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