Sure you can learn more than one. But you can only really learn a few, and you only fully master (at the "concert pianist" level) one -- except if you're some crazy outlier.
Same for languages. And I'm including the library and framework ecosystem, language tooling and culture here too.
Whilst I aspire to being a polyglot and agree that it's a desirable trait, until you can arrange me a 30 hour day and a 10 day week, I'm going to spend my time where I get the highest return at the moment - getting things done in the best way I know how.
The customers dictate the technology stack and we are expect to be able to dive in, learn what is missing from our side and start developing.
You just need a mix of real experts, the ones dealing directly with the customer on site, with a blend of not so experts hacking along a few lines behind in the battlefield.
When one those "not so well experts" gets the next gig, they are themselves experts in the said technology. :)
Dynamic languages like python or ruby have very malleable definitions of what a class is, and a lot of static verification you can be used to in C# or Java isn't there anymore.
Pattern-matching heavy languages like ML have much simpler object heirarchies than what you might find in OO languages, and have different design patterns to compensate.
Purely functional languages like Haskell require a completely different way of thinking about state (seeing how there is none on a purely language-semantic level).
There are many languages worth looking at that are not OO, and the lessons learned from really trying to learn them and their design patterns can make your code better in your "native" tongue.
With each new lens you come face to face with the reality that the fewer mental models you have, the more each one colors what you see, think, and believe -- the thought patterns driving your decisions and ultimately setting your trajectory. It's experiences like these that transcend tech and reveal what Alan Kay means when he says "we see things not as they are, but as we are" and "a change in perspective is worth 80 IQ points".
Both sides of the table should embrace programming language agnosticism. I've spent most of my career doing PHP and later Node.js, but I'd be happy to take a job working on a product written in Python or Ruby if such an opportunity arose.
I've happily identified as a "Python programmer" while it was the main language I was using, and now more or less call myself a "Go programmer" after a similar switch. In less code-centric teams it's a handy way to identify where you are coming from.
Another reply here noted the time investment can lead to attachment, I find this true as well. When I decided to switch to Go for my next project, the only way to learn it was to put in some serious hours on the weekend and late into the evenings. You can't help but identify with something when you make that kind of effort towards it. All of the little cognitive biases and tricks with ego keep you invested enough to keep learning.
The Well World series would probably qualify as an example of the latter.
1. Learning a new programming language or a framework requires a significant effort for someone to use it comfortably. No matter how smart you are, there's the inevitable "grind" you have to go through to achieve the level of familiarity with a new language. It's only natural that people gravitate towards what they are familiar with and grow attached to what they know more.
2. Identifying oneself with some programming language is completely fine. Would you have any problem if Dennis Ritchie identified himself as a C programmer or Matz as a Ruby programmer?
You're being unnecessarily harsh, this type of comment might have educational value for newer developers. The fact that a programming language is a tool is not understood by all of us, and I personally admit that a very similar message I read on IRC opened my eyes when I was younger.
> Would you have any problem if Dennis Ritchie identified himself as a C programmer or Matz as a Ruby programmer?
Your own example ruins your whole argument. Matz is a programmer, he invented Ruby and wrote its interpreter in C. Calling him a C programmer or a Ruby programmer makes therefore very little sense. Same goes for Dennis Ritchie and the assembly he used to create C.
Your point still stands though: you need to be fairly competent at assembly language to write a compiler that emits machine code.
>"The origin of C is closely tied to the development of the Unix operating system, originally implemented in assembly language on a PDP-7 by Ritchie and Thompson, incorporating several ideas from colleagues."
It's also written that the B rewrite only came later.
I yearn for the day when we'll stop calling ourselves X programmer, and writing articles about "switching languages" or "going from one to the other".
A language is a tool, not an identity.