> Most cases of the pure function being harder to think about than the impure equivalent are a result of either demanding impure semantics from a pure function(pure functions aren't always the best choice for implementation)
So much for the claim that purity is always easier to understand....
>> And, because pure functions have no state, many pure functions have to drag along state through their parameters that they don't need/use but that their callees need/use.
> I don't understand this argument. Calling another function on data from their parameters is the way functions need/use their parameters.
Callees provide a service. I don't care how they provide said service, but if they're "stateful", functional programming exposes that.
> However, as I am one of those functional programming advocates, I think that you would be helping yourself by solving problems purely when impure semantics are not a necessary requirement of the problem(I would also expect that fewer problems than you might think require impurity).
Read up the thread. I'm a believer, and I'm telling you that the way that fp folk advocate is counter-productive. (Telling people that they shouldn't reject fp because some future language might be useful for their problem is especially dumb.)
> C was developed by quite brilliant people, but there were many issues they did not solve.
C wasn't developed by folks who were trying to introduce a new type of programming language. C was, in some sense, an afterthought for them because their argument was about systems building, not programming languages. Also, it was a different world then - C didn't really have competitors.
While FP can be a fantastic way of programming, FP advocates are mindbogglingly ignorant of people and programming in the real. (Perhaps the ability to write small programs for some non-trivial problems is an obstacle to understanding.)
So much for the claim that purity is always easier to understand....
>> And, because pure functions have no state, many pure functions have to drag along state through their parameters that they don't need/use but that their callees need/use.
> I don't understand this argument. Calling another function on data from their parameters is the way functions need/use their parameters.
Callees provide a service. I don't care how they provide said service, but if they're "stateful", functional programming exposes that.
> However, as I am one of those functional programming advocates, I think that you would be helping yourself by solving problems purely when impure semantics are not a necessary requirement of the problem(I would also expect that fewer problems than you might think require impurity).
Read up the thread. I'm a believer, and I'm telling you that the way that fp folk advocate is counter-productive. (Telling people that they shouldn't reject fp because some future language might be useful for their problem is especially dumb.)
> C was developed by quite brilliant people, but there were many issues they did not solve.
C wasn't developed by folks who were trying to introduce a new type of programming language. C was, in some sense, an afterthought for them because their argument was about systems building, not programming languages. Also, it was a different world then - C didn't really have competitors.
While FP can be a fantastic way of programming, FP advocates are mindbogglingly ignorant of people and programming in the real. (Perhaps the ability to write small programs for some non-trivial problems is an obstacle to understanding.)
But, feel free to ignore me.