
Functional Programming Is Hard, That's Why It's Good - trptcolin
http://dave.fayr.am/posts/2011-08-19-lets-go-shopping.html
======
tumult
FP is becoming the new OOP. People who don't understand its original meaning
are misinterpreting it and incorrectly expounding its usefulness. Newcomers
are not grasping how it fits into the bigger picture. Be cautious.

~~~
dustingetz
You know, I've learned something today!

When some people talk about functional programming, they talk about monads and
iterating with recursion and lambda calculus.

Other people talking about functional programming mean using data-oriented
abstractions, where functions operate on data in well-defined ways, to avoid
state and interlocked dependencies[3]. I've been calling the latter a
"functional style", but clearly there is ambiguity and people get turned off
and say things like "we're using an OO language why would i want FP"

in Avdi Grimm's talk "Confident Code"[2] he calls this style "narrative
structure", compared to "haphazard structure"[4]. I like that; "functional"
envokes all sorts of emotion about being hard to understand and unnecessary.
"Narrative" or "confident" or "data-oriented" are more articulate, and don't
evoke flame wars.

Avdi's example (code screenshot) is the most articulate example of this I've
yet seen. [https://lh4.googleusercontent.com/-Cs-
muD17ato/Tk6b1Rb9MwI/A...](https://lh4.googleusercontent.com/-Cs-
muD17ato/Tk6b1Rb9MwI/AAAAAAAAAeY/MTDO67H4r1c/s912/narrative-code-avdi-
grimm.png)

And it's in ruby. Nothing hard here, but it meets a functional style per John
D Cook's definition[1]: "OO makes code understandable by encapsulating moving
parts. FP makes code understandable by minimizing moving parts." "functional
in the small and OO in the large" seems a good path. The Scala community seems
to get this, and seems to me Scala is mainstreaming much quicker than any of
the pure functional languages.

[1] [http://www.johndcook.com/blog/2010/11/03/object-oriented-
vs-...](http://www.johndcook.com/blog/2010/11/03/object-oriented-vs-
functional-programming/) [2] [http://avdi.org/talks/confident-
code-2010-01-12/confident-co...](http://avdi.org/talks/confident-
code-2010-01-12/confident-code.html) [3] <http://www.dustingetz.com/how-to-
become-an-expert-swegr> [4] <http://www.dustingetz.com/confident-code-vs-
timid-code>

~~~
SoftwareMaven
_functional in the small and OO in the large" seems a good path._

That's what I like about Erlang as well. Once you recognize processes as your
objects, this philosophy just flows out of the language.

~~~
gclaramunt
But is taking a while for Erlang to come to terms with it...see Joe Armstrong
"Why OO sucks" (<http://www.sics.se/~joe/bluetail/vol1/v1_oo.html>)

------
mwexler
Ok, I've been a procedural programmer for years. I struggle even with OO.
Where's my easy bridge to Functional? Where's the killer "here's the trick,
the secret, the leap"?

Because I have to say, for all the "functional will save you" mantras, I keep
finding a procedural approach gets the problem solved. Are my problems too
simple? Not scale issues? Perhaps. And clearly, I am not trained in anything
other than intro Lisp and Hadoop, so I haven't had the deep dive
indoctrination others appear to have had.

But as each new computing metaphor comes, we find ways to make it easy for
folks trained in older metaphors to come over. Other than Scala, I've found
few bridges that are trying to help procedural and OO lang folks adopt
functional. It's no-one's fault, I guess, other than new folks are trained in
it, and older folks aren't.

But I'll keep looking for that bridge, that shining one thing that will make
me go "aahhha, I see" and not "one of these books will explain how passing
this function through this multi-nested other function is better than just
making a loop".

Because after all these articles, I know functional is great. I just feel bad
that I haven't been able to make it great for me... yet.

~~~
dustingetz
one of the cardinal rules of OO is: "each unit (method, object, whatever)
should do exactly one thing"[3]. this rule is universally ignored in all the
big OO codebases I've seen[1]. applying this rule with discipline, forces you
to have a better understanding of what your code is actually doing. I think,
that applying this rule even in OO languages forces you towards "functional-
style in the small, object-oriented in the large", and the only difference is
your code will have fewer classes/methods, and more high-level data-structures
with operations like list.filter on them.

[1] i get it, refactoring takes discipline and time, and desire to practice
and learn[2], and a team of like minded people, on top of sensible business
constraints. [2] [http://www.dustingetz.com/nostrademons-75h-work-week-
harmful...](http://www.dustingetz.com/nostrademons-75h-work-week-harmful-to-
personal-growth) [3]
<http://en.wikipedia.org/wiki/Single_responsibility_principle>

edit: added source for single-responsibility principle

~~~
SamReidHughes
That's not a cardinal rule of OO or even a rule of OO.

~~~
nahname
It is if you don't want to write side effect riddled 'objects'.

~~~
SamReidHughes
If it's a rule it's a rule of programming in general, not OO.

------
dasil003
The thing that got me really interested in learning Haskell was the
realization that something like 90% of the nasty bugs that I fixed in
production over the years would be have been impossible in a pure functional
language.

The thing that slows me down is the prospect of actually getting paid to write
Haskell, and my doubts about it's ultimate suitability for iterate-quickly,
fail-fast software world.

But reading this article reinvigorates me. Pure functional programming may be
much harder, but its rigor allows for more powerful abstractions. Grokking
those abstractions is no doubt useful regardless of what language you're
using.

~~~
thesz
>doubts about it's ultimate suitability for iterate-quickly, fail-fast
software world.

Lest you doubt: <http://thesz.mskhug.ru/svn/hiersort/doc/hhm-eng.pdf>

We did a cycle-accurate prototype of MIPS CPU with some twists. In Haskell.

For Haskell to shine in prototyping you have to apply it to some critical and
new task, where type system works with you, preventing errors. The novelty is
crucial, I think. You will have to explore the solution space with the help of
some sort of theorem prover (type system).

~~~
ThaddeusQuay2
"You will have to explore the solution space with the help of some sort of
theorem prover (type system)."

Have you tried ATS (Applied Type System)?

<http://en.wikipedia.org/wiki/ATS_(programming_language)>

~~~
thesz
No, I haven't. When I looked at it, I didn't see a well-composed thing like
Epigram or Agda2.

So I decided to stick to Haskell for a while and then slowly work my way to
Agda2, if I would feel the need.

------
rednum
It is worth noting that there are a few other paradigms that can change the
way you think of programming - recently there was a post providing a good
overview of languages that will make you learn some new abstractions,
functional programming being one of them:
<http://blog.fogus.me/2011/08/14/perlis-languages/>

------
vegai
I have done a few real, production projects with Haskell, and I've come to
realize that a lot of interest in it is hype. The paradigm is neat, the
language is relatively well designed (considering that it's an academic
committee language) and the implementation is passable.

Programmers sadly forget that the greatest challenge of software creation very
often happens outside of your text editor: it happens in the domain, in
architecture, specification and communication. If you succeed in those, your
project will succeed, no matter which language* you chose. If you fail in
them, no amount of strictness in your programming language will save you.

* _unless of course it's Java_

------
Dn_Ab
I see that some people are saying that functional programming is more powerful
than OOP. I disagree with that.

I do not think one is less than the other. Actually there is a mathematical
argument why one is not less than the other. To me functional programming is
"what does what I'm trying to describe do?". In object oriented programming
it's "what are the properties of the thing I'm trying to describe?". In
functional programming I describe the interactions directly and in OOP the
interactions come about from how I have described the objects. Done properly,
they are both about interactions, it is just a difference of what you focus
on.

It has been shown that classes of OOP can be modelled for the most part as co-
algebras. This means that objects are a mathematical dual to algebraic types
of functional programming. The reason why functional programming is important
is that some things are easier to express in a dual space. This means that
many things that are hard in OOP are trivial in functional languages. But the
reverse is also true. This is why it is important to not drop one for the
other.

The real advantage IMO in functional programming is that these languages tend
to be developed with stronger mathematical foundations. Hence programming in
them tends to encourage people to be principled and rigorous (at least in
theory). It is very likely that if you study the subject you will naturally
come to be interested in why monads are only one particular type of functor,
that polymorphic functions are well described as natural transformations or
try to wrap your head around mechanically generating dynamic algorithms in
terms of hylomorphisms. The more mathematical nature also makes it less
magical and rickety to the self taught programmer (such as myself). That I
think is the real advantage. But there is nothing inherent in OOP that stops
it from also being built from more rigorous foundations. Such things will come
to matter more with increasing concerns in security.

I think functional programmers sleep on the power of coalgebras. In fact his
example of google map reduce is completely ignorant of the fact that the real
hero in MapReduce tm is unfold not reduce.

I have a pet theory that the fact that algorithms are written in dual styles
is why experienced OOP people find functional programming so hard. They
literally have to reverse their style of thinking. This takes a lot of energy.
Just because it takes place in your head doesn't make it any less physical
than trying to roll a boulder uphill or get a wagon wheel out of a rut.

<http://www.cs.ru.nl/E.Poll/papers/durham97.pdf>

~~~
dustingetz
i think the root problem here is out-of-band -- expertly written OO models are
fine. the problem is that i've never encountered an expertly written OO
system, which is probably because OO allows you to get lazy, where functional
patterns require thought and understanding. i'm gradually starting to suspect
that an expertly written OO system actually kinda looks like a functional
system, except with practical compromises with respect to functional purity.

------
Eliezer
And here I was expecting the surprise moral to be, "Functional code looks
better than average, just because only smarter-than-average programmers can
manage to work in FP languages."

------
richcollins
_Functional Programming Is Hard, That's Why It's Good_

This is a major issue in software development. Developers like a challenge so
they are often drawn to complexity. Unfortunately, this interest in complexity
often carries over into their work.

------
kenjackson
I'd really love to hear PG defend this line: "But with Lisp our development
cycle was so fast that we could sometimes duplicate a new feature within a day
or two of a competitor announcing it in a press release. By the time
journalists covering the press release got round to calling us, we would have
the new feature too."

I'd really love to see the code for something that one would do in a day or
two in Lisp, but would be much longer in another language. I don't suspect
there exists a wide class of such things -- I suspect the features tend to
look like embedding Lisp compilers.

~~~
dustingetz
i speculate the edge compounds as, say, a competitors java codebase's
complexity increases faster than a lisp codebase. exponentiate this over time
and the edge is obvious.

~~~
dpritchett
_The more of an IT flavor the job descriptions had, the less dangerous the
company was. The safest kind were the ones that wanted Oracle experience. You
never had to worry about those. You were also safe if they said they wanted
C++ or Java developers. If they wanted Perl or Python programmers, that would
be a bit frightening-- that's starting to sound like a company where the
technical side, at least, is run by real hackers. If I had ever seen a job
posting looking for Lisp hackers, I would have been really worried._

<http://www.paulgraham.com/avg.html>

------
Apocryphon
How about learning functional JavaScript?

------
brohee
"Pointers are a very powerful and fundamental abstraction"

An abstraction of what? Can't get much closer to the metal than with pointers.
Frankly I'm not sure someone writing this have much insight worth wasting time
on.

------
gregburek
I have an electrical engineering background and all this FP VS IP sounds like
Async Logic VS State Machines. How far off base is that description?

------
kwithl
In the first paragraph a dialect of Lisp is considered a functional
programming language. So I don't read any more. 133 points for this?

------
Paddy3118
The "One True Language Paradigm"....

... Is functional programming!

(while it lasts that is).

Keeps the money circulating.

------
quizbiz
Can anyone recommend any resources for getting started with Scheme?

~~~
rimmjob
the little schemer series was very good. you can safely skip the first 5
chapters if you're comfortable with recursion. learn scheme in fixnum days is
good too for learning the language right away.

------
nirvana
I love Erlang so much I haven't yet gotten around to learning another
functional language. (still growing with erlang).

I learned it reading Armstrong's book from Pragmatic Programmers. It was a
joy. I'm also reading the OReilly book, and it seems good as well, though I
can't tell how it would be if I didn't know the language already. As for the
titles-- one is Programming Erlang, and the other is Erlang Programming!

~~~
stmartin
I think you should learn Brainf*ck. It has awesome mental/intellectual
benefits to you as a Erlang lover. No, but really.... ! And if you don't you
will suffer! Muahaha!

~~~
nirvana
Erlang is easy to read and makes a lot of sense, without requiring much
brainpower... if you'll take a few days and read about it.

I think its kinda silly that people will just ignore a language because it
doesn't look like java/C/pascal. Its not like the syntax of erlang is stupid,
or pointlessly obtuse.

~~~
SoftwareMaven
IMO, the only really ugly part of Erlang is it's record syntax, but it's
binary handling more than makes up for it!

Doing Erlang at the day job for the last few months has been awesome. I really
wish it would catch on more. Maybe when the JVM supports tail-call
optimization and there is a JVM implementation of the runtime...

~~~
rvirding
We know, we know. BUT no one has come up with a better syntax that really
works, all the time. There have been suggestions but none have really worked.

------
stmartin
This is the lie that every functional programmer has perpetuated for the last
50 years since the dawn of Lisp - that somehow, automagically, productivity or
effectiveness of programmers increase with the use of functional languages.

It's the biggest lie in the programming world, and it was designed to make the
uber-geeks of this world, those people that you walk around the block just to
avoid saying hello to because you know they are deeply and profoundly anti-
social, feel good about themselves, to feel special, as though they have the
"upper hand" that other normal people who deliberately choose other languages
over purely functional ones.

There is value in learning how to think recursively, but a lot of programming,
especially systems programming doesn't need to have its for loops transformed
into recursive functions, or its addition operators into primitive recursive
functions.

I am sick and tired of people expounding on the alleged efficacy and
efficiency of functional languages and I wish they would just STFU once and
for all and go back to their porn intermezzos between their functional
programming spurts.

~~~
dasil003
You're making the same mistake that the Java loyalists did when Rails came
out: judging something based on your distaste for the advocacy around it
without any real understanding. I'm not going to pretend to know your
motivations here, but often times people throw up this defense mechanism to
protect their own professional knowledge; but here's the thing, that does
nothing but stunt your own growth.

Functional programming is about the removal of side effects, aka mutable
state. Removing side effects makes programming harder because ultimately the
_whole point_ of computer programming is to create side effects. Isolating
those side effects and writing most of your code in a functional (mathematical
definition: always the same output for a given input) way is challenging, but
it also promises an order of magnitude more possibility of correctness. The
mathematical rigor of a pure functional language like Haskell allows deeper
reasoning to be done, and thus more powerful abstractions to be introduced.

In practice functional programming is not the fastest way to solve many
problems, but it is an excellent way to push forward the state of computer
science as a whole. Think about the relationship between physics and math. We
would not have the deep practical knowledge of the physical universe that we
have today without the complex math that allowed physicists to reason about
things well outside the realm of experimentability.

~~~
ebiester
Here's the problem I have with this: nearly everything I do involves state.
It's called a database.

Let's take a simple example, a to-do list. Abstracted out to its essentials (a
piece of paper), the to-do list is exclusively state. Add a task, complete a
task.

Now, I can write a program that manages a to-do list in a functional language.
There are two options. (Let's assume this is a web app.) First, I can make the
client manage the state. Each time they use the application, they bookmark the
last page. This is obviously inconvenient, but it's pure. Every input has a
distinct output. Send the entire to-do list and what you wish to add or
complete as input, receive an update copy of the state in return. It's always
immutable state. It's also inconvenient if you ever want to use this on
another computer.

So, like most to-do lists, we use a database on the server side to manage the
state of the application. However, you've lost the entire benefit of immutable
state! You are not guaranteed to get the same output given an input. We're
back to square one, aren't we? What's functional about mutable state?

Now, in a subset of programs, eliminating mutable state is beneficial. 99% of
scientific programming would be best served by FP. However, I've never seen an
answer to how we can still call any system functional once we add a database.

And at that point, why aren't we using a language that is bad at what we
expressly need in the first place?

~~~
dasil003
It seems you didn't read my post at all, because this is a complete non-
sequitur. Look at the only sentence in which I emphasized a word and notice
that it is exactly the same as the opening sentence your rebuttal.

This tells me that you are operating off of some mental model of what you've
heard from FP proponents in the past without actually giving what I said
proper consideration. The irony is that in your other comments you decry the
religion of such debates with FP proponents, but in this case you are the one
bringing a religious view. Nowhere did I say that FP languages are generally
superior for real-world problem solving.

~~~
ebiester
I'm not the one you replied to originally. You're right, it was a non-
sequitur, but mostly because it was a question I'd had since I took a
functional programming class in college, and never saw an answer that sat well
for me. One of the other commenters gave one, so rather than contribute to the
noise I just stayed silent and upvoted.

I was just taking advantage of a heated discussion to get an answer. :)

