5 ms·

The value of functional programming is not in what it brings, it's in what it takes away. It is easier to reason about functional programs because they maintai

The value of functional programming is not in what it brings, it's in what it takes away. It is easier to reason about functional programs because they maintain certain properties. These could be types, an absence of side effect, etc. This is the point of the entire article. You get none of those benefits if your "multi paradigm" language allows you to break those guarantees. For a multi paradigm language to derive benefits from functional programming, it should allow developers to explicitly write guarantees that can be enforced at compile time. This is a promising direction but, to my knowledge, it's not available in any of the languages you mentioned.

asonge 11y ago
I think this is exactly it. If you had a multi-paradigm language, you'd need not only just some way to break the rules easily and have that bubble up, you'd also want this rule-breaking behavior to be exposed up the chain from any libraries. You'd also have to enforce the benefits of immutability and such through social pressure in order for users to see large parts of the benefits of side-effect isolation. A lot of the choices FP languages make that are less about side-effects (like strict typing systems) are also often an all-or-none proposition. Optional typing systems have very limited benefits if libraries aren't well-typed. The static analyzers can only do so much.
- dozzie 11y ago
  Oh, they can do surprisingly much. See how Erlang works with its optional typespecs and dialyzer.
sohcahtoa 11y ago
Code Contracts for .NET, maybe?
the_af 11y ago
> The value of functional programming is not in what it brings, it's in what it takes away. That's what I used to think, and in fact I still think like that somewhat, but do note it's explicitly mentioned as a red herring in John Hughes' well-known and often quoted paper "Why Functional Programming Matters". From the paper: > Such a catalogue of “advantages” [things that FP lacks or constraints] is all very well, but one must not be surprised if outsiders don’t take it too seriously. It says a lot about what functional programming isn’t (it has no assignment, no side effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing. > [...] > Functional programmers argue that there are great material benefits — that a functional programmer is an order of magnitude more productive than his or her conventional counterpart, because functional programs are an order of magnitude shorter. Yet why should this be? The only faintly plausible reason one can suggest on the basis of these “advantages” is that conventional programs consist of 90% assignment statements, and in functional programs these can be omitted! This is plainly ridiculous. If omitting assignment statements brought such enormous benefits then Fortran programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be. He then goes on to argue that the real benefit of FP languages is that they excel at modularity, a widely agreed upon trait of good software, and that they have an excellent mechanism for "gluing" stuff together, i.e. lazy evaluation. (I've since read that some FP devs disagree about the importance Hughes placed on laziness).
- murbard2 11y ago
  I think he's refuting weak-men argument. Not quite straw-men because I've heard them being made. Of course it's about modularity, but how do you get modularity? How do you safely abstract the internals of libraries? Types and lack of side effects! It's also about correctness. Most of the time spent writing any complex bit of software is generally spent finding out what's wrong with it.
  - the_af 11y ago
    Agreed. I find Hughes' paper very interesting, but I disagree with him that "you cannot make something more powerful by removing things". Even philosophically this position is weak. It's self-evident to me you can make something more powerful/better by removing things. You can make something better by removing risks. You can make an UI saner by removing the possibility of invalid interactions. You can make art better by removing superfluous details. I still think that types and control of side effects is essential to (good) FP.
    - murbard2 11y ago
      - You can make the Library of Babel better by removing books.[1] - You can make limbs more useful by removing degrees of freedom, simplifying the control task.[2] [1] https://en.wikipedia.org/wiki/The_Library_of_Babel https://en.wikipedia.org/wiki/The_Library_of_Babel [2] http://www.ncbi.nlm.nih.gov/pubmed/16631583 http://www.ncbi.nlm.nih.gov/pubmed/16631583

asonge 11y ago

I think this is exactly it. If you had a multi-paradigm language, you'd need not only just some way to break the rules easily and have that bubble up, you'd also want this rule-breaking behavior to be exposed up the chain from any libraries. You'd also have to enforce the benefits of immutability and such through social pressure in order for users to see large parts of the benefits of side-effect isolation. A lot of the choices FP languages make that are less about side-effects (like strict typing systems) are also often an all-or-none proposition. Optional typing systems have very limited benefits if libraries aren't well-typed. The static analyzers can only do so much.

dozzie 11y ago
Oh, they can do surprisingly much. See how Erlang works with its optional typespecs and dialyzer.

sohcahtoa 11y ago

Code Contracts for .NET, maybe?

the_af 11y ago

> The value of functional programming is not in what it brings, it's in what it takes away. That's what I used to think, and in fact I still think like that somewhat, but do note it's explicitly mentioned as a red herring in John Hughes' well-known and often quoted paper "Why Functional Programming Matters". From the paper: > Such a catalogue of “advantages” [things that FP lacks or constraints] is all very well, but one must not be surprised if outsiders don’t take it too seriously. It says a lot about what functional programming isn’t (it has no assignment, no side effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing. > [...] > Functional programmers argue that there are great material benefits — that a functional programmer is an order of magnitude more productive than his or her conventional counterpart, because functional programs are an order of magnitude shorter. Yet why should this be? The only faintly plausible reason one can suggest on the basis of these “advantages” is that conventional programs consist of 90% assignment statements, and in functional programs these can be omitted! This is plainly ridiculous. If omitting assignment statements brought such enormous benefits then Fortran programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be. He then goes on to argue that the real benefit of FP languages is that they excel at modularity, a widely agreed upon trait of good software, and that they have an excellent mechanism for "gluing" stuff together, i.e. lazy evaluation. (I've since read that some FP devs disagree about the importance Hughes placed on laziness).

murbard2 11y ago
I think he's refuting weak-men argument. Not quite straw-men because I've heard them being made. Of course it's about modularity, but how do you get modularity? How do you safely abstract the internals of libraries? Types and lack of side effects! It's also about correctness. Most of the time spent writing any complex bit of software is generally spent finding out what's wrong with it.
- the_af 11y ago
  Agreed. I find Hughes' paper very interesting, but I disagree with him that "you cannot make something more powerful by removing things". Even philosophically this position is weak. It's self-evident to me you can make something more powerful/better by removing things. You can make something better by removing risks. You can make an UI saner by removing the possibility of invalid interactions. You can make art better by removing superfluous details. I still think that types and control of side effects is essential to (good) FP.
  - murbard2 11y ago
    - You can make the Library of Babel better by removing books.[1] - You can make limbs more useful by removing degrees of freedom, simplifying the control task.[2] [1] https://en.wikipedia.org/wiki/The_Library_of_Babel https://en.wikipedia.org/wiki/The_Library_of_Babel [2] http://www.ncbi.nlm.nih.gov/pubmed/16631583 http://www.ncbi.nlm.nih.gov/pubmed/16631583