17 ms·

FP is largely defined by what it avoids, not by what it adds. All the other bits, monads, higher order functions, etc, are necessary to finding workable solutio

FP is largely defined by what it avoids, not by what it adds. All the other bits, monads, higher order functions, etc, are necessary to finding workable solutions to real problems while avoiding things that cause the badness. To people who use those things avoided, it comes off as arrogant. It's like with vegetarians. "I don't eat meat; there are plenty of plant based sources of protein and I don't want to have to have animals killed on my behalf". Nothing about this is factually incorrect, none of it is arrogant, yet, because it's purposely avoiding something the listener consumes, the listener may take offense, and assume the vegetarian is taking a holier than thou attitude toward them. They assume that because the vegetarian views eating meat as something to be avoided, that the vegetarian must be judging them for eating meat. Similarly, because the FP programmer views mutable state as a dangerous practice, the listener who uses mutable state views the FP's attitude as judgemental, "You're not using best practices!" But, like the vegetarian who encounters someone who wants to try giving up meat, and is asking for recipes and ideas, FP programmers will, indeed, bend over backwards for someone who is trying to enter the functional world.

agumonkey 11y ago
That's the basis of an essay I'm writing. Derivation of FP from ImpP by progressive enhancement through mutation avoidance.
- JimmyM 11y ago
  That sounds really interesting, there was a similar approach (albeit somewhat implicit rather than explicit) in the Programming Languages Coursera course. Where do you think I would be able to read the essay when it's complete? Will there be a great deal of mathematics in there? (I have a poor/loose grasp of anything past high school mathematics, barring algorithms).
  - agumonkey 11y ago
    If I ever finish it I'll tweet it. There won't be a lot, I'm a barely educated noob with distate for out of reach abstraction. And I see a simple migration path from imperative to functional. If you have no college education about programming languages it might be interesting to test if my ideas are worth reading and actually effective.
    - steveklabnik 11y ago
      You might be interested in reading "Teaching Programming with the Kernel Language Approach" by Van Roy and Haridi.
      - agumonkey 11y ago
        Is it different from CTM ? ps: just read this https://www.info.ucl.ac.be/~pvr/fdpefinalweb.pdf https://www.info.ucl.ac.be/~pvr/fdpefinalweb.pdf it seem they extends the SICP approach, substitution -> state | concurrency ... I planned to do the opposite. state -> subst
        steveklabnik 11y ago
        They're very close to each other, the paper just presents the method directly, whereas the CTM is a book-length application of the method. Yeah, I guess it is in the opposite direction. I was mostly thinking in terms of describing a language in terms of another via 'progressive enhancement'.
        agumonkey 11y ago
        Yeah, the idea is similar, but I really meant to show how similar FP was to ImP by starting from what's familiar to non FP programmers.
DanWaterworth 11y ago
As both a vegetarian and functional programmer, I totally agree.
amalag 11y ago
The vegetarian bit is a nice analogy. Sometimes stating the truth comes off as being judgemental because the implications are obvious.
- tsmarsh 11y ago
  I'm a meat eater due to my biology more than anything else, I love the taste and I'm allergic to most fruits and vegetables (ORA). Before the degree of my ORA was known, I did play at being vegetarian for 6 months for ecological, not moral reasons. I don't see a moral difference between eating a fruit and and an egg, or salmon and a herb, milk/blood and maple syrup. The arguments that fauna are somehow more alive than fauna has never felt very strong to me. We've all been evolving and finding our niche for about the same amount of time. We've all got our own versions of response to external stimuli. Its just much harder to empathize with an apple tree than a chicken, especially when it comes to the ultimate sacrifice. However, the ecological arguments for vegetarianism around sustainability and CO2 emission seem sound for the standard american lifestyle. Of course that starts to flip if you hunt (I don't). Large scale agriculture does more damage to the environment than culling native mega fauna, which is arguably beneficial. It flips again, if you have your own garden, supplemented by local, organic specialists. And then you reach a much better level of reuse/yield if you can feed scraps to chickens and pigs and fertilize your ground with blood and bone meal. (it always makes me laugh when vegans think their organic vegetables are 'cruelty free'). So, no. I don't think the implications of saying you are vegetarian are immediately obvious. The more I research it, the healthier and more sustainable a diet of mostly fruit and vegetables supplemented by the meat of a couple of pigs, 6 or so chickens and the occasional hunt seems to be. But if you genuinely believe that fauna are some how better than flora I guess that simplifies the equation and somewhere down that path you get labelled a zealot. I suspect the same is true with programming. What you want is a system of mostly functional business logic that is supplemented with objects when it makes sense (modeling the state of an electrical circuit?!?), and the odd 'declarative hunting trip' when you need to cull the date from the database :) It is possible exist on just objects, or just functions but variety is the spice of life and the sum is often greater than the whole.
  - sshine 11y ago
bluetomcat 11y ago
The thing is, CPUs are designed to execute imperative programs. A stream of instructions is imperative. Until we see real hardware that executes functional programs, FP will always be somehow treated as a second-class citizen in the computing world.
- gagege 11y ago
  The thing is, CPUs are designed to execute imperative programs. A stream of instructions is imperative. Until we see real hardware that executes object-oriented programs, OOP will always be somehow treated as a second-class citizen in the computing world. Everything we do is an abstraction.
  - bluetomcat 11y ago
    Abstractions sometimes do not match well with the underlying abstractions that they depend on. The Von Neumann architecture is all about state and mutability, and yet FP tries to stay as far as it can from that. OOP is really a supplement layer over imperative programming and doesn't deny any of its underpinnings.
    - Retra 11y ago
      Abstractions necessarily do not match the underlying infrastructure. That's why they are called abstractions. That's also why we use them: because we don't want to be bound by underlying infrastructure. PS: Computers are not inherently digital, either.
    - dragonwriter 11y ago
      > The Von Neumann architecture is all about state and mutability, and yet FP tries to stay as far as it can from that. As I understand it, real world FP isn't about "staying away from" state and mutability, its about providing tools for managing state and mutability as a means to manage the complexity of reasoning about programs using it. E.g., Haskell's monadic approach essentially makes every Haskell program one that produces (as the result of the main function) the imperative program that is actually executed by the runtime.
altcognito 11y ago
Re: Vegetarianism. Because there is technically no need to say "I don't want to have animals killed on my behalf." That statement adds no extra information about their diet, it only says that if they were eating meat, they would be having animals killed on their behalf.
- lostcolony 11y ago
  shrug Fine. Assume they leave that bit off. In fact, assume they give no rationale at all. You're trying to figure out where to eat, and someone suggests a steakhouse, and someone else says "Er, I'm a vegetarian". Some people will get defensive of that, even with nothing further. The person didn't bring up that they were vegetarian pre-emptively, it was absolutely in the right context, it was in no way judgemental, it was not even saying -why-, and yet, many people get defensive. "Oh, man, I could never do that; I love meat too much", "Pff, you and your rabbit food", "How do you get enough protein? You know that's unhealthy, right?", etc.
  - altcognito 11y ago
    It's odd when people get defensive about it when you just say you're vegetarian, but I know it happens. My SO was vegetarian for 14 years and this happened from time to time. Sometimes the comment that having animals killed on your behalf is a flag that this person thinks it is amoral to kill animals for food. Meat is murder after all. I recognize very much so that not all vegetarians are like that.
  - tremendo 11y ago
    I also have a definite preference about what I allow into my digestive system, but if I happen to be in a group that, as a group, expresses a preference for where to go for a meal, I'll be flexible and eat the best way possible within the given constraints. Surely even a steakhouse has salads. Too frequent deviations of late? politely suggest an alternative or, decline to partake this time. No need to impose one's particular preferences, which is why it comes off the way it does.
- mcguire 11y ago
  ...which is true. And only a problem if you're defensive about it.
KingMob 11y ago
Interesting. As a former vegetarian, I was always a little surprised when someone would take offense at my vegetarianism, even if I hadn't said anything. They just assumed there was a critique implied.
eli_gottlieb 11y ago
I disagree. I've programmed in plenty of languages with mutable state and found myself desperately wishing for the power of lambdas, function combinators, comprehensions, and other higher-order constructs from functional programming. I'd really much rather have `map f xs` than `for(x : xs) result.add(f(x));`.
- lostcolony 11y ago
  I'm not saying that the ideas that came out of FP don't have beneficial use even in the imperative world, but that they are -necessary- in FP, because you've given up the imperative approaches.
- toast0 11y ago
  Most 'non-fuctional' languages have function pointers too, it just might be less idiomatic.
- pron 11y ago
  Mutable state and what we call FP aren't at all mutually exclusive. In fact, most languages which we call functional are imperative (i.e. they're imperative-functional). One of the first languages I used was Scheme which had plenty of mutable state as well as higher-order functions etc. Today, most OO languages have all those as well, and the mother-of-all-OOP, Smalltalk, had them all before the name "functional" even became fashionable.
pron 11y ago
FP is not defined at all. Pure FP (PFP) has a clear definition, but I challenge you to find a definition for FP that includes Clojure, Erlang, F#, and OCaml but excludes Java, JS, Ruby, Python, C++. All of these languages are imperative with varying amounts of reliance on higher-order functions and emphasis on immutability (for example, my favorite so-called-FP language, Clojure, allows global mutation all over the place, but provides some transactional assurances). Second, even if we consider PFP alone (which is, indeed, different from imperative programming), I often find that some of its proponents are lacking in understanding of the theoretical underpinnings of imperative programming. For example, day before yesterday I gave a talk at CurreyOn/ECOOP about why monads are harmful in imperative languages (i.e. any language that isn't PFP), and PFP experts present weren't aware (although, TBH, neither was I, but I'm not a PL researcher) of this proof[1] that imperative continuations are at least as powerful and easy to express as monads (I later claimed and provided evidence that they're more powerful). There is actually much to debate about the relative merits of PFP and imperative, but I certainly wouldn't say that PFP is "avoiding badness". It's avoiding some badness while introducing other kinds of badness (monads have some serious disadvantages), while imperative programmers can avoid the same badness without resorting to PFP (e.g. as Clojure and Erlang do). [1]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.8213 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.8...
- lostcolony 11y ago
  I agree; I'm handwaving at the definition. FP as a 'thing' doesn't really exist, but we recognize languages that more and more embrace pure FP as an ideal, and require greater and greater concessions away from imperative programming. There is likely a sweet spot in that continuum, but from someone solidly on the imperative side, the people falling somewhere on that continuum can appear arrogant, due to what imperative bits they have given up, even if it's not ~all~ the bits.
- DanWaterworth 11y ago
  > I challenge you to find a definition for FP that includes Clojure, Erlang, F#, and OCaml but excludes Java, JS, Ruby, Python, C++ Challenge accepted: FP languages emphasise restriction of mutation.
tel 11y ago
There's at least one bit that goes further than you've noted and while it has an analogue in vegetarianism, it's much more important to note in FP. It's this: language choice is often a shared/communal one. Therefore, it's required not only to find personal reasons for the choice but also to convince a not insignificant number of your colleagues to make the same choice. This means that some portion of language advocacy is a war for survival in a way that vegetarianism isn't (at least until you have to choose what restaurant to go to with some vegetarians in the crowd—tension grows). (To be clear, I'm just noting this, not trying to be a proponent of it!) So that fuels asshole behaviors because one wants to find a justification not only that an alternative exists and works but that it is actually better. So it's not just a matter of coming off as arrogant but there actually being a seed of truth to that claim. Now what I feel makes PL debates remarkably dangerous is that theres a prevalent idea that PL all comes down to taste---therefore anyone who is trying to make a PL sale is peddling snake oil at least partially. Every action they take is therefore hostile in that it is impossible for them to offer a legitimate cure. In honesty, that idea is completely false. Language really matters a ton and is merely a very complex decision not a meaningless one. Each language offers its own sets of cures and downsides and actual decisions are tricky. So when an FPer comes with arguments, legitimate but complex ones, that FP significantly improves programming experience/outputs then making the trade-analysis to your personal needs is a big undertaking. When, further, they do this with at least some motive to convert you, it's a forced, big undertaking. Finally, when you balk a bit at the potentially massive investment with uncertain return involved in analyzing a new language for a project and this is thrown back at you as a failure to recognize the legitimate value of FP. Well, that's easy to see as asshole-y. What makes a language community fun? Lots of ways to get started, lots of positive, non-forced examples of benefits, and a community oriented around perfecting their own trade not proselytization. Once you start heading out of those bounds you pick up assholes.
- vanderZwan 11y ago
  > There's at least one bit that goes further than you've noted and while it has an analogue in vegetarianism, it's much more important to note in FP. It's this: language choice is often a shared/communal one. Well, so is food. I'd say you just gave a good argument for why the analogy is even more on point that it might appear at first!
mavelikara 11y ago
Your comment is about pure functional programing, which the linked article does not explicitly talk about. But even functional programing with mutable state has some pointing-and-laughing going on - for example, here: http://i.imgur.com/FM2DXkf.png http://i.imgur.com/FM2DXkf.png.
- babygoat 11y ago
  Nor does the linked article explicitly talk about so-called "mostly functional" programming, but lostcolony's comment is on point either way. Is there some context around your linked meme that implies mutable state or pointing-and-laughing?
- steego 11y ago
  I think this is a slide where people really have missed the joke. Scott Wlaschin does an excellent presentation on Function Programming Design Patterns (http://www.slideshare.net/ScottWlaschin/fp-patterns-ndc-london2014 http://www.slideshare.net/ScottWlaschin/fp-patterns-ndc-lond...) where he talks about using functional patterns to properly model domains. I suspect Scott did a search on "Design Patterns" and "F#" to see what was already out there. He was probably frustrated that the only thing he saw were references and translations of GoF design patterns. From what I gather, Scott's slide was a funny way of getting out of the way that his presentation was not going to be another thing about translating GoF design patterns to F#. (Full disclosure, I actually did that presentation here: http://sgoguen.github.io/presentations/FS-Patterns-2/#16 http://sgoguen.github.io/presentations/FS-Patterns-2/#16) UPDATE: Just confirmed with Scott that was the inspiration of this slide and joke.
jasode 11y ago
>To people who use those things avoided, it comes off as arrogant. [...] , the listener who uses mutable state views the FP's attitude as judgemental I disagree with your meta-analysis of where the root of perceiving "arrogance" comes from. (I'll shall attempt to speak for non-practicing functional programmers and the following opinion is not my own.) In my observations, it's that all the essays and evangelizations about functional programming do not manifest themselves in the industry as irrefutable evidence that it creates better programs, with less bugs, at higher rates of productivity. For example, folks can point to Jane Street using OCaml, or a London finance shop using F#, but are they doing 10x better than Goldman Sachs using the clunky C++ language? Maybe. But we won't know because there are too many confounding factors. Functional programmers can repeat all the "benefits" of the style with "immutable", and "referential transparency", "monads", etc, and describe languages in glowing terms such as "Haskell has this beautiful internal mathematical consistency that Java doesn't" or "Lisp with its homoiconicity lets you write a DSL as first-class concepts with macros whereas C++ makes you force-fit them into classes", etc, etc. All those bullet points may be true but it doesn't manifest itself as obvious slam dunk winnings in the industry. That's the root of the arrogance: the attitude of "superiority" about functional ideas does not match what people see on the street. In other words, people wonder why there are no AAA game studios using functional programming that blows everyone else out of the water crawling on their hands & knees with C++. Or some application software company using Haskell to deliver software with 10x less bugs, 10x faster, and 1/10th less cost than their competitors using Java. Or some YC company using 100% functional language and killing their competitors stupidly using Python/PHP. So far, there are hundreds (thousands?) of tutorials about monads and recursive Fibonacci snippets but very few case studies (if any) of real companies killing the competition as a direct result of the functional programming language. Companies showing massive industry results is how you win hearts & minds. Fibonacci exercises are not enough. What the functional community needs are better essays that go beyond "monads" and addresses why the mystery gap exists between functional theory and industry results. My guess is that the functional benefits are real but there are other aspects of software craft that overwhelm its advantages. In other words, the essays needs to look at functional style holistically. As a historical analogy, the benefits of structured programming languages vs machine language were initially debated in 1960s. However, within less than a decade, everyone adopted it because the multiplication of productivity was obvious and compelling. The ease of programming wasn't just a 10x improvement, it was arguably a 100x improvement. Now, assembly is only done for isolated pockets of tight loops and resource constrained scenarios. If the FP>OOP is similar to Structured>Assembly, then for some reason, the real world has not shown that same magnitude of increased benefits. Fix that perception and the root of "arrogance" goes away. Today, we don't say one is "arrogant" for explaining that structured programming will allow teams to write software faster with less bugs. Imo, that's the type of self-reflection that functional essays are missing.
sklogic 11y ago
> FP is largely defined by what it avoids Why? FP is just a theory of computing, equivalent to all the other existing theories. It allows to do some analysis which is not that simple with the other theories (and it is crappy with the other important analysis methods, most notoriously with complexity analysis). It does not "add" or "avoid" anything at all.
- babygoat 11y ago
  Because many people think of it and define it in terms of how it differs from the paradigm that they're familiar with, and because people often incorporate functional programming concepts into imperative program designs.
- tel 11y ago
  It's not actually crappy at all for complexity analysis. Laziness is sometimes spoken about in that way, but nobody is forcing you to be lazy.
  - sklogic 11y ago
    Yet, Turing machine is much easier and is almost always a first choice for a complexity research. Of course, it heavily depends on a nature of an algorithm.
    - tel 11y ago
      I'm not confident that it's much easier in any universal sense, but I certainly agree that the nature of at least the presentation of an algorithm defines the easiest way to talk about its analysis.
    - deleted 11y ago
      [deleted]
Chattered 11y ago
That FP subtracts from everything else can be switched around pretty easily. If you, as a client, can prove that you do not mutate the data structure that I hand back to you, then I don't have to worry about you corrupting my alias of it, and I don't have to worry about giving you a deep-copy instead of a direct reference. Pure functional programming subtracts something from your expressive power, but it also subtracts from the assumptions you have to make about code. Less expressive power is a bad thing, but fewer assumptions are a good thing. The inequality of assumption versus conclusion is right there in the functional arrow. I'm not sure I can easily work the vegetarian analogy into that. Vegetarians notoriously frustrate catering, while I think people who agree never to mutate data are probably easier for programmers to cater for.

agumonkey 11y ago

That's the basis of an essay I'm writing. Derivation of FP from ImpP by progressive enhancement through mutation avoidance.

JimmyM 11y ago
That sounds really interesting, there was a similar approach (albeit somewhat implicit rather than explicit) in the Programming Languages Coursera course. Where do you think I would be able to read the essay when it's complete? Will there be a great deal of mathematics in there? (I have a poor/loose grasp of anything past high school mathematics, barring algorithms).
- agumonkey 11y ago
  If I ever finish it I'll tweet it. There won't be a lot, I'm a barely educated noob with distate for out of reach abstraction. And I see a simple migration path from imperative to functional. If you have no college education about programming languages it might be interesting to test if my ideas are worth reading and actually effective.
  - steveklabnik 11y ago
    You might be interested in reading "Teaching Programming with the Kernel Language Approach" by Van Roy and Haridi.
    - agumonkey 11y ago
      Is it different from CTM ? ps: just read this https://www.info.ucl.ac.be/~pvr/fdpefinalweb.pdf https://www.info.ucl.ac.be/~pvr/fdpefinalweb.pdf it seem they extends the SICP approach, substitution -> state | concurrency ... I planned to do the opposite. state -> subst
      - steveklabnik 11y ago
        They're very close to each other, the paper just presents the method directly, whereas the CTM is a book-length application of the method. Yeah, I guess it is in the opposite direction. I was mostly thinking in terms of describing a language in terms of another via 'progressive enhancement'.
        agumonkey 11y ago
        Yeah, the idea is similar, but I really meant to show how similar FP was to ImP by starting from what's familiar to non FP programmers.

DanWaterworth 11y ago

As both a vegetarian and functional programmer, I totally agree.

amalag 11y ago

The vegetarian bit is a nice analogy. Sometimes stating the truth comes off as being judgemental because the implications are obvious.

tsmarsh 11y ago
I'm a meat eater due to my biology more than anything else, I love the taste and I'm allergic to most fruits and vegetables (ORA). Before the degree of my ORA was known, I did play at being vegetarian for 6 months for ecological, not moral reasons. I don't see a moral difference between eating a fruit and and an egg, or salmon and a herb, milk/blood and maple syrup. The arguments that fauna are somehow more alive than fauna has never felt very strong to me. We've all been evolving and finding our niche for about the same amount of time. We've all got our own versions of response to external stimuli. Its just much harder to empathize with an apple tree than a chicken, especially when it comes to the ultimate sacrifice. However, the ecological arguments for vegetarianism around sustainability and CO2 emission seem sound for the standard american lifestyle. Of course that starts to flip if you hunt (I don't). Large scale agriculture does more damage to the environment than culling native mega fauna, which is arguably beneficial. It flips again, if you have your own garden, supplemented by local, organic specialists. And then you reach a much better level of reuse/yield if you can feed scraps to chickens and pigs and fertilize your ground with blood and bone meal. (it always makes me laugh when vegans think their organic vegetables are 'cruelty free'). So, no. I don't think the implications of saying you are vegetarian are immediately obvious. The more I research it, the healthier and more sustainable a diet of mostly fruit and vegetables supplemented by the meat of a couple of pigs, 6 or so chickens and the occasional hunt seems to be. But if you genuinely believe that fauna are some how better than flora I guess that simplifies the equation and somewhere down that path you get labelled a zealot. I suspect the same is true with programming. What you want is a system of mostly functional business logic that is supplemented with objects when it makes sense (modeling the state of an electrical circuit?!?), and the odd 'declarative hunting trip' when you need to cull the date from the database :) It is possible exist on just objects, or just functions but variety is the spice of life and the sum is often greater than the whole.
- sshine 11y ago

bluetomcat 11y ago

The thing is, CPUs are designed to execute imperative programs. A stream of instructions is imperative. Until we see real hardware that executes functional programs, FP will always be somehow treated as a second-class citizen in the computing world.

gagege 11y ago
The thing is, CPUs are designed to execute imperative programs. A stream of instructions is imperative. Until we see real hardware that executes object-oriented programs, OOP will always be somehow treated as a second-class citizen in the computing world. Everything we do is an abstraction.
- bluetomcat 11y ago
  Abstractions sometimes do not match well with the underlying abstractions that they depend on. The Von Neumann architecture is all about state and mutability, and yet FP tries to stay as far as it can from that. OOP is really a supplement layer over imperative programming and doesn't deny any of its underpinnings.
  - Retra 11y ago
    Abstractions necessarily do not match the underlying infrastructure. That's why they are called abstractions. That's also why we use them: because we don't want to be bound by underlying infrastructure. PS: Computers are not inherently digital, either.
  - dragonwriter 11y ago
    > The Von Neumann architecture is all about state and mutability, and yet FP tries to stay as far as it can from that. As I understand it, real world FP isn't about "staying away from" state and mutability, its about providing tools for managing state and mutability as a means to manage the complexity of reasoning about programs using it. E.g., Haskell's monadic approach essentially makes every Haskell program one that produces (as the result of the main function) the imperative program that is actually executed by the runtime.

altcognito 11y ago

Re: Vegetarianism. Because there is technically no need to say "I don't want to have animals killed on my behalf." That statement adds no extra information about their diet, it only says that if they were eating meat, they would be having animals killed on their behalf.

lostcolony 11y ago
shrug Fine. Assume they leave that bit off. In fact, assume they give no rationale at all. You're trying to figure out where to eat, and someone suggests a steakhouse, and someone else says "Er, I'm a vegetarian". Some people will get defensive of that, even with nothing further. The person didn't bring up that they were vegetarian pre-emptively, it was absolutely in the right context, it was in no way judgemental, it was not even saying -why-, and yet, many people get defensive. "Oh, man, I could never do that; I love meat too much", "Pff, you and your rabbit food", "How do you get enough protein? You know that's unhealthy, right?", etc.
- altcognito 11y ago
  It's odd when people get defensive about it when you just say you're vegetarian, but I know it happens. My SO was vegetarian for 14 years and this happened from time to time. Sometimes the comment that having animals killed on your behalf is a flag that this person thinks it is amoral to kill animals for food. Meat is murder after all. I recognize very much so that not all vegetarians are like that.
- tremendo 11y ago
  I also have a definite preference about what I allow into my digestive system, but if I happen to be in a group that, as a group, expresses a preference for where to go for a meal, I'll be flexible and eat the best way possible within the given constraints. Surely even a steakhouse has salads. Too frequent deviations of late? politely suggest an alternative or, decline to partake this time. No need to impose one's particular preferences, which is why it comes off the way it does.
mcguire 11y ago
...which is true. And only a problem if you're defensive about it.

KingMob 11y ago

Interesting. As a former vegetarian, I was always a little surprised when someone would take offense at my vegetarianism, even if I hadn't said anything. They just assumed there was a critique implied.

eli_gottlieb 11y ago

I disagree. I've programmed in plenty of languages with mutable state and found myself desperately wishing for the power of lambdas, function combinators, comprehensions, and other higher-order constructs from functional programming. I'd really much rather have `map f xs` than `for(x : xs) result.add(f(x));`.

lostcolony 11y ago
I'm not saying that the ideas that came out of FP don't have beneficial use even in the imperative world, but that they are -necessary- in FP, because you've given up the imperative approaches.
toast0 11y ago
Most 'non-fuctional' languages have function pointers too, it just might be less idiomatic.
pron 11y ago
Mutable state and what we call FP aren't at all mutually exclusive. In fact, most languages which we call functional are imperative (i.e. they're imperative-functional). One of the first languages I used was Scheme which had plenty of mutable state as well as higher-order functions etc. Today, most OO languages have all those as well, and the mother-of-all-OOP, Smalltalk, had them all before the name "functional" even became fashionable.

pron 11y ago

FP is not defined at all. Pure FP (PFP) has a clear definition, but I challenge you to find a definition for FP that includes Clojure, Erlang, F#, and OCaml but excludes Java, JS, Ruby, Python, C++. All of these languages are imperative with varying amounts of reliance on higher-order functions and emphasis on immutability (for example, my favorite so-called-FP language, Clojure, allows global mutation all over the place, but provides some transactional assurances). Second, even if we consider PFP alone (which is, indeed, different from imperative programming), I often find that some of its proponents are lacking in understanding of the theoretical underpinnings of imperative programming. For example, day before yesterday I gave a talk at CurreyOn/ECOOP about why monads are harmful in imperative languages (i.e. any language that isn't PFP), and PFP experts present weren't aware (although, TBH, neither was I, but I'm not a PL researcher) of this proof[1] that imperative continuations are at least as powerful and easy to express as monads (I later claimed and provided evidence that they're more powerful). There is actually much to debate about the relative merits of PFP and imperative, but I certainly wouldn't say that PFP is "avoiding badness". It's avoiding some badness while introducing other kinds of badness (monads have some serious disadvantages), while imperative programmers can avoid the same badness without resorting to PFP (e.g. as Clojure and Erlang do). [1]: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.8213 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.8...

lostcolony 11y ago
I agree; I'm handwaving at the definition. FP as a 'thing' doesn't really exist, but we recognize languages that more and more embrace pure FP as an ideal, and require greater and greater concessions away from imperative programming. There is likely a sweet spot in that continuum, but from someone solidly on the imperative side, the people falling somewhere on that continuum can appear arrogant, due to what imperative bits they have given up, even if it's not ~all~ the bits.
DanWaterworth 11y ago
> I challenge you to find a definition for FP that includes Clojure, Erlang, F#, and OCaml but excludes Java, JS, Ruby, Python, C++ Challenge accepted: FP languages emphasise restriction of mutation.

tel 11y ago

There's at least one bit that goes further than you've noted and while it has an analogue in vegetarianism, it's much more important to note in FP. It's this: language choice is often a shared/communal one. Therefore, it's required not only to find personal reasons for the choice but also to convince a not insignificant number of your colleagues to make the same choice. This means that some portion of language advocacy is a war for survival in a way that vegetarianism isn't (at least until you have to choose what restaurant to go to with some vegetarians in the crowd—tension grows). (To be clear, I'm just noting this, not trying to be a proponent of it!) So that fuels asshole behaviors because one wants to find a justification not only that an alternative exists and works but that it is actually better. So it's not just a matter of coming off as arrogant but there actually being a seed of truth to that claim. Now what I feel makes PL debates remarkably dangerous is that theres a prevalent idea that PL all comes down to taste---therefore anyone who is trying to make a PL sale is peddling snake oil at least partially. Every action they take is therefore hostile in that it is impossible for them to offer a legitimate cure. In honesty, that idea is completely false. Language really matters a ton and is merely a very complex decision not a meaningless one. Each language offers its own sets of cures and downsides and actual decisions are tricky. So when an FPer comes with arguments, legitimate but complex ones, that FP significantly improves programming experience/outputs then making the trade-analysis to your personal needs is a big undertaking. When, further, they do this with at least some motive to convert you, it's a forced, big undertaking. Finally, when you balk a bit at the potentially massive investment with uncertain return involved in analyzing a new language for a project and this is thrown back at you as a failure to recognize the legitimate value of FP. Well, that's easy to see as asshole-y. What makes a language community fun? Lots of ways to get started, lots of positive, non-forced examples of benefits, and a community oriented around perfecting their own trade not proselytization. Once you start heading out of those bounds you pick up assholes.

vanderZwan 11y ago
> There's at least one bit that goes further than you've noted and while it has an analogue in vegetarianism, it's much more important to note in FP. It's this: language choice is often a shared/communal one. Well, so is food. I'd say you just gave a good argument for why the analogy is even more on point that it might appear at first!

mavelikara 11y ago

Your comment is about pure functional programing, which the linked article does not explicitly talk about. But even functional programing with mutable state has some pointing-and-laughing going on - for example, here: http://i.imgur.com/FM2DXkf.png http://i.imgur.com/FM2DXkf.png.

babygoat 11y ago
Nor does the linked article explicitly talk about so-called "mostly functional" programming, but lostcolony's comment is on point either way. Is there some context around your linked meme that implies mutable state or pointing-and-laughing?
steego 11y ago
I think this is a slide where people really have missed the joke. Scott Wlaschin does an excellent presentation on Function Programming Design Patterns (http://www.slideshare.net/ScottWlaschin/fp-patterns-ndc-london2014 http://www.slideshare.net/ScottWlaschin/fp-patterns-ndc-lond...) where he talks about using functional patterns to properly model domains. I suspect Scott did a search on "Design Patterns" and "F#" to see what was already out there. He was probably frustrated that the only thing he saw were references and translations of GoF design patterns. From what I gather, Scott's slide was a funny way of getting out of the way that his presentation was not going to be another thing about translating GoF design patterns to F#. (Full disclosure, I actually did that presentation here: http://sgoguen.github.io/presentations/FS-Patterns-2/#16 http://sgoguen.github.io/presentations/FS-Patterns-2/#16) UPDATE: Just confirmed with Scott that was the inspiration of this slide and joke.

jasode 11y ago

>To people who use those things avoided, it comes off as arrogant. [...] , the listener who uses mutable state views the FP's attitude as judgemental I disagree with your meta-analysis of where the root of perceiving "arrogance" comes from. (I'll shall attempt to speak for non-practicing functional programmers and the following opinion is not my own.) In my observations, it's that all the essays and evangelizations about functional programming do not manifest themselves in the industry as irrefutable evidence that it creates better programs, with less bugs, at higher rates of productivity. For example, folks can point to Jane Street using OCaml, or a London finance shop using F#, but are they doing 10x better than Goldman Sachs using the clunky C++ language? Maybe. But we won't know because there are too many confounding factors. Functional programmers can repeat all the "benefits" of the style with "immutable", and "referential transparency", "monads", etc, and describe languages in glowing terms such as "Haskell has this beautiful internal mathematical consistency that Java doesn't" or "Lisp with its homoiconicity lets you write a DSL as first-class concepts with macros whereas C++ makes you force-fit them into classes", etc, etc. All those bullet points may be true but it doesn't manifest itself as obvious slam dunk winnings in the industry. That's the root of the arrogance: the attitude of "superiority" about functional ideas does not match what people see on the street. In other words, people wonder why there are no AAA game studios using functional programming that blows everyone else out of the water crawling on their hands & knees with C++. Or some application software company using Haskell to deliver software with 10x less bugs, 10x faster, and 1/10th less cost than their competitors using Java. Or some YC company using 100% functional language and killing their competitors stupidly using Python/PHP. So far, there are hundreds (thousands?) of tutorials about monads and recursive Fibonacci snippets but very few case studies (if any) of real companies killing the competition as a direct result of the functional programming language. Companies showing massive industry results is how you win hearts & minds. Fibonacci exercises are not enough. What the functional community needs are better essays that go beyond "monads" and addresses why the mystery gap exists between functional theory and industry results. My guess is that the functional benefits are real but there are other aspects of software craft that overwhelm its advantages. In other words, the essays needs to look at functional style holistically. As a historical analogy, the benefits of structured programming languages vs machine language were initially debated in 1960s. However, within less than a decade, everyone adopted it because the multiplication of productivity was obvious and compelling. The ease of programming wasn't just a 10x improvement, it was arguably a 100x improvement. Now, assembly is only done for isolated pockets of tight loops and resource constrained scenarios. If the FP>OOP is similar to Structured>Assembly, then for some reason, the real world has not shown that same magnitude of increased benefits. Fix that perception and the root of "arrogance" goes away. Today, we don't say one is "arrogant" for explaining that structured programming will allow teams to write software faster with less bugs. Imo, that's the type of self-reflection that functional essays are missing.

sklogic 11y ago

> FP is largely defined by what it avoids Why? FP is just a theory of computing, equivalent to all the other existing theories. It allows to do some analysis which is not that simple with the other theories (and it is crappy with the other important analysis methods, most notoriously with complexity analysis). It does not "add" or "avoid" anything at all.

babygoat 11y ago
Because many people think of it and define it in terms of how it differs from the paradigm that they're familiar with, and because people often incorporate functional programming concepts into imperative program designs.
tel 11y ago
It's not actually crappy at all for complexity analysis. Laziness is sometimes spoken about in that way, but nobody is forcing you to be lazy.
- sklogic 11y ago
  Yet, Turing machine is much easier and is almost always a first choice for a complexity research. Of course, it heavily depends on a nature of an algorithm.
  - tel 11y ago
    I'm not confident that it's much easier in any universal sense, but I certainly agree that the nature of at least the presentation of an algorithm defines the easiest way to talk about its analysis.
  - deleted 11y ago
    [deleted]

Chattered 11y ago

That FP subtracts from everything else can be switched around pretty easily. If you, as a client, can prove that you do not mutate the data structure that I hand back to you, then I don't have to worry about you corrupting my alias of it, and I don't have to worry about giving you a deep-copy instead of a direct reference. Pure functional programming subtracts something from your expressive power, but it also subtracts from the assumptions you have to make about code. Less expressive power is a bad thing, but fewer assumptions are a good thing. The inequality of assumption versus conclusion is right there in the functional arrow. I'm not sure I can easily work the vegetarian analogy into that. Vegetarians notoriously frustrate catering, while I think people who agree never to mutate data are probably easier for programmers to cater for.