
Functional programming's smugness problem  - robrenaud
http://www.sdtimes.com/content/article.aspx?ArticleID=36534
======
joeyh
I have never, ever seen "Monads are just monoids in the category of
endofunctors" used in an actual conversation with someone who is trying to
learn monads. The phrase is and always has been a joke; surely part of the
joke is that most of us who use monads don't understand all that jargon
ourselves. [http://stackoverflow.com/questions/3870088/a-monad-is-
just-a...](http://stackoverflow.com/questions/3870088/a-monad-is-just-a-
monoid-in-the-category-of-endofunctors-whats-the-problem)

BTW, the article asks about design patterns that structure functional
programs. Well, monads are one such pattern. That's why they're important, not
some mathematical jargon.

~~~
Muzza
Please read between the lines. The author wasn't implying that anyone actually
said that, just like he doesn't think anyone has ever said this in real life:

>"Design patterns? Hey everyone, look at the muggle try to get the wand to
work!"

~~~
technomancy
Well actually...
[https://mobile.twitter.com/bos31337/status/18756470625548697...](https://mobile.twitter.com/bos31337/status/187564706255486978)

------
ozataman
I can speak only for Haskell-land, but I honestly see no truth in any of the
author's negative arguments towards the functional programming community.

I have been doing most of my programming in Haskell for 3 years now, having
worked in Ruby and Python before that. I can tell you that the Haskell
community is among the most cordial, helpful and communicative I have ever
seen in any field. In fact, many members of the community will cry foul if
anyone dons on a "smug" attitude at any point; I've seen countless comments on
reddit get buried for this alone.

If you want proof, just ask a question on StackOverflow[1], join #haskell on
freenode or check out the reddit[2] page.

[1]: <http://stackoverflow.com/questions/tagged/haskell>

[2]: <http://www.reddit.com/r/haskell/>

~~~
CJefferson
I find that many functional programmers, including Haskell programmers, seem
convinced that I will completely abandon C++ if only I spent the time to
understand Haskell.

After spending quite a bit of time learning Haskell, seeing a number of
advantages and disadvantages, and being unconvinced and staying with C++, the
assumption is I didn't "do enough".

Of course, I also know a number of lovely functional programmers as well!

~~~
DannoHung
Maybe you're not ready to leave C++, but if you don't have a slightly icky
feeling from C++ compared to Haskell, then you've been programming C++ for so
long that the weirdness has metabolized.

~~~
KingMob
Errr... perhaps you meant metastasized? Or solidified/ossified?

I think if it had metabolized, that would mean your body had burnt up the
weirdness and gotten rid of it.

------
granitepail
This article serves to fracture the community in a manner disturbingly similar
to that in which the 'smug functional programmers' he complains about do. I
can't help but sigh.

I think the recent rise in popularity of functional programming is a sign that
more people are beginning to approach computing from a 'computer science'
perspective as opposed to a 'programming' one. That is, to say, that the
industry has matured to a point in which a significant portion of industry
programmers are getting excited about some of the more abstract concepts
brought to us through functional programming.

Few people will argue that the concepts underlying FP don't take some time to
internalize, but the number and quality of FP learning resources is increasing
at an incredible rate. This, alone, makes me skeptical of the author's points
— people are going out of their way to create accessible learning resources so
that they might share something they find to be useful/interesting. In any
movement of any kind, there will always be evangelists. Some (read: most) of
these evangelists will be overly aggressive and preachy, but they are rarely
(read: never) representative of the larger body.

In the past two years I've become quite a fan of Clojure, and I have found the
community to be tight-knit, welcoming and eager to share.

~~~
lincolnq
Is that why more people are learning FP? I think it's a different trend:
recognition that programming is no longer about writing tight loops. Those
have mostly been written. Instead, practical programming these days is
dominated by orchestrating different people's code. Functional languages move
more quickly here because functional code is, in some sense, more reusable by
default.

~~~
granitepail
I don't think our ideas are mutually exclusive — what you're describing is the
notion of abstraction as it is applied to writing code. FP gives programmers
incredible power with regards to reusing code (macros, first class functions,
etc) at the expense of taking a little longer (in some cases) to wrap one's
head around.

I was merely commenting that I think part of the reason people have been drawn
to FP lately is that the industry as a whole has matured to a point in which
more people recognize the need for and have developed the skills necessary to
embrace such abstractions.

------
fleitz
The downside of being better than everyone else is psople tend to assume
you're pretentious.

I learned FP by doing it, not asking around what monads are. There are plenty
of great tutorials and no one has ever seriously talked about monads in that
way.

The only time you really need to know what monads are is when you are building
a new one.

~~~
ajross
_The downside of being better than everyone else is psople tend to assume
you're pretentious._

The article used the word "smugness", not "pretention". They don't quite mean
the same thing. Being merely better than someone might certainly seem
pretentious depending on context.

Telling everyone about it (in a context without relevance or evidence),
however, is undeniably smug.

------
ciderpunx
I've just started having a play with Haskell which I got interested in after
working through the seven languages in seven weeks book.

I've not really seen much smugness in the Haskell community. Though there are
some proper clever people talking about stuff I don't understand, I don't feel
they've done it in a patronizing way (or at least its been to subtle for me to
pick up on!) That's my experience anyhow. I realize that the plural of
anecdote is not data.

I'm actually more interested in the second part of the article where the
author talks about claims of productivity gains from functional programming
being exaggerated. I am curious if folk on here can point to counterexamples
to the study quoted.

My strong suspicion is that there is much more likely to be a large variance
in the productivity of programmers than in the productiveness of a particular
language or way of programming.

------
m0th87
My experience is the _exact_ opposite. Whenever I struggle with an FP concept,
those deeply nested in the community tend to be both eager to help and pretty
unassuming. This is especially true among Haskellites (Haskellistas?) who
usually understand there's a high learning curve associated with the language.

~~~
technomancy
His examples come from the Scala community; I wonder if it's more pronounced
there? I get the impression Haskell folks are fairly laid-back too.

------
jejones3141
I suspect that OOP had a similar problem at one time.

~~~
cobrausn
I'm not so sure. OOP entered the scene and became a dominant paradigm in a
short amount of time - this doesn't happen without massive amounts of
evangelization (from existing users) and marketing, neither of which can be
particularly smug if they intend on being successful.

~~~
jgon
OOP was able to become dominant because it came with some clearly defined
"killer apps", the likes of which I have yet to see materialize from the FP
world. I mean, Smalltalk shows up in Byte and says "look, here is an entire
system for graphically interacting with a computer, creating music,
simulations, animations, drawing programs, documents, and more. It is so easy
that school children can use it. We have managed to accomplish all of this in
a few hundred thousand lines of our language called Smalltalk, which
incidentally also contains the implementation of all the dev tools and the
standard library. How large would this be in the language you are currently
using (probably COBOL, Pascal, C or something similar)?"

I get that FP has some very good characteristics, and I have tried to add a
bit more "functional-ity" to my code over the years, but at the same time I
get an overwhelming urge to say "put up or shut up" every time I am confronted
with an article talking about how terrible OO and the programmers who work in
it are, and how those working in FP are in some sort of enlightened
programming utopia.

Convince me by showing me some examples of programs so good that I can't
possibly ignore them, the way OOP did. Convince me by becoming the foundation
of almost every program I am currently running on my computer right now, the
way OOP did.

Don't convince me by writing article after article showing how insanely
elegant your implementation of a mathematical function (My head will literally
explode if I see another Fibonacci example) is, and how brain damaged what I
am currently using must be. Numerical code comprises probably 0.1% of any
computer system I am currently using. Show me instead how easy you just made
to it interact with my computer, to write the type of programs that I am
currently using and, for bonus points, to write the types of programs that I
didn't even think were possible.

~~~
KingMob
Hmmm. The killer app, when it comes, will probably be for parallelism. Since
FP languages are better able to control state, they can neatly sidestep many
of the contention issues that plague imperative programming in multi-core
scenarios. Problems that require heroic programming in imperative realms
become much simpler in certain FP languages. And given that clock speed is
settling down while core numbers are ramping up, I think this alone will make
FP more compelling.

It's more about appropriateness, though, than anything else. I still think OOP
is great for things like GUIs, modeling complex domains.

As always, the trick is to pick either the right language for your problem, or
pick a multi-paradigm language, and choose the right approach for your
problem.

~~~
bunderbunder
_The killer app, when it comes, will probably be for parallelism._

If that's the case, then FP's got a problem in the form of OOP having already
done it first and famously with projects like Hadoop.

I think that too much hay is made of the tradition of minimizing mutable state
in functional programming. It's not something that's exclusive to FP. And I'd
even go a step further and suggest that excessive use of mutable state isn't a
hallmark of imperative programming so much as a hallmark of _bad_ imperative
programming. Though I'm sure there's also plenty of room for argument there.

Regardless, the fact remains that when functional programming proselytizers
suggest that imperative programmers need FP to escape from the bugaboos of
excessive mutability, it comes across as somewhat naive. While many functional
languages make mutability less convenient, this is not the same as making
immutability more convenient. Which I mention by way of pointing out that
really the only thing people working in imperative languages need to do to cut
back on their use of mutable state is _cut back on their use of mutable
state._

Now, if the current fad for FP made more noise about something that
distinguishes functional languages much more tangibly, it might be more
impressive. Take higher-order programming, something most functional languages
do very well and most imperative languages do poorly (if at all). Imagine
doing something like node.js in a non-functional language.

Or this couple minutes from a lecture on F#, where the presenter converts
sequential code to asynchronous parallel code in just a few keystrokes. Sure,
managing state properly is an important precondition to being able to do that,
but the real magic is in the async workflow (a type of monad).
<http://youtu.be/HQ887aOZITY?t=53m>

~~~
tincholio
> with projects like Hadoop

You do know where the "map" and "reduce" in MapReduce come from, right?

~~~
bunderbunder
Yes. That's precisely why I chose it as my example. One of the major themes in
my post was statements to the effect of "you need functional programming
languages to do X" often being mistaken, so that detail makes Hadoop a rather
poignant case.

~~~
KingMob
I agree. I think perhaps, a better point to make is that FP makes certain
things easy, or the default, while doing it in am imperative language requires
discipline, which I think is a mistake to rely on at the industry level.

It's a bit of a reductio ad absurdum, but remember: technically everything
_could_ be written in assembler. Languages and their idiomatic usage matter.
Any C++ person could point out that, yeah, everything you can do in Java can
be done in C++, but the fact that Java does automatic memory management still
has value to many people.

~~~
bunderbunder
Totally. And I also think a lot of imperative languages make that kind of
discipline more of a hassle than it needs to be. (Giant peeve: .NET does not
have any decent options for immutable collections in its standard libraries.)

But the author does bring up a good point: The industry is full of people who
were taught using Scheme in university, but quickly switched to an imperative
language when given the chance. Having TA'd classes that are taught in Scheme,
and spent a lot of time tutoring people who fit into that class, and watching
the way they go nuts when they're finally shown set! for the first time, I've
come to the conclusion that it isn't merely a preference. Most of them really
do have a genuinely easier time reasoning about and writing correct imperative
code. It would also be a mistake to rely on a programming paradigm in which
many people have a hard time functioning at the industry level.

If there's a middle ground that allows people to keep their FOR-loops while
discouraging them from using mutability in the contexts where it's dangerous,
that's the direction I think industry should be headed in.

------
xd
Out of curiosity .. when was the last time you read a story that told of
company x dominating the market because they used programming paradigm n..
just a thought.

~~~
lincolnq
Viaweb?

~~~
xd
The wikipedia entry states viaweb was partially written in lisp .. would be
interesting to know what part lisp played .. is pg in the house?

~~~
dpritchett
This nine year old essay by pg is very well known:
<http://www.paulgraham.com/avg.html>

_Our hypothesis was that if we wrote our software in Lisp, we'd be able to get
features done faster than our competitors, and also to do things in our
software that they couldn't do. And because Lisp was so high-level, we
wouldn't need a big development team, so our costs would be lower. If this
were so, we could offer a better product for less money, and still make a
profit. We would end up getting all the users, and our competitors would get
none, and eventually go out of business. That was what we hoped would happen,
anyway._

------
canthonytucci
I dont think it gets much friendlier than Learn You a Haskell

<http://learnyouahaskell.com/>

------
AnthonBerg
Smugness is in the eye of the beholder.

~~~
cobrausn
That's just something smugly people say. ;-)

------
grayed_comments
I totally agree with the author in my experiences. To be fair those
individuals were also egotistic elitists in other realms of their life. "If
there's anything around here more important than my ego, I want it caught and
shot now!"

------
michaelochurch
OP strikes me as someone who is trying to position himself as a "moderate" but
who is mistaking a caricaturized extreme (<0.25%) for "functional
programmers". Honestly, I like FP extremists better than their OOP cargo-cult
counterparts, who have the same smugness but are usually better, in most
companies, at getting managerial blessing. In many companies, OOP acolytes
glow in the managerial sun like Dudley Dursley, despite the general crappitude
of their ideas.

"Functional programming" in the real world isn't about dogmatically
eliminating mutable state. It's about _managing_ it. It's about _modularity_.
It's not far from the original vision behind OOP-- before it got taken away by
the wrong crowd-- which was that when complexity is inevitable, it should be
encapsulated behind simpler interfaces. For example, SQL is append-only (as
functional as one can get over a growing knowledge base) if you never use
DELETE or UPDATE. The inner guts of SQL are not "purely functional"-- caching
and indexing cause internal state changes, for performance reasons-- but the
interface is.

I don't even know what endofunctors are. If it's relevant to my job, I'll
learn about them, but I care more about writing good software than reciting
category-theory arcana. I'm sure it's important (especially as an inspiration
for design) for some people, but you don't need to know them to do functional
programming. Not even close. And I was already a productive functional
programmer (in Ocaml and Lisp) before I even knew what _monads_ were.

~~~
moldbug
The problem is that the best, most expressive functional languages (lookin at
ya Haskell) are _mathematically based_ on this theory. If you want to use
these languages, you have a choice between (a) learning the theory, and (b)
not fully understanding the tool you're using. Both have significant downsides
from a UI perspective.

 _Learn You A Haskell_ is a classic case of (b). As a tutorial it's completely
successful, and how? It tells you that you can learn Haskell without learning
PL theory. It also neglects to tell you how to _debug_ you a Haskell (without
learning PL theory). But once you type in the examples, I'm sure you can
figure it out.

A lot of people are smart enough to program on top of mysterious black boxes.
That is: a lot of people are smart enough to work past this UI problem.
Moreover, the smartest people can learn Haskell by rote and then gradually,
through intuition and experience, learn to grok the black box. This is not to
say, I think, that it's not a problem.

Of course you could just learn the theory. I'd say anyone who can graduate
with a math degree from an Ivy-class university can do it. Is you a member of
this set? Find out by reading the Wikipedia page for Hindley-Milner:

<http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner>

I'm sure there are simpler explanations of H-M (Haskell's type inference
algorithm). But they're not on Wikipedia. I sent this link to a friend of mine
with a PhD in astrophysics from Caltech. "Which seems easier to you?" I asked.
"This, or special relativity?" You can probably imagine his response.

So, wanted: a higher-order typed functional language whose type system is
easier to understand than special relativity. Or of course a proof that such a
device is impossible :-)

~~~
sold
Do you think H-M, which can be presented in full in less than a 60 minutes
functional programming lecture, is harder than a whole subfield of physics? I
don't think so. Astrophysists deal with large objects every day and there
might be a reason why they find relativity easier.

BTW: Debugging is much less used in Haskell, this is not a strong objection to
LYAH.

~~~
moldbug
Special relativity is a few formulas, not a "whole subfield of physics." But
yes - I didn't really regard this as a serious scientific criticism.

I can present LR parsing in a lecture as well. However, if you had to
understand LR parsing to write an HTML 5 app, there would be a lot fewer HTML
5 apps.

By "debugging" I didn't just mean tracing. I meant one of the most basic tasks
of the programmer - interpreting and responding to error messages. Is there a
single error message shown or explained in LYAH? If so, I missed it.

This is germane because, when a type system works perfectly, it appears magic
by definition. When it issues you an error, however, you have to understand
what went wrong. It is sometimes possible to do this without understanding the
black box, but the skill is again recondite.

I refuse to believe that Haskell programmers are so godly that their programs
work the first time they're typed in.

~~~
sold
I think "special relativity is a few formulas" is an underestimation, but this
is not important.

> By "debugging" I didn't just mean tracing. I meant one of the most basic
> tasks of the programmer - interpreting and responding to error messages. Is
> there a single error message shown or explained in LYAH? If so, I missed it.

Yes, although not much; grep for "error" in
[http://learnyouahaskell.com/starting-out#babys-first-
functio...](http://learnyouahaskell.com/starting-out#babys-first-functions) or
other chapters.

I could code comfortably in Pascal long before I knew how exactly does
"expecting a semicolon, found a number" arise. I could code comfortably in
Haskell many months before learning HM as well. You know what to do when you
see "no instance for Num Char" as well as you know what to do with that
parsing error. No need to think about unification or parsing, a kneejerk
reaction is enough.

> I refuse to believe that Haskell programmers are so godly that their
> programs work the first time they're typed in.

Of course that's false -- but once a Haskell program is typed and compiled,
there are much larger chances that it will work first time compared to, say,
Java.

~~~
moldbug
_I could code comfortably in Haskell many months before learning HM as well._

This is a better argument for you than for Haskell. I wasn't disputing that
there's a set of people who can intuitively command an incredibly recondite
black box they don't (yet) understand - or that that set includes you. What I
will argue is that that set is _small_ , making it very hard to produce a
critical mass of Haskell users despite the tremendous academic subsidies
Haskell has received.

Imagine you're a helicopter pilot. That it's easy for you to fly a helicopter
doesn't mean it's easy to fly helicopters. If we compare the set of people
cognitively able to use PHP, to the set cognitively able to use Haskell, I
don't think we're far from comparing car drivers to helicopter pilots.

 _Of course that's false -- but once a Haskell program is typed and compiled,
there are much larger chances that it will work first time compared to, say,
Java._

Indeed. (I'm not just agreeing for rhetorical purposes - this really is true.)
Inasmuch as the programmer isn't perfect, however, he spends his time chasing
not runtime errors - but static type errors.

~~~
sold
I agree that using Haskell is like flying a helicopter when others use cars.
However, I still strongly disagree with the choice you wrote earlier:

> If you want to use these languages, you have a choice between (a) learning
> the theory, and (b) not fully understanding the tool you're using.

Please bear in mind HM is only a basic idea of how Haskell type system works.
Current inner workings of GHC type checking are described in 80 page research
paper on OutsideIn(X),
<http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn>. I never read more
than half a page from this. Yet I can use GADTs, type families, existentials,
rank-2-types and so on with no trouble. I don't think Haskellers who did not
read those 80 pages are "not fully understanding the tool they're using".

Why should I know theory - OutsideIn(X), HM, category theory etc., to "fully
understand" the tool? Intuitive understanding gained by practice is enough.

~~~
moldbug
Intuitive understanding gained by practice enough for _you_. If Haskell didn't
exist, you could probably invent it. The result might even be better.

Neighbor, how much code is there in the world? And how many coders as good as
you? Divide these numbers, and you'll see why the world can't possibly adopt
Haskell.

Some people can climb Half Dome with their fingernails. That doesn't mean
there shouldn't be a fixed rope, too - that is, if your goal is to maximize
the climbers of Half Dome. (If its goal is to separate the men from the boys,
Haskell is already doing just fine and shouldn't change a thing.)

~~~
sold
I think intuitive understanding gained by practice is enough for every
programmer, not just me. Learning by programming is easier than reading
research papers and digging the theory. What more, it was a prerequisite for
me: I could not understand papers on type systems or category theory before I
saw Haskell code. I heard similar opinions often - Haskellers learn Haskell
first, can code comfortably, and only then are able to read about the theory.
Theory seems hard, dull and useless at first. Even now, I feel a lot of it is
cruft.

The semi-official motto of Haskell is "Avoid success at any cost", not world
domination. It is enough as a tool for hackers, not for everyone. Haskell
expands extremely slowly, yet steadily.

------
guccimane
Oh, stop. I'm tired of hearing about "smug" being the worst thing ever. Too
easy to toss this insult around.

Instead, personally my issue with functional programming is the aversion to
side effects. It seems to cause a lot of weird contortions, when the whole
reason we make software in the first place is for the side effects.
Programming in a functional style brings with it a lot of wonderful, powerful
ideas. But that one has always struck me as unfortunate.

~~~
fpgeek
I couldn't disagree more.

I find that the aversion to side effects even when working in imperative
languages is one of the most useful things I've learned from functional
programming.

It is true that, at one level of abstraction, we write programs for their side
effects. However, it is also true that having the right side effects is
extremely important - so important that a program with the wrong side effects
can easily be worse than no program at all. From that perspective, a focus on
minimizing, containing and controlling side effects is very valuable. And an
aversion to side effects is a good way to sharpen your focus on that.

~~~
guccimane
> _I couldn't disagree more._

I know. Trust me, I know.

