> Yes, I was referring to the time and space complexities of actually calculating the values. If the pure function were the algorithm, then there would be no separating the two. However, since a pure function can be calculated by several algorithms, then we are really just putting off some of the major points, no? (Hell, even in the simple 8 * 2, we are glossing over what really happens.
Again: both imperative and functional algorithms can be implemented in several ways. Both imperative and functional algorithms can solve the same problem, but have different time complexities.
"However, since a pure function can be calculated by several algorithms, then we are really just putting off some of the major points, no?"
What? The semantics of a pure function shouldn't be changed when you actually compute it - there is no "functional algorithm execution algorithm". The actual code that gets evaluated can be pretty different from the actual code you wrote, though - maybe your lazy lists got implemented as for-loops. Maybe you used a list in some way that made it look like you had O(n) space complexity, but it got turned into a loop that didn't store intermediate values so the space complexity is actually O(1). So yes, time complexity can be a little decieving, in some cases, if the compiler is sufficiently smart. However, there is no magic about the actual semantics of a functional algorithm.
> This is all really missing my main assertion, though. What is your function for getting in your car and driving somewhere? Could this be written in such a way that everything was a "pure" function? Probably. My hunch is that it wouldn't really be that readable, though. Now, if we shift the paradigm such that one of the "primitives" is your current location, suddenly the directions are a lot more readable.
Maybe you could. I don't think many care, though, not even functional programmers. The only decently widespread language that I can think of that actually enforces purity is Haskell, and some people even prefer to write imperative code in it over other languages. I don't get this obsession of yours with trying to argue against pure functional programming in the very, very strict sense of the whole program being pure, if that is actually possible. I think there are very few that are upset about having to write imperative code for code that has to do with sequential commands. They might use pure functional programming for the computations that they need, but they'll effectively write imperative programs at the top level.
What they probably do want, though, is to be able to clearly distinguish what parts of their programs are pure and what parts of their programs are potentially effectful.
Ah, I think I see the misunderstanding I am causing. I am not arguing against pure functions as a whole. Just acknowledging the weakness that they can not often be the whole. Many of the arguments for pure functions seem to be based on the "if your application is nothing but a collection of pure functions, then it will be easier to logic about." My assertion is "use that which is easier to reason about where you can." In some cases, this will actually be mutable state based entities. In others, it will be pure functions.
I also fully grant that when one is trying to work in a massively shared state application, pure functions have massive benefits. Seems the real win is typically identifying that which can be easily shared and that which can not. And partitioning the program accordingly. (Which, is what you ended with. So, I believe we are actually in fairly violent agreement. :) )
Again: both imperative and functional algorithms can be implemented in several ways. Both imperative and functional algorithms can solve the same problem, but have different time complexities.
"However, since a pure function can be calculated by several algorithms, then we are really just putting off some of the major points, no?"
What? The semantics of a pure function shouldn't be changed when you actually compute it - there is no "functional algorithm execution algorithm". The actual code that gets evaluated can be pretty different from the actual code you wrote, though - maybe your lazy lists got implemented as for-loops. Maybe you used a list in some way that made it look like you had O(n) space complexity, but it got turned into a loop that didn't store intermediate values so the space complexity is actually O(1). So yes, time complexity can be a little decieving, in some cases, if the compiler is sufficiently smart. However, there is no magic about the actual semantics of a functional algorithm.
> This is all really missing my main assertion, though. What is your function for getting in your car and driving somewhere? Could this be written in such a way that everything was a "pure" function? Probably. My hunch is that it wouldn't really be that readable, though. Now, if we shift the paradigm such that one of the "primitives" is your current location, suddenly the directions are a lot more readable.
Maybe you could. I don't think many care, though, not even functional programmers. The only decently widespread language that I can think of that actually enforces purity is Haskell, and some people even prefer to write imperative code in it over other languages. I don't get this obsession of yours with trying to argue against pure functional programming in the very, very strict sense of the whole program being pure, if that is actually possible. I think there are very few that are upset about having to write imperative code for code that has to do with sequential commands. They might use pure functional programming for the computations that they need, but they'll effectively write imperative programs at the top level.
What they probably do want, though, is to be able to clearly distinguish what parts of their programs are pure and what parts of their programs are potentially effectful.