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.
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.
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.
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.
> Unless you'd like to argue that "take some responsibility for your own learning!" is not even in the least a condescending statement.
It depends. Sometimes it's condescending; sometimes it's exactly what one needs to hear. (When I got a very similar statement from a physical therapist about my physical health, it actually was what I needed to hear.) It depends on whether the recipient is being lazy, or is genuinely trying.
But it gets more complicated, because the speaker may mis-judge whether the recipient is trying. Also, the recipient may be lazy but defensive, or lazy but receptive to the criticism. There is no one right answer here; it depends on the people involved.
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.
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.
I agree that the parent reads like it condones too much bad behavior. At the same time, I think "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" is not as true as we might hope.
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.
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.
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...
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?
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.
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.
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.