You may have read Aurynn’s piece on contempt culture and programming languages. It’s been doing the rounds. I recommend reading it, and this piece is not an argument with hers. It’s merely a write up of some adjacent thoughts I’ve had on the matter (some of which I’ve discussed with Aurynn on IRC).
To quote from it:
it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.
Notably there are three (and a half) statements that Aurynn mentions as popular to make:
- Other languages sucked
- the people using them were losers or stupid
- if they would just use a real language, such as the one we used, everything would just be better.
What’s interesting is that these statements absolutely look like one statement in most arguments, but their truth value is different.
Other languages sucked
Yes, this is absolutely true.
Of course, every language is someone else’s other language.
All programming languages fall into one (or both) of two categories: Terrible to use or not yet ready to use. Sure, there are degrees of each, but if you think a language is great, you’re wrong. The best you can hope for is less bad.
PHP and Java, two examples cited in Aurynn’s post, are shitty languages. PHP more than Java (some of the recent Java stuff actually looks quite nice, and I have more sympathy for what Java is trying to do than I used to), but both have a lot of problems.
The people using them were losers or stupid
For me, I think this is the heart of the problem with the narrative that Aurynn is criticizing: Languages don’t care if you make fun of them, or call them bad languages. Languages don’t have feelings. People do.
It’s OK to make fun of Java’s baggage of erased types embedded within the language that it carries over from pre 1.4. It’s better to constructively acknowledge that it’s a problem and talk about other ways that problem could have been solved, but ultimately posting ridiculous programs and saying “lol, Java, you so silly” isn’t really hurting anyone.
But saying “Oh god, why are you using Java? It’s the worst and you should feel bad for that decision” is hurting people. And, in case this is unclear, hurting people is bad.
If they would just use a real language, such as the one we used, everything would just be better
This point is not even wrong. First, it embeds the half statement I mentioned “such as the one we used”, because aside from the fact that all languages are equally “real”, the one you are using is probably terrible too. But even setting that aside: The chance that someone has the option to switch languages is very low.
I am a reasonably senior developer with a reasonably large amount of negotiating clout. I have only once in my career got to choose what programming language I used during my day job (Scala, for a green field project. It didn’t go very well).
The best you can realistically hope for is right of refusal: You can choose not to take a job because of the programming language involved, or to preferentially seek out jobs which involve a particular programming language, but if the jobs aren’t there, or you can’t get them, you’ve no magic ability to just decide to create one where you get to write in your favourite language.
What this means when you’re saying someone should change to a new language, in the overwhelming majority of cases their options are one of:
- Quit their job and hope to luck into finding one in a new language that you prefer.
- Persuade their company that they should switch to a new language.
- Do a vast amount of free labour and pretend that their day job isn’t their real language.
Hopefully when spelled out that way it’s obvious what a ridiculous set of choices this is.
Making the programming language you write in the sole determiner of your job is an awful idea. I’m not saying the programming language doesn’t matter, but when you compare it to working on good projects with good people for good compensation in a good work environment, it should be obvious that if you’re making it your primary consideration you’re making some really bad life choices.
Persuading a company that they should switch to a new language is basically a non-starter, and rightfully so. You can start new projects in a new language, although this itself may not be a great idea, but when you’ve got an existing project and infrastructure written in one language, switching that over to a new language is going to be a lot of work. Even if it that work pays off in the long term (it probably won’t), in the short term it’s an almost impossible sell.
So really what we’re saying when we want people to use new languages is mostly another variation on the theme of “your worth as a developer is measured by the amount of free labour you do”. This continues to be bullshit.
Why are we doing this anyway?
Ultimately, I think a lot of this problem comes down to identity. As software developers, we have too much of our identity bound up in the tools we use. We’re not software developers – we’re Java developers, or Python developers, or Ruby developers. And of course we use a mac/linux/Windows. Who the hell would choose one of those other options? I’ll tell you who: Emacs users.
But seriously. We get very personal about our choices. This makes it hard to criticise the tools people use, because it so easily turns into criticising the people who use them. Equally, it makes it feel like when people who choose things differently than us, they’re criticising our choices and thus criticising us.
We need to move past this. Our jobs are not to develop software. Our jobs are to develop software to solve problems. The software is a mechanism, not an end goal, and every constraint we put on this limits our ability to solve those problems.
It also limits our ability to improve the tools that we consider so important: Part of why I think it’s important to be able to criticise languages is because I want those languages to improve. We’ve come a long way in the last 50 years of language development, but we still have a long way to go. It would be as much a shame to stop here as it would be to release a language that ignored most of those 50 years of development.
But equally, if it’s important to criticize it’s more important to criticize well. If you can’t criticize well, don’t criticize at all. So I’d like to finish with some suggested guidelines for constructive criticism:
- Criticize, don’t mock.
- Criticize things, not people. Ideally don’t even criticize the people responsible for making those things (I’m not good at this one). Even when people are at fault (and as discussed, they usually aren’t), criticizing them just makes it personal and makes it less likely that a productive conversation is going to happen.
- Be specific. Nothing “sucks” generically, but something about it might be bad. Even when something does suck, this isn’t useful criticism but mere venting. If you’re using that thing regularly then venting is fine, but otherwise it’s an extremely unclassy move.
- Focus on effects, not aesthetic preferences. “I hate this syntax” is not a useful criticism. “I keep confusing this syntax with this other syntax” is. Although in general people over focus on syntax anyway and “This feature keeps causing this concrete problem” is way better.
- Things arise through vast amounts of historical context, and come with a vast amount of inertia. Change is hard, and comes with a lot of problems. Most of the time, criticism will never result in fixing the problem. All it can do is try to establish how you can do better next time.
Pingback: 2015 in review | David R. MacIver