I've long been a proponent of learning multiple languages. While I have no empirical evidence, I do believe that it gives a market advantage in understanding how best approach software problems. Peter Norvig agrees and Steve Yegge seems to agree, given the amount of time he spends discussing different languages. I'll try to ride on their laurels, since they are way smarter than I am.
Just saying it is a good thing doesn't mean much if you can't specifically say what is good. Very briefly, here are some thing I've learned as I've learned different languages. I am not saying that I'm an expert at all of these languages; in fact, in many cases, it's the opposite. However, I have spent enough in them to gain some pearls of wisdom for my career. These pearls, taken together, have made me a better developer.
I included it, because through it came my first understanding of loops and basic programming constructs: the wonders of GOSUB. Yes, my BASIC pearl was, in fact, GOSUB.
Pascal took all those hand-rolled constructs from BASIC and formalized it. My pearl was that, when put into the native constructs of a language, the constructs learned in BASIC were much more useful and usable.
My pearl here was understanding how the metal works. Understanding that those thirty variables sitting in your function have to be swapped in and out of a limited number of registers was an important lesson. I wonder now, though, whether that lesson is as important today as it was when I was learning Assembly 15 years ago or if compilers have largely made this learning irrelevant. Still, it surprises me how many people don't understand why 1.1 cannot be represented in a native float type.
Once upon a time, it was the college teaching language. To be honest, I had a very difficult time with it. As I struggled to build a Pascal interpreter in Scheme, the pearl I learned was that all languages are equally powerful. It just so happens that some languages are more expressive in ways that are important for particular problems.
What can I say? The workhorse of systems programming. As I played with making code compile on various systems, the I learned was that it is possible to write close to the metal in a more abstract, efficient way. The pearl learned was that languages provide many trade-offs, and it is important to understand what you are trading when you choose a language.
C++ was my introduction to object oriented programming. While that could be pearl right there, it wasn't. My pearl came when I realized that a large team could effectively work together using the structure that object oriented applications created. While this is undoubtedly possible with other programming models, it felt right with OO.
I started using Perl as my first foray into web development. I had played around with shell scripts, awk, and the like for several years; but Perl was light-years ahead of those. My Perl pearl (don't pardon the pun...) was that a scripting language could be not just as powerful as a compiled language, but, in some ways, more powerful.
I debated admitting to this one, but I did find a pearl here and it's an important one. I was working for a company building CD-ROMs and for this project, time was of the essence. Given the form-building capabilities of Visual Basic, I could build the application very quickly. The pearl: focus on the business objective and not the technology. Even though the technology was...umm...sub-par, the business objective was successfully met.
I have a love-hate relationship with Java right now. I've learned more about how to develop software while writing Java than any other language (because I've written so much of it), but the language has not aged well (unlike the JVM, which has aged marvelously!). Ironically, given how strongly typed Java is, the pearl I learned from Java is that you don't always have to know the type (think Collections before [evil] templates).
It is funny how people love or hate Python, and most of it seems to come from significant white-space. I'd be lying if I didn't admit to needing to get over that as well. Once I overcame that, though, I gained my pearl: If you can write concise, readable code, you can introduce fewer bugs and be more efficient.
Erlang is a great language. I wish I had an opportunity to use it more. I honestly believe it could go a long way to reducing the difficulties so many developers have with multi-threaded code and so many systems have with scaling. And that, really, is my pearl: sometimes the tools we use are a variable in how tractable a problem is to solve.
These tid-bits do not encompass all I've learned from these languages. They do highlight what I consider to be key learnings I've taken from them. More important than any single pearl is the combination of unique pearls the whole gives.
I've also learned a few other languages over the years. My latest excursion is Objective C, which I can't say I've used long enough to gather my pearl yet. I'm sure it's in there somewhere, and I'll keep looking until I find it.
My point in this is two-fold: First, no matter what language you are "stuck" with at work, there is value in learning other languages. These pearls will make you rich.
Second, if you haven't found a pearl yet, keep looking. Try to find it, because the exercise of looking for your pearl is where all the value is.