
Why Why Functional Programming Matters Matters (2007) - olalonde
http://weblog.raganwald.com/2007/03/why-why-functional-programming-matters
======
westoncb
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.

------
vorbote
Better formatted version of the blog post:

[http://raganwald.com/2014/12/20/why-why-functional-
programmi...](http://raganwald.com/2014/12/20/why-why-functional-programming-
matters-matters.html)

The original paper by John Huges mentioned in the posting:

Internet Archive:
[https://web.archive.org/web/20070323095313/http://www.math.c...](https://web.archive.org/web/20070323095313/http://www.math.chalmers.se/~rjmh/Papers/whyfp.html)

PostScript, PDF and the BibTeX reference.

~~~
chii
google has a better pdf viewer:
[https://drive.google.com/file/d/1nYvECWLSzedsMew0INhv3tLhwut...](https://drive.google.com/file/d/1nYvECWLSzedsMew0INhv3tLhwutLNUxUy3STz4M6KvquaLLGKv7BO0XKepw5/view?usp=sharing)

------
thibauts
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.

------
fjarlq
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
Is there a .pdf of the latest version? Couldn't find.

~~~
twic
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
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.

~~~
coolsunglasses
>you can do FP in any language.

Not in my experience or that of my colleagues, no. I'm a Haskell user and
writing a book for learning Haskell. I'm friends with several Scalaz
developers including the creator and people that have worked on similar
libraries for other languages. I've also attempted to use FP idioms outside of
Haskell.

You can't take it with you. At best you'll learn to eschew a few bad habits,
but that's not FP nor does it bring anywhere near the same benefits.

~~~
twic
Nor in mine. I worked on some codebases in Java 6/7 with a team who yearned
for functional programming. They used various libraries that tried to support
a functional style - Guava for the moderates, FunctionalJava for the zealots,
lambdaj for those who liked to be different.

None of them really worked well (for functional programming - Guava is
excellent in other ways). Java just doesn't let you write the function-like
classes concisely enough for it to be worth breaking code down as far as you
need to to call it functional programming.

Plus, no higher-kinded types, so no functors. And what's functional
programming without functors and their kin?

~~~
einhverfr
Think about what following the most basic aspects of functional programming
would mean in Java:

1\. No private attributes (all state is transparent and immutable). 2\. All
methods that transform an object return a transformed copy. So instead of:

    
    
        rectangle.stretch_x(2.5);
    

you have:

    
    
        newRectangle = rectangle.stretched_x(2.5);
    

Even this very small move here moves you way outside Java as typically
programmed. This means further that even at this level (the most basic level
of FP), your program will:

1\. Be unable to work with standard libraries without mixing paradigms

2\. Be unable to be used in other projects because of the same problems.

Given that ABCL uses supertypes to allow round-trips between Java and Common
Lisp, I am fairly sure that functors should be _possible_ in Java, if not
elegant.

~~~
twic
You're conflating a couple of things here: encapsulating state, and mutability
of state. Your examples are about mutability. But immutability is already
standard practice in Java - standard enough that it's one of the items in Josh
Bloch's 2001 book 'Effective Java', the bible of righteous Java programmers:

[https://books.google.co.uk/books?id=ka2VUBqHiWkC&pg=PA73#v=o...](https://books.google.co.uk/books?id=ka2VUBqHiWkC&pg=PA73#v=onepage&q&f=false)

It's not usually pursued with the same rigour as in many functional languages,
but it would be absolutely normal to see a Rectangle class with a stretchedX
method which returns a new rectangle rather than mutates its receiver.

Now, you might argue that despite what Bloch, and every other good Java
programmer, says, "Java as typically programmed" still trades mostly in
mutable state. Since Java is actually widely used in the real world, it's
typically incompetently programmed, and so this is probably true.

Nonetheless, i am confident that Java code written using immutable objects
could both use and be used by other code. I say this because it's what i and
my colleagues have been doing for years.

I had a go at functors in Java a while ago. You're certainly right that it's
not elegant:

[https://news.ycombinator.com/item?id=7898294](https://news.ycombinator.com/item?id=7898294)

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

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

------
snarfy
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
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.

------
icebraining
(2007)

