Arguments in favor of pure functional programming
apocalisp.wordpress.com
apocalisp.wordpress.com
Perhaps it is because I have lived (and worked) through Structured Programming, Object Oriented Programming and now see Functional Programming promoting a (valid) bid to make a contribution to the general improvement in the standard of written programs - this time by attempting to eliminate the side effects of "state".
Each of the previous "one true ways" has made a welcome contribution but only a contribution.
We must remember that all such programming techniques are intended to help us, the poor imperfect programmer, write code with fewer bugs. The final code is always translated into a sequence of simple procedural instructions for the processor to execute - procedural programming is the foundation upon which all other edifices are constructed.
I think your point about 'us poor imperfect programmers' is well supported by the article, because it argues that purely functional programs are easier to understand. To quote the article:
This is why you have bugs, why programs are hard to debug, and software is difficult to extend. It’s because programs are difficult to comprehend to the extent that they are impure. And the reason for that is that they are not sufficiently abstract. A writer of impure code is not operating on the level of abstraction of programming. He’s operating at the level of abstraction of the machine.
OO principles also allow programmers to selectively expose complexity, hopefully reducing complexity to a commonsense model of what is going on. (Essential complexity?) However, this amounts to volunteering to do “the right thing,” as even “pure OO” environments like Smalltalk allow one to violate encapsulation and write procedural code. I can see how a “pure functional” environment would make it difficult to write procedural code. But one can also create spaghetti OO models that respect encapsulation. I imagine that one can create spaghetti pure functional code as well.
That's wrong.
> And the reason for that is that they are not sufficiently abstract.
Abstraction has nothing to do with functional purity.
> A writer of impure code is not operating on the level of abstraction of programming.
Nonsense.
> He’s operating at the level of abstraction of the machine.
The real world has mutable state and all abstractions leak.
I write functional when I can and single-assignment (mechanically translateable into pure functional, but is often cleaner in procedural languages) almost all of the rest of the time, so I live on the functional Kool-Aid(TM).
The above is the sort of crap that makes it harder to get people to write functional.
If someone knows what both functional purity and abstraction are, they don't need to be told that they're different and one can have either one without the other.
"the abstraction of programming" is on the edge of bather and the part that isn't blather has nothing to do with impure programming.
And, if you don't understand that abstractions leak and that the real world (and machines) are stateful/not functional, you're in for it.
What part of that is hard to understand?
If purely functional programs in some language to accomplish some goal are harder to understand than stateful implementions, the appropriate response is not to criticize functional programming, but instead to try to find ways to make that language more understandable or more suitable for accomplishing that goal.
"And, if you don't understand that abstractions leak and that the real world (and machines) are stateful/not functional, you're in for it."
I think there are actually conceptual advantages to thinking of the universe functionally(as a tail-recursive function with all the "state" contained in the parameters), in case a method for time travel is ever developed. It seems as though it would be easier to reason about than it would be if the universe is treated as stateful.
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.
> Pure functions are simpler than impure functions because their result depends only on their parameters.
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.
> (complexity being correlated with the number of things on which a thing depends).
The complexity of the things matters a lot as well.
> If purely functional programs in some language to accomplish some goal are harder to understand than stateful implementions, the appropriate response is not to criticize functional programming, but instead to try to find ways to make that language more understandable or more suitable for accomplishing that goal.
"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. (Some of the developers of functional programming systems are quite brilliant so the fact that they haven't solved certain issues is significant.)
> I think there are actually conceptual advantages to thinking of the universe functionally(as a tail-recursive function with all the "state" contained in the parameters), in case a method for time travel is ever developed.
Talk about premature optimization, not to mention the bogus assumption that a universe with time travel can't be stateful.
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.
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.
I think i agree with you on some points, but this just sounds like mindless generalisation.
Not all fp advocates are like this, if it were so, we wouldn't see so much real world solutions to the use of fp in non academical languages
There is the possibility that FP gets wins despite the actions of FP advocates.
This could be argued as being totally wrong philosophically, and is certainly not a proved statement.
I could say that state is only the creation of the human mind in a world that is essentially made of movement, in order to understand it and quantize it. Even matter at the lowest level is the movement or particles, almost as much as it is the particles themselves.
This point is not without link to the current argument about functional/imperative programming, and certainly shows that your view of the matter, while not false, is certainly narrow minded.
Doing functional programming still leaves you with the essential complexity.
But I wonder if "procedural programming is the foundation upon which all other edifices are constructed" is necessarily true. Could we not build a computer that was truly functional throughout?
Not to sound rude here, but I'm going to guess you have never done any low-level programming, with assembly, mnemonic and embedded microprocessors, circuit-design etc etc: Things which require that you fundamentally understand how computers work.
Not to say we shouldn't have ambition, but given today's technology a computer being "functional throughout" would be a VM running on top of 100% procedural logic.
His point is very much valid.
That said, it's not 100% clear to me that this must be true for all physical models of computation. (And the existence of Shor's algorithm suffices to keep practical people at least a little interested in computational mechanisms which are fundamentally different from classical switches.) Does anyone know if there are any reasonably plausible computational mechanisms for which it'd be natural to start by implementing something that looked more like lambda calculus, so that if you needed a Turing machine you'd emulate it?
But it doesn't mean that it has to be that way. Everybody presumes that addresses are in binary, but this was not the case for many of the Burroughs machines, i think the 3500, just to challenge some assumptions.
So let me ask you a question in return: Are you familiar with the Burroughs B 1700?
And claiming that I have not done low-level programming is not likely to convince me that hardware is fundamentally necessarily procedural logic.
Also I'd like point out it's not like functional programming is a fad. It's roots go back almost 50+ years alongside structured programming. These paradigms have coexisted and influenced each other significantly over this time and as evidenced by the current of crop of interesting programming languages, there's lot more evolving to look forward to.
I firmly believe that all techniques that help us reduce errors are valid but that they should be selectively applied according to the context of any given task. I know that such an approach does little to help the newcomer to our craft but silver bullets will always lead newcomers in the wrong direction - at the end of the day what we write is executed by a silicon chip and the more aware we are of it's capabilities and limitations the better.