7 ms·

Why Why Functional Programming Matters Matters (2007)

141 points by olalonde 12y ago

icebraining 12y ago
(2007)
deleted 12y ago
[deleted]
jonahx 12y ago
Related: Does anyone know of an html / epub / mobi link to the original paper (I could find only the pdf)?
- deleted 12y ago
  [deleted]
- tim333 12y ago
  Google cache? http://webcache.googleusercontent.com/search?q=cache:ucpR8GcbVSEJ:worrydream.com/refs/Hughes-WhyFunctionalProgrammingMatters.pdf+&cd=1&hl=en&ct=clnk&gl=uk http://webcache.googleusercontent.com/search?q=cache:ucpR8Gc...
vorbote 12y ago
Better formatted version of the blog post: http://raganwald.com/2014/12/20/why-why-functional-programming-matters-matters.html http://raganwald.com/2014/12/20/why-why-functional-programmi... The original paper by John Huges mentioned in the posting: Internet Archive: https://web.archive.org/web/20070323095313/http://www.math.chalmers.se/~rjmh/Papers/whyfp.html https://web.archive.org/web/20070323095313/http://www.math.c... PostScript, PDF and the BibTeX reference.
- chii 12y ago
  google has a better pdf viewer: https://drive.google.com/file/d/1nYvECWLSzedsMew0INhv3tLhwutLNUxUy3STz4M6KvquaLLGKv7BO0XKepw5/view?usp=sharing https://drive.google.com/file/d/1nYvECWLSzedsMew0INhv3tLhwut...
westoncb 12y ago
While reading, it made me think: It’s important when approaching architecture—and probably software problems in general—that you do not start by reasoning in terms of the constructs of a particular language (e.g. classes and interfaces). The philosophy underlying this is: your range of potential conceptions becomes wider as abstraction increases; and, as you become more concrete you inevitably introduce auxiliary problems that result purely from the features of the particular language you are expressing with, which means you are prematurely diverting thought from, “what is the correct description of this thing” to, “what is the best wording for this description”. Also: Working at a higher level of abstraction has a lot in common with looking at a scene from far away, a mountain range for instance: the further away you get, the easier it becomes to change which mountain you are experiencing: you merely turn your head a quarter of an inch and now three new mountains have entered your consciousness. If you’re trying to decide which mountain to climb, this is an extraordinary benefit—but at the same time, if you are too far away, you can’t perceive the features of the mountain clearly enough for optimal decision making. A similar tradeoff is always present in working at one level of abstraction or another, and understanding these tradeoffs helps you figure out where to stand more effectively.
fjarlq 12y ago
As an additional exploration of these excellent ideas, I recommend the textbook How to Design Programs (HtDP): https://en.wikipedia.org/wiki/How_to_Design_Programs https://en.wikipedia.org/wiki/How_to_Design_Programs It's available online: http://htdp.org/ http://htdp.org/
- mixmastamyk 12y ago
  Is there a .pdf of the latest version? Couldn't find.
  - twic 12y ago
    The latest version is a work in progress - for example, near the start of chapter VI we find "The rest of this chapter is under development. Use HtDP/1e in the meantime.". I wouldn't be surprised if there wasn't a PDF version until it was finished.
einhverfr 12y ago
It's a good paper, but what it hints at (but doesn't really come out and say) is that in separating concerns, functional programming actually eliminates concerns from the programmer. This isn't really just a question of the language -- you can do FP in any language. But by thinking about programming differently, we can eliminate concerns entirely. This is what garbage collection does, and it is what FP does.
- codygman 12y ago
  > you can do FP in any language Depends on your definition of functional programming.
  - einhverfr 12y ago
    This is true. However.... The basic premise that you are operating with mathematical functions, which allow you to reason equationally can be done in any language. Of course when you move from C to Perl you pick up a lot of power in what you can do functionally, and when you move from Perl to Common Lisp you pick up even more, and when you move to Scala or Haskell, you pick up even more from what I have seen. But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too.
    - codygman 12y ago
      > But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too. This statement is only true depending on what you mean by OOP. For instance see this post[0] implementing minimal OOP with scheme. 0: http://robots.thoughtbot.com/you-could-invent-objectoriented-programming http://robots.thoughtbot.com/you-could-invent-objectoriented...
      - einhverfr 12y ago
        This is also true. OOP in Java is certainly not the same as OOP using CLOS, and not the same as Perl and Moose. But there is a common thread through these. Namely with OOP, you are tying structure and behavior together so that behavior can encapsulate structure. OOP, like FP, isn't so much "a paradigm" as a "family of paradigms," one or more per language.
thibauts 12y ago
To me what makes functional programming matter and what differentiates it from OOP today is less its essential properties than the simple fact that it pushes you to think in terms of functions that process collections of objects rather than functions that act on a single one. This may look like a simple statement yet the implications are huge. Now it doesn't reflect a property of FP as such, it only highlights one of the biggest shortcomings of OOP along mutability that we are slowly awakening to as a community.
snarfy 12y ago
Pure functional programs either don't work or are bug free. At a high level the entire app can be viewed as one continuous evaluation, which is kind of beautiful. It could transfer to an FPGA without needing a von nuemann simulation.
- mercurial 12y ago
  FP isn't a silver bullet. A statically-typed function language with a strong type system will keep some classes of issues away. It will not, however, prevent logic errors or infinite loops or resource leaking.

141 points by olalonde 12y ago

icebraining 12y ago

(2007)

deleted 12y ago

[deleted]

jonahx 12y ago

Related: Does anyone know of an html / epub / mobi link to the original paper (I could find only the pdf)?

deleted 12y ago
[deleted]
tim333 12y ago
Google cache? http://webcache.googleusercontent.com/search?q=cache:ucpR8GcbVSEJ:worrydream.com/refs/Hughes-WhyFunctionalProgrammingMatters.pdf+&cd=1&hl=en&ct=clnk&gl=uk http://webcache.googleusercontent.com/search?q=cache:ucpR8Gc...

vorbote 12y ago

Better formatted version of the blog post: http://raganwald.com/2014/12/20/why-why-functional-programming-matters-matters.html http://raganwald.com/2014/12/20/why-why-functional-programmi... The original paper by John Huges mentioned in the posting: Internet Archive: https://web.archive.org/web/20070323095313/http://www.math.chalmers.se/~rjmh/Papers/whyfp.html https://web.archive.org/web/20070323095313/http://www.math.c... PostScript, PDF and the BibTeX reference.

chii 12y ago
google has a better pdf viewer: https://drive.google.com/file/d/1nYvECWLSzedsMew0INhv3tLhwutLNUxUy3STz4M6KvquaLLGKv7BO0XKepw5/view?usp=sharing https://drive.google.com/file/d/1nYvECWLSzedsMew0INhv3tLhwut...

westoncb 12y ago

While reading, it made me think: It’s important when approaching architecture—and probably software problems in general—that you do not start by reasoning in terms of the constructs of a particular language (e.g. classes and interfaces). The philosophy underlying this is: your range of potential conceptions becomes wider as abstraction increases; and, as you become more concrete you inevitably introduce auxiliary problems that result purely from the features of the particular language you are expressing with, which means you are prematurely diverting thought from, “what is the correct description of this thing” to, “what is the best wording for this description”. Also: Working at a higher level of abstraction has a lot in common with looking at a scene from far away, a mountain range for instance: the further away you get, the easier it becomes to change which mountain you are experiencing: you merely turn your head a quarter of an inch and now three new mountains have entered your consciousness. If you’re trying to decide which mountain to climb, this is an extraordinary benefit—but at the same time, if you are too far away, you can’t perceive the features of the mountain clearly enough for optimal decision making. A similar tradeoff is always present in working at one level of abstraction or another, and understanding these tradeoffs helps you figure out where to stand more effectively.

fjarlq 12y ago

As an additional exploration of these excellent ideas, I recommend the textbook How to Design Programs (HtDP): https://en.wikipedia.org/wiki/How_to_Design_Programs https://en.wikipedia.org/wiki/How_to_Design_Programs It's available online: http://htdp.org/ http://htdp.org/

mixmastamyk 12y ago
Is there a .pdf of the latest version? Couldn't find.
- twic 12y ago
  The latest version is a work in progress - for example, near the start of chapter VI we find "The rest of this chapter is under development. Use HtDP/1e in the meantime.". I wouldn't be surprised if there wasn't a PDF version until it was finished.

einhverfr 12y ago

It's a good paper, but what it hints at (but doesn't really come out and say) is that in separating concerns, functional programming actually eliminates concerns from the programmer. This isn't really just a question of the language -- you can do FP in any language. But by thinking about programming differently, we can eliminate concerns entirely. This is what garbage collection does, and it is what FP does.

codygman 12y ago
> you can do FP in any language Depends on your definition of functional programming.
- einhverfr 12y ago
  This is true. However.... The basic premise that you are operating with mathematical functions, which allow you to reason equationally can be done in any language. Of course when you move from C to Perl you pick up a lot of power in what you can do functionally, and when you move from Perl to Common Lisp you pick up even more, and when you move to Scala or Haskell, you pick up even more from what I have seen. But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too.
  - codygman 12y ago
    > But just as you can do object-oriented programming in C (a language really not designed for it), you can do functional programming in a lot of languages not really designed for it too. This statement is only true depending on what you mean by OOP. For instance see this post[0] implementing minimal OOP with scheme. 0: http://robots.thoughtbot.com/you-could-invent-objectoriented-programming http://robots.thoughtbot.com/you-could-invent-objectoriented...
    - einhverfr 12y ago
      This is also true. OOP in Java is certainly not the same as OOP using CLOS, and not the same as Perl and Moose. But there is a common thread through these. Namely with OOP, you are tying structure and behavior together so that behavior can encapsulate structure. OOP, like FP, isn't so much "a paradigm" as a "family of paradigms," one or more per language.

thibauts 12y ago

To me what makes functional programming matter and what differentiates it from OOP today is less its essential properties than the simple fact that it pushes you to think in terms of functions that process collections of objects rather than functions that act on a single one. This may look like a simple statement yet the implications are huge. Now it doesn't reflect a property of FP as such, it only highlights one of the biggest shortcomings of OOP along mutability that we are slowly awakening to as a community.

snarfy 12y ago

Pure functional programs either don't work or are bug free. At a high level the entire app can be viewed as one continuous evaluation, which is kind of beautiful. It could transfer to an FPGA without needing a von nuemann simulation.

mercurial 12y ago
FP isn't a silver bullet. A statically-typed function language with a strong type system will keep some classes of issues away. It will not, however, prevent logic errors or infinite loops or resource leaking.