
Functional programming and condescension - coolsunglasses
http://superginbaby.wordpress.com/2014/10/28/suddenly-the-opposite-appeared/
======
JoeAltmaier
Its easy to call 'condescending' when you simply feel inadequate. Read that
strictly: its not condescending if you are actually inferior (in understanding
or education).

Functional programming is important, and about real structural things. It can
take a long runway to understand why its different, then more learning to get
any facility with it. This is not a problem with the languages; some important
things are hard and that's just a fact.

~~~
stdbrouw
So you're saying it's perfectly okay to behave poorly towards people with
lesser understanding or education? I'm pretty sure people can tell the
difference between those who are speaking at a level that is too difficult for
them to understand, and people who are actually condescending.

~~~
JoeAltmaier
Read the article? Its about how people take it wrong when the issue is hard
and they don't understand. Its about confusion about exactly what you said
there.

One takeaway is, when someone expects you to read up on a subject before
making conjectures, that's not condescending, that treating you as a competent
peer, an adult who can take charge of their own education.

~~~
stdbrouw
I read the article. It gives one (one!) example of someone who thought a
statement was condescending when in reality it was – wait for it – only semi-
condescending. Unless you'd like to argue that "take some responsibility for
your own learning!" is not even in the least a condescending statement.

It's great that the author has found people in the Haskell community to be
generally helpful (and I've been learning some Haskell and thus far have no
complaints myself). And I think the author makes an interesting remark that
sometimes, by trying to "be easier" on newcomers, that might actually be a
form of talking down to them instead of treating them like adults. But to turn
that into a blanket "oh, you know, you might think we're condescending but
really you just don't get it" is practically satire.

So despite what the author says, and despite having no more proof for my
statement than she does, I'll stand by my statement: people can generally spot
the difference between condescension and a knowledge gap.

~~~
JoeAltmaier
That example was a teacher to a student. If you're not careful, everything a
teacher says to a student can be read as condescending.

That's the crux of it; if it not how its said but how its received, then the
issue is on the receiving end.

~~~
dllthomas
But clearly there are ways things can be said that lend themselves more to one
interpretation or another. We need to own whatever role we have in the problem
and work to fix it on the end we control, balanced against whatever other
legitimate problems or constraints we're working with.

"Successful communication" is a constraint that probably should trump
"phrasing to protect people's feelings" when the two conflict. "Social
signalling games" probably should not. Differentiating the two is deliberately
made difficult, but we don't get out of that by ignoring it.

~~~
JoeAltmaier
Sure all things being equal. When you go to a teacher to be instructed, its
counter-productive to be thin-skinned. Even if you are a peer, but are
learning the ropes from a more-experienced player, best to take the
information without emotionally investing in the style of messaging.

~~~
dllthomas
_" Sure all things being equal."_

Yes, but not only then. There are some things worth sacrificing to that end.
Clarity shouldn't be one of them.

 _" When you go to a teacher to be instructed, its counter-productive to be
thin-skinned."_

And when you serve as a teacher, it is counter-productive to not make
reasonable accommodation for whatever skin your student has.

I don't think we're saying anything new anymore.

------
AnimalMuppet
I've had explanations that are over my head. When I asked for help
understanding the explanation, sometimes I got help, and sometimes I got
mocked because every educated person should know _that_.

Honest questions deserve honest answers. Giving mockery instead means that
you're a jerk trying to up your self-esteem at the expense of someone who's
trying to learn. Don't be a jerk.

On the other hand, lazy and/or dishonest questions do _not_ deserve an honest
answer - "do your homework and then come back" might be best for lazy
questions. For dishonest questions, maybe the best approach is to gently point
out the dishonesty. (Point it out, because others may be reading the
conversation and doing so might help them to not be misled, and gently,
because you may be wrong when you think someone is being dishonest.)

But it can be hard to determine when someone is being dishonest or lazy, and
when they're honest but clueless. Err on the side of assuming the best of
people.

Specifically on HN, on the topic of functional programming, I have received
good, helpful explanations from a number of people, and have learned from
them. (I have also received arrogance and condescension from some.)

The biggest form of condescension from FP types is often in the high-level
assumption: "If you really understood, you would know that FP is The One Right
Way. Since you don't agree, that means you are still ignorant." And anyone who
tries to point out that this assumption is flawed is automatically lumped in
as one of the ignorant. _That_ is condescension.

~~~
dllthomas
Very well said.

I would like to add a note, though, that "do your homework and then come back"
can also be deployed dishonestly.

Something I called out a bit back (which was graciously received by the
perpetrator - I don't think it was actually intentional in that instance)
amounted to "If you haven't found the thing that proves I'm right, you haven't
done enough homework". Which is an approach that can be rhetorically effective
when people don't notice what you're doing, but seems somewhat poisonous to
the goals of truth seeking, of educating ourselves, and of getting along.

I don't know the best way to distinguish these - most examples don't reduce so
clearly and I agree there are plenty of cases where someone just needs to go
read something.

------
Mikeb85
I find this interesting. Personally, I'm someone with absolutely no technical
background. Haskell programmers seem to come from many backgrounds - math, CS,
but also backgrounds that don't involve programming, various sciences for
instance.

I've personally always found the communities of many less-common, more
functional languages (Haskell, R, Clojure, etc...) to be very welcoming to
newcomers with little programming experience or non-programming background,
although perhaps I could see how it would be less welcoming to someone coming
from a C++, Java or C# background.

To really embrace functional programming (and their communities), in many ways
you need to discard what you know about imperative programming. Different
mindsets. And I've never found functional programmers to be smug or
condescending, though they do use terms that don't make sense in other
programming languages/paradigms...

------
Someone1234
That was a pretty interesting read. It really has nothing to do with
functional programming, and everything to do with human nature.

~~~
PeterWhittaker
We work with interesting technologies which we attempt to make do novel
things. Occasionally, one of us works and succeeds alone, but, far more often,
we work with others.

Human nature and how we treat, are treated by, and respond to our fellow
humans is likely the single most important factor in any technology project.
Indeed, in any team project. That's not to say that all projects require the
same approach to managing the team: Some work requires top-down command and
control with explicit orders and consequences for disobedience, some is better
done with self-selecting teams and kanban boards, and much is somewhere in
between.

The common element is that the players have to know and respect the team's
organizing principle. Once upon time, it was command and control and strict
orders for everything; everyone knew this was how it was done. Everyone worked
within that.

Nowadays, establishing and maintaining an organizational culture, and
articulating that culture, over and over again, are vital elements to any team
work.

Many of us will read what this post and roll their eyes at this human factors
bullshit.

Some of us will think "Oh, yeah, that'd be good". (Some of us will mean that,
others will express is sarcastically, imagining me with rose coloured
glasses.)

Functional programming is YAHA (yet another human activity). Sometimes pursued
alone, but sometimes in groups.

Some of those groups even manage to become communities. But are they inclusive
or exclusive, and is that implicit or explicit knowledge? When I switched from
Windows to Linux, I chose Ubuntu because it was explicitly inclusive with a
clear code of conduct. Pissing on others strictly forbidden.

Some technologies succeed despite the way key players treat others. It
happens. My guess is that most don't.

How many forks are for sociological reasons, and not for technical or legalo-
business reasons? (That last phrase is obscure, I confess: I mean things like
the OpenSSO/OpenAM fork, for example: Forked because of a change in governance
and ownership.)

In other words, how many times are projects forked because part of the
community doesn't like how the rest of the community conducts itself? How many
projects fail because of how the community conducts itself?

------
dllthomas
I wonder if some of these critics aren't confusing "condescending" and
"conceited", to further muddle things.

------
_random_
They are just frustrated that the only way to make functional programming
useful is mixing it with some good old OOP and imperative stuff - the recent
rise of Scala and C# are a proof.

~~~
coolsunglasses
It’s a bit like the transition from the bronze age to the iron age.

It wasn’t a sudden switch and while the iron tools owned the future, they were
inferior at first. Took a long time before iron tools and weapons became the
most popular thing, even after iron tools could be made that were superior to
bronze.

Popularity doesn't say anything about tool quality.

A lot changed from 2010-2012 for Haskell. There was an explosion of libraries
and tool fix-up. This continues, no doubt, but it has shifted the equation in
favor of tools that don't have to make compromises that harm productivity.

I teach Haskell in a decided un-academic manner. This is partly because I have
no academic background nor degree. It is also because I teach people Haskell
in a manner designed to enable its use for practical projects.

This is the guide I use to teach people Haskell:
[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

I've taught Haskell successfully for the last year to programmers and non-
programmers.

