@john_ohno wrote:
The answer to "what programming language should you learn" for someone who wants to program seriously (either professionally or as a hobby) is, and remains, "as many as possible". The answer for someone who doesn't is, generally, "any" (although some languages are easier to approach than others and make the first few steps of learning easier -- something that will help some people and put off others).
I get a lot of hate on HN for harping on this topic, but it's something that a lot of beginners don't realize. It's not just a matter of choosing the right tool for the job (although that's part of it); it's a matter of knowing the field. Someone who is really good at front kicks but doesn't know how to form a fist correctly can't pass himself off as a karate expert, no matter how good his front kicks are, because in order to reach that stage you need to know a variety of techniques, how they work together, and when each is appropriate; yet so many programmers learn one language and then call themselves ninjas.
And, ultimately, if you cannot determine that the tool you are working with is the wrong tool for the job (which you can't if you aren't familiar with enough tools to happen to know a better one), you cannot do the job well with the tool you are forced to use. (To mix metaphors again, you can definitely undo bolts with a vice grip, but when doing so you benefit from knowing how to use a monkey wrench -- in which you benefit from understanding why you should be using the right sized wrench in the first place. If you understand the mechanics of stripping bolt heads, and you have the tactile experience of determining the right sized wrench for a bolt, you can leverage that to use a monkey wrench; in vice grips, you have a less convenient angle so you have to modify the technique you applied to the monkey wrench in order to avoid stripping the bolt-head. It's exactly the same with programming: if you're forced to use java to solve a problem that would be better solved in scheme, you simulate the things that make the problem easier to solve in scheme, then you solve the damned problem.)
Luckily, the more languages you know (and the bigger the variety of languages you know) the easier it is to pick up new languages. I'm routinely expected to write code for work in several languages that I would argue I don't know at all (this week I had to work in both scala and perl; my experience with scala is limited to about three lines of code I wrote for a school project in 2010, and my limited experience with perl is shrouded by decades of incoherent rage against Larry Wall), because I've learned how to learn languages and I've become skilled at learning enough of a new language to perform a task.
Large projects, if they are well-designed, are often polyglot projects -- people use the appropriate language for each piece (or, more frequently, the wholly inappropriate language they happen to prefer), and then the pieces are bound together through some relatively flexible mechanism. If you know enough languages, you can work on all the parts of such a project (including the ones in languages you don't know); this makes you valuable: if the entire development team gets hit by a bus you can take over!