5 ms·

I am deeply suspicious of any attempt to define the next "one true way". Perhaps it is because I have lived (and worked) through Structured Programming, Object

by bdfh42 17y ago

I am deeply suspicious of any attempt to define the next "one true way". 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.

Confusion 17y ago
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.
wglb 17y ago
I am suspicious as well, or perhaps stronger--I am likely to say "humbug" to such claims. Having made many of them loudly at various points in my career, starting with Structured Programming, OOP. There was also the Rational phase, as in the Rational Unified Method, in which the methodology was though to hold the true silver bullet. 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?
- trezor 17y ago
  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.
  - william-newman 17y ago
    I agree that his point is valid for computers built on the ordinary substrate of classical switches (whether relays, tubes, or transistors). There are two very influential ways of representing computation, the lambda calculus and the Turing machine; when starting from switches, people (roughly) build something that looks like a Turing machine (with procedural programs) and then, if they want lambda calculus (with more functional programs) they use Turing completeness to emulate it. 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?
swannodette 17y ago
Sure, subatomic particles are the foundation for reality, but as humans we don't walk around thinking about the world in terms of each object's subatomic structure - it's simply too low a level for most activities. We operate at the level of thought, images, words, concepts - abstractions. Why should we be spending a lot time of programming at the level of the computer's fundamental structure or even be using idioms from that level? This is not to say we as researchers and practitioners should not comprehend this level and occasionally operate at it- but most of the time we should be expressing our ideas in the most expressive way possible. 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.
- bdfh42 17y ago
  You are correct in everything you say but we have to be careful of each and every layer we build on top of the "fundamental particles" of programming to minimise the risk of accidental complexity. 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.
radu_floricica 17y ago
I don't think there was any "one true way"-ness in this article. It described a different way to write programs, and argued it's better. Don't let the use of the word "pure" fool you, I also expected an argument about "pure" functional languages vs mixed, but it was not the case. Pure programming, in this context, means locally side-effect free programming, using immutable data structures. It said nothing about using imperative programming in other parts of the software, or even about using non-immutable variables inside a function.

by bdfh42 17y ago

Confusion 17y ago

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.

wglb 17y ago

I am suspicious as well, or perhaps stronger--I am likely to say "humbug" to such claims. Having made many of them loudly at various points in my career, starting with Structured Programming, OOP. There was also the Rational phase, as in the Rational Unified Method, in which the methodology was though to hold the true silver bullet. 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?

trezor 17y ago
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.
- william-newman 17y ago
  I agree that his point is valid for computers built on the ordinary substrate of classical switches (whether relays, tubes, or transistors). There are two very influential ways of representing computation, the lambda calculus and the Turing machine; when starting from switches, people (roughly) build something that looks like a Turing machine (with procedural programs) and then, if they want lambda calculus (with more functional programs) they use Turing completeness to emulate it. 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?

swannodette 17y ago

Sure, subatomic particles are the foundation for reality, but as humans we don't walk around thinking about the world in terms of each object's subatomic structure - it's simply too low a level for most activities. We operate at the level of thought, images, words, concepts - abstractions. Why should we be spending a lot time of programming at the level of the computer's fundamental structure or even be using idioms from that level? This is not to say we as researchers and practitioners should not comprehend this level and occasionally operate at it- but most of the time we should be expressing our ideas in the most expressive way possible. 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.

bdfh42 17y ago
You are correct in everything you say but we have to be careful of each and every layer we build on top of the "fundamental particles" of programming to minimise the risk of accidental complexity. 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.

radu_floricica 17y ago

I don't think there was any "one true way"-ness in this article. It described a different way to write programs, and argued it's better. Don't let the use of the word "pure" fool you, I also expected an argument about "pure" functional languages vs mixed, but it was not the case. Pure programming, in this context, means locally side-effect free programming, using immutable data structures. It said nothing about using imperative programming in other parts of the software, or even about using non-immutable variables inside a function.