4 ms·

"Don't be scared" rhetoric is generally used to promote arguments not primarily through logic, but by painting the audience as fearful luddites, scared of progr

"Don't be scared" rhetoric is generally used to promote arguments not primarily through logic, but by painting the audience as fearful luddites, scared of progress and the inevitable better future based on whatever the speaker is advocating. The goal is to encourage the listener to convert to the new religion or paradigm, or be considered backwards, behind the times, and ignorant or stubborn. It's an effective tactic because any push-back is pre-framed as evidence the listener is among the ignorant backwards people.

notacoward 12y ago
Hear, hear. I had exactly the same reaction. Maybe the author is pitching the article toward novice programmers and is genuinely trying to reassure. OTOH, such phrasing is far more often used as a pure rhetorical ploy. Personally, since I work in storage which is where we have to store all the "state" that the FP folks have defined into Somebody Else's Problem, I have little tolerance for that particular flavor of the month.
- slapresta 12y ago
  You seem to be confusing state with data. Storage is supposed to store data, not state. Still, even if you store your internal state, that's hardly what functional programming means when opposing state.
  - notacoward 12y ago
    That kind of response starts to sound like "no true Scotsman" pretty darn quick. How do you distinguish between state that is on the stack (which FP still has), state that is on the heap, or state that is on external storage? Are those the same distinctions/evasions that I'd get from the next three FP advocates I asked? I keep hearing about how FP saves us from all that evil mutable state, but every time I look at a program written in a functional language I see plenty of mutable state. Half of it is entangled with control flow, which I do not see as an unalloyed win. When that doesn't suffice, those same programs often resort to externalizing their state (e.g. into a database), often incurring a significant and unnecessary performance penalty just so they can give it a name and treat it as something outside of their program. Aristocrats never like to get their hands dirty, and that's exactly how most FP advocacy comes across. "Let them eat monads." Can't wait for the guillotine.
    - innguest 12y ago
      There are answers to those questions but they do not help you to understand functional programming as a practice. Because you're asking the equivalent of "But how does OOP distinguish stack from heap from storage?" and it's not a practical question. The answer is something along the lines of: the compiler is usually very different from most, it uses graph reduction and rewriting techniques, garbage collectors optimized for block reusage for all the heap churn that all those function frames would generate if implemented naively (that's why recursion ends up being as fast as a loop); this is my cursory understanding of it. But yes, I would suggest Lisp in Small Pieces and Appel's compiler books. For practical purposes what is important is that FP is inviting you to program in this world where it is not important to talk about how those things end up getting implemented on the machine. In fact it lets you quickly escape that world whenever possible by allowing you to alias the String type to FirstName for instance; so you can talk about the problem you're trying to solve, and not the computer that will run it. That's the point of declarative programming and FP is declarative. It's the same in Prolog, I'd think. I'm sure they don't care about how these things are actually being created and destroyed on the machine; the power of Prolog's declarative style is precisely that it allows you to never talk about the machine if you don't want to. That ends up being more general than the usual abstractions of the day that still model themselves after the turing machine. There's no state to speak of. FP builds the blueprint of the program (one level removed from the way OOP and procedural see things) and gives it to the computer to run it. Now we make the execution order implicit (it's now implicitly threaded through the functions' caller-callee relationships) and we lose the ability to do state (because state depends on ordering things, which can be represented by the semicolon in curly-brace languages). We also lose the ability to do one thing after the other. But although it sounds like a bad thing, it's actually a really good thing, because apparently most bugs live inside semicolons.
      - seanmcdirmid 12y ago
        > That's the point of declarative programming and FP is declarative. Declarative programming is a gradient. You can be exposed to a bunch of tedious details in FP and you can abstract over them in OOP. Saying FP is somehow magically declarative (as if that were a thing) leads to profound disappointment when complexity is inevitably encountered. > It's the same in Prolog, I'd think. "Cut" it out :) Also see taming space leaks in Haskell. > There's no state to speak of. FP builds the blueprint of the program (one level removed from the way OOP and procedural see things) and gives it to the computer to run it. The primary difference between pure FP and OOP is identity: there is no identity to speak of, things don't have names or addresses, they are just values whose equality is determined purely by structure. The inability to name things in FP is a huge drawback, because things actually have names in the real world. State doesn't depend on ordering. It depends on time; imperative and even functional languages often convolute the two concepts, but not always (see real FRP, not fake FRP ala Rx). Functional languages eschew state are merely eschewing the notion of time, which makes equational reasoning hard; it takes something like FRP to bring time back into the fold by making it explicit. Still, its quite hard to program interactive apps in pure FP given the intrinsic aversion to time.
- wyager 12y ago
  >Personally, since I work in storage which is where we have to store all the "state" that the FP folks have defined into Somebody Else's Problem, I have little tolerance for that particular flavor of the month. You say this as if functional programmers somehow make your life harder... It's not like they're decrying the existence of persistent storage or trying to put you out of business :) Also, functional programming isn't about offloading state, it's about removing it from programs altogether (in the sense of "state" being something that isn't explicitly passed through function arguments).
- innguest 12y ago
  In FP, State is transformed into something more formalized, namely parameters passed to other functions. So no one in FP is punting on State, we simply don't need it to accomplish those same goals. It's different from saying "it's somebody else's problem", though it might sound like that because State is one problem FP does not have (so in that sense it is solely a turing-machine-programmers' problem).
msie 12y ago
I didn't get that impression from the title. There are people who are interested in fp but feel that they are not smart enough to comprehend it. They are not luddites by any stretch.
deleted 12y ago
[deleted]
CmonDev 12y ago
We are already dealing with a weak dynamic language - what else could really scare us? Perhaps introducing shared memory multithreading into core JS... Certainly not a bit of immutability and pure functions.
wyager 12y ago
I think it's appropriate. A sentiment I hear an alarming amount is roughly "I want to program, not do math." when someone gets a suggestion to learn functional programming. In reality, someone can take advantage of FP with absolutely no understanding of the mathematical underpinnings. I think that's what the author was trying to get across.
- innguest 12y ago
  I think it's better to solve the "math is scary" attitude problem by first showing how it actually helps and is useful. FP gets a lot easier if you know some basic abstract math.
VeejayRampay 12y ago
With more passionate FP advocates, there's no "people who are not interested in FP after having tried and not finding it useful for their intents and purposes", there are people who either : - Don't understand it - Are afraid of it - Find it too complicated

notacoward 12y ago

Hear, hear. I had exactly the same reaction. Maybe the author is pitching the article toward novice programmers and is genuinely trying to reassure. OTOH, such phrasing is far more often used as a pure rhetorical ploy. Personally, since I work in storage which is where we have to store all the "state" that the FP folks have defined into Somebody Else's Problem, I have little tolerance for that particular flavor of the month.

slapresta 12y ago
You seem to be confusing state with data. Storage is supposed to store data, not state. Still, even if you store your internal state, that's hardly what functional programming means when opposing state.
- notacoward 12y ago
  That kind of response starts to sound like "no true Scotsman" pretty darn quick. How do you distinguish between state that is on the stack (which FP still has), state that is on the heap, or state that is on external storage? Are those the same distinctions/evasions that I'd get from the next three FP advocates I asked? I keep hearing about how FP saves us from all that evil mutable state, but every time I look at a program written in a functional language I see plenty of mutable state. Half of it is entangled with control flow, which I do not see as an unalloyed win. When that doesn't suffice, those same programs often resort to externalizing their state (e.g. into a database), often incurring a significant and unnecessary performance penalty just so they can give it a name and treat it as something outside of their program. Aristocrats never like to get their hands dirty, and that's exactly how most FP advocacy comes across. "Let them eat monads." Can't wait for the guillotine.
  - innguest 12y ago
    There are answers to those questions but they do not help you to understand functional programming as a practice. Because you're asking the equivalent of "But how does OOP distinguish stack from heap from storage?" and it's not a practical question. The answer is something along the lines of: the compiler is usually very different from most, it uses graph reduction and rewriting techniques, garbage collectors optimized for block reusage for all the heap churn that all those function frames would generate if implemented naively (that's why recursion ends up being as fast as a loop); this is my cursory understanding of it. But yes, I would suggest Lisp in Small Pieces and Appel's compiler books. For practical purposes what is important is that FP is inviting you to program in this world where it is not important to talk about how those things end up getting implemented on the machine. In fact it lets you quickly escape that world whenever possible by allowing you to alias the String type to FirstName for instance; so you can talk about the problem you're trying to solve, and not the computer that will run it. That's the point of declarative programming and FP is declarative. It's the same in Prolog, I'd think. I'm sure they don't care about how these things are actually being created and destroyed on the machine; the power of Prolog's declarative style is precisely that it allows you to never talk about the machine if you don't want to. That ends up being more general than the usual abstractions of the day that still model themselves after the turing machine. There's no state to speak of. FP builds the blueprint of the program (one level removed from the way OOP and procedural see things) and gives it to the computer to run it. Now we make the execution order implicit (it's now implicitly threaded through the functions' caller-callee relationships) and we lose the ability to do state (because state depends on ordering things, which can be represented by the semicolon in curly-brace languages). We also lose the ability to do one thing after the other. But although it sounds like a bad thing, it's actually a really good thing, because apparently most bugs live inside semicolons.
    - seanmcdirmid 12y ago
      > That's the point of declarative programming and FP is declarative. Declarative programming is a gradient. You can be exposed to a bunch of tedious details in FP and you can abstract over them in OOP. Saying FP is somehow magically declarative (as if that were a thing) leads to profound disappointment when complexity is inevitably encountered. > It's the same in Prolog, I'd think. "Cut" it out :) Also see taming space leaks in Haskell. > There's no state to speak of. FP builds the blueprint of the program (one level removed from the way OOP and procedural see things) and gives it to the computer to run it. The primary difference between pure FP and OOP is identity: there is no identity to speak of, things don't have names or addresses, they are just values whose equality is determined purely by structure. The inability to name things in FP is a huge drawback, because things actually have names in the real world. State doesn't depend on ordering. It depends on time; imperative and even functional languages often convolute the two concepts, but not always (see real FRP, not fake FRP ala Rx). Functional languages eschew state are merely eschewing the notion of time, which makes equational reasoning hard; it takes something like FRP to bring time back into the fold by making it explicit. Still, its quite hard to program interactive apps in pure FP given the intrinsic aversion to time.
wyager 12y ago
>Personally, since I work in storage which is where we have to store all the "state" that the FP folks have defined into Somebody Else's Problem, I have little tolerance for that particular flavor of the month. You say this as if functional programmers somehow make your life harder... It's not like they're decrying the existence of persistent storage or trying to put you out of business :) Also, functional programming isn't about offloading state, it's about removing it from programs altogether (in the sense of "state" being something that isn't explicitly passed through function arguments).
innguest 12y ago
In FP, State is transformed into something more formalized, namely parameters passed to other functions. So no one in FP is punting on State, we simply don't need it to accomplish those same goals. It's different from saying "it's somebody else's problem", though it might sound like that because State is one problem FP does not have (so in that sense it is solely a turing-machine-programmers' problem).

msie 12y ago

I didn't get that impression from the title. There are people who are interested in fp but feel that they are not smart enough to comprehend it. They are not luddites by any stretch.

deleted 12y ago

[deleted]

CmonDev 12y ago

We are already dealing with a weak dynamic language - what else could really scare us? Perhaps introducing shared memory multithreading into core JS... Certainly not a bit of immutability and pure functions.

wyager 12y ago

I think it's appropriate. A sentiment I hear an alarming amount is roughly "I want to program, not do math." when someone gets a suggestion to learn functional programming. In reality, someone can take advantage of FP with absolutely no understanding of the mathematical underpinnings. I think that's what the author was trying to get across.

innguest 12y ago
I think it's better to solve the "math is scary" attitude problem by first showing how it actually helps and is useful. FP gets a lot easier if you know some basic abstract math.

VeejayRampay 12y ago

With more passionate FP advocates, there's no "people who are not interested in FP after having tried and not finding it useful for their intents and purposes", there are people who either : - Don't understand it - Are afraid of it - Find it too complicated