Functional programming and condescension
superginbaby.wordpress.com
superginbaby.wordpress.com
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.
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.
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.
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.
That's the crux of it; if it not how its said but how its received, then the issue is on the receiving end.
"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.
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.
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'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...
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?
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
I've taught Haskell successfully for the last year to programmers and non-programmers.