4 ms·

I don't think the article promotes functional programming in favor of structured programming or object oriented programming. Rather it explains why pure functio

I don't think the article promotes functional programming in favor of structured programming or object oriented programming. Rather it explains why pure functional programming should be favored over 'impure' functional programming. 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.

stcredzero 17y ago
I'll quote my comment: 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.
anamax 17y ago
> [Quoting the article.] It’s because programs are difficult to comprehend to the extent that they are impure. 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.
- Raphael_Amiard 17y ago
  Argumenting your "That's wrong" "Nonsense" and such interjections would help me understand the usefulness of your post
  - anamax 17y ago
    Functional purity is mostly unrelated to comprehensibility - comprehensible programs can be pure, or not, and the same goes for incomprehensible probgrams. The relevant background knowledge is some experience with programs. 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?
    - ekiru 17y ago
      Pure functions are easier to think about than impure functions. It is easier to think about simpler things. Pure functions are simpler than impure functions because their result depends only on their parameters(complexity being correlated with the number of things on which a thing depends). 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.
      - anamax 17y ago

stcredzero 17y ago

I'll quote my comment: 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.

anamax 17y ago

> [Quoting the article.] It’s because programs are difficult to comprehend to the extent that they are impure. 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.

Raphael_Amiard 17y ago
Argumenting your "That's wrong" "Nonsense" and such interjections would help me understand the usefulness of your post
- anamax 17y ago
  Functional purity is mostly unrelated to comprehensibility - comprehensible programs can be pure, or not, and the same goes for incomprehensible probgrams. The relevant background knowledge is some experience with programs. 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?
  - ekiru 17y ago
    Pure functions are easier to think about than impure functions. It is easier to think about simpler things. Pure functions are simpler than impure functions because their result depends only on their parameters(complexity being correlated with the number of things on which a thing depends). 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.
    - anamax 17y ago