Discussion on: Function vs Object

[Jason C. McDonald]

Functional Programming is not just made up of functions, but of pure functions. You've already started to touch on this, but these are the most important traits of a pure function according to FP:

• No side-effects. Accepts input, returns output, nothing more. (You mentioned this.)

• No state within a function; the same input should always yield the same output on each call. (Exceptions exist...sorta? Closures aren't pure FP.)

• The implementation of a function has absolutely no effect on any other part of the code. As long as the input and output are the same, the details don't matter to the rest of the program.

• The function does exactly one thing; it should call other functions to handle any other things.

That said, I have a feeling you're going to go into all this later? (At least, I hope you will.)

[stereobooster]

Functional Programming is not just made up of functions, but of pure functions.

I don't want to touch the whole surface, I would need to explain, lazy evaluation, side effects, IO monad (I'm not ready for that one). So I keep it simple for now.

Closures aren't pure FP.

Why not? Closures with mutation and re-assignment are not pure FP, but otherwise...

[Jason C. McDonald]

Closures have state, which the purists say you should avoid.

But I'm not a purist.

[stereobooster]

It's not that "state", which they avoid in FP (unless you add mutation and reassignment). You can think of it as variable binding

[Jason C. McDonald]

Yes, I know. It appears there are two camps on this. Clearly, the other factor is implementation, anyway.

As for myself, I'm content to say "frankly, my dear, I don't give a grep." ;-P

[stereobooster]

I have no idea about the second camp. Any Haskell (the most wide spreaded pure FP language) programmer would agree that closures are functional. When I say state, I mean data. I'm not saying this data will change over time. Maybe this is what confuses people? Consts - e.g. state which you can set only once and never change after are functional. Variable binding is functional as well.

(There is a link to Haskell wiki in the thread)

[Jason C. McDonald]

When I say state, I mean data. I'm not saying this data will change over time. Maybe this is what confuses people?

It could be. FP is far newer a concept to me than OOP, so I won't rule out missing something!

Go figure this happens while I'm writing an entire chapter on functional programming in Python. At least this gives me information for putting some of said confusion to rest.

[stereobooster]

Thanks for the feedback. Interesting is there some kind of authoritative definition for state in this case? My PoV is that whenever you need to allocate or write to memory this is a state, even if you never change it after the first write.

From merriam-webster: a condition or stage in the physical being of something.

For example, let's imagine pure FP program which is not doing side effects, but only doing calculation of some big number. We can pause in the middle of calculation (put computer in a sleep mode) and resume later. The fact that we were able to resume means we have state (right?).

But on the other side a lot of people would consider only mutable data as state...

[Jason C. McDonald]

From what I understood, the main complaint against stateful closures (would that be what you call them) is when you provide it with the same inputs, and get different outputs. Any function should provide the same output for the same input, every time.

But, as you pointed out, constants don't contribute that issue.

[stereobooster]

Closure without mutation or re-assignment ("pure"):

const addSome = (x) => (y) => x + y;
const addFive = addSome(5);
addFive(1) === addFive(1) 

Closure with re-assignment += ("not pure"):

const counter = (x) => (y) => x += y;
const countFromZero = counter(0);
countFromZero(1) !== countFromZero(1)

My point is that there is nothing wrong with closures. It is re-assignment and mutation which make closures (or functions) "not pure".

[Jason C. McDonald]

Yup, makes sense!

[Robin Palotai]

Re state: in pure FP I think we mean a "named" piece of data whose instances get changed over time:

go :: Int -> Int
go 0 = 0
go s = s + go (s-1)

Here s can be thought of as state, even though specific bindings of s don't change.

We observe state over the course of computation.