Why Why Functional Programming Matters Matters (2007)

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• 12 years 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

It's available online: http://htdp.org/

mixmastamyk• 12 years ago

Is there a .pdf of the latest version? Couldn't find.

twic3• 12 years 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.

einhverfr7• 12 years 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.

codygman5• 12 years ago

you can do FP in any language

Depends on your definition of functional programming.

einhverfr7• 12 years 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.

coolsunglasses• 12 years ago

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.

coldtea2• 12 years ago

Consider than most software in actual use, changing the world and making millions is written in C/C++, those "benefits" must not be that many or that difficult to overcome...

And if the price we pay for this "worse is better" is buffer overflows and the ocassional crash and/or security exploit, that's hardly unsurmountable either. Life would be boring with perfectly perfoming programs anyway...

detaro• 12 years ago

What is the part of FP in Haskell you can't do in lets say C++?

EDIT: or to phrase it better, what is missing or hard to do that you feel has the biggest influence (some things are possible, but just way more complicated)? I don't have enough FP experience myself to judge that.

twic3• 12 years ago

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?

current_call• 12 years ago

No, you really can't do FP in any language.

"Please let’s not have a discussion about Turing Equivalence. Computer Science “Theory” tells us “there’s no such thing as more powerful.” Perhaps we share the belief that In theory, there’s no difference between theory and practice. But in practice, there is."

Programming paradigms are about how programs are written. If a problem can be solved in one language, it can be solved in every language, but that doesn't mean it can be solved in every paradigm in every language.

kaeluka2• 12 years ago

You make a claim here but don't back it up.

I think that a functional program, compiled to native code is STILL a functional program. You seem to not think that. Edit: If so, why?

Edit 2: Oh, maybe your point is that FP is statically typed?

thibauts• 12 years 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• 12 years 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• 12 years 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.

Why Why Functional Programming Matters Matters (2007)

Related Stories