Lately I’ve been doing a fair amount of interviewing, particularly for hiring interns. Like most people do, I’ve got into a bit of a routine with the questions I ask. I often open by asking what languages the candidate is familiar with, which they like the most and what they do and don’t like about them.
This is mostly intended as an easy lead-in to the interview proper, with the added advantage that it helps me to decide what language to use for the technical questions later in the interview. As far as answering the question “what do you like about language X” go I’m not looking for any answer in particular, and I’m certainly not looking for answers I agree with. I expect any reasonably competent candidate to be able to tell me the commonly accepted strengths and weaknesses of C or Perl, say (assuming they have experiences with those languages). A good candidate will come out with an idea that I haven’t heard before, or give a particularly cogent example or neat summary of an issue, which is great because it tells me that the candidate is thinking about their tools as well as just using them.
Incidentally, I quite like the negative form of this question—”What is the worst thing about technology X?”—exactly because it’s not something that people habitually give much thought to. It’s easy to spot the things that cause annoyance (like long compile times in C++, or run-time type errors in Python) without finding the time to think about why the language ended up with those flaws and whether there’s a more fundamental problem behind it (such as backward compatibility with C in C++).
The worst answer I tend to get for why a candidate likes a language is “because it’s easier”. This might be the starting point for an interesting dialogue on what makes an effective programming language, but too often it’s presented simply as an end in itself, an inarguable fact about the world. Java is simply easier than C.
The thing is, as a professional developer easiness is never really an issue. If you find a day’s task easy and get it done by 2pm, you don’t get to go home early. If you can write code in a particular language using only half your brain, your boss will expect you to get two things done in parallel. Productivity is a very real issue, but easiness isn’t.
Am I splitting hairs here with the distinction between easiness and productivity? I don’t think so. Firstly, it’s a question of attitude: if you’re hoping for a software job that’s easy, then we might not be the right people for you. But secondly, the idea of easiness seems to come out of a mindset of programming languages being like industrial design: the reason that C is difficult to use is that the designers were incompetent or lazy. Java is the iPhone to C’s Android Cupcake. Although there is an element of programming language design learning from earlier mistakes, a far more important effect is just that different languages are designed to do different jobs. C doesn’t do bounds checking on array dereferences because you don’t necessarily want the overhead when you’re doing the kind of things C is used for. That might well make it a bad choice for the sort of thing you like to work on. It may even make it a bad choice for modern programming in general. But not just because the language makes you think hard.