> Many pure functions are easier to think about than their impure equivalents, but it's certaintly not the case the all pure functions are easier to think about than their impure equivalents.
I disagree. 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) or bad programming. I think that even programs that are best implemented statefully such as databases are easier to think about if they are defined conceptually in a pure way(as functions taking an additional parameter to represent the database state when it is called) regardless of how they are actually impelmented.
> 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.
> "the appropriate response"? Sorry, I have work to do, work that doesn't include making advocates of functional programming happy, let alone spending time on things that they haven't been able to do.
I'm not saying that you have some sort of obligation to make it possible to more understandably solve some problem purely. 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). What I meant by what you quoted is not that you specifically should make a better functional language, but that flaws in the existing languages are not necessarily a condemnation of the concept of pure functions.
> (Some of the developers of functional programming systems are quite brilliant so the fact that they haven't solved certain issues is significant.)
Significant, but hardly an indication that those issues are unsolvable. C was developed by quite brilliant people, but there were many issues they did not solve.
> 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.)
I disagree. 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) or bad programming. I think that even programs that are best implemented statefully such as databases are easier to think about if they are defined conceptually in a pure way(as functions taking an additional parameter to represent the database state when it is called) regardless of how they are actually impelmented.
> 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.
> "the appropriate response"? Sorry, I have work to do, work that doesn't include making advocates of functional programming happy, let alone spending time on things that they haven't been able to do.
I'm not saying that you have some sort of obligation to make it possible to more understandably solve some problem purely. 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). What I meant by what you quoted is not that you specifically should make a better functional language, but that flaws in the existing languages are not necessarily a condemnation of the concept of pure functions.
> (Some of the developers of functional programming systems are quite brilliant so the fact that they haven't solved certain issues is significant.)
Significant, but hardly an indication that those issues are unsolvable. C was developed by quite brilliant people, but there were many issues they did not solve.