Joseph Ottinger:

I don't know Python yet... so I don't sit around wishing Java had features that I don't know how to use, nor do I routinely encounter problems in Java that distress me over their lack of solution. It's usually my knowledge that's at fault, after all, not Java's lack of solution. Why would I blame the language?

The Pragmatic Programmers:

Learn at least one new [programming] language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut.

This is valuable advice.

Thanks to Alan Turing, we know that computationally speaking, all programming languages are equivalent. If this meant they were all practically equivalent, we'd still be programming in Assembler. We're not. Instead, the history of programming has been a long procession of different languages, some of which are still going strong, and others that have withered or been superceded.

For a general purpose programming language to gain traction, it has to solve some set of problems better than competing languages. This is true of even commonly vilified languages like Basic and COBOL (or for that matter, Java). No language emerges in a vacuum: for any language to gain a following of programmers, it must attract them from competing languages by offering them something that they need.

(Paul Graham has a presumably slightly tongue-in-cheek but quite apt characterisation of languages based on what aspects of previous languages they 'fix')

Computational equivalence means that (ignoring for the moment practical matters like being able to address specific hardware), there are no problems you can solve in language A that can't be solved in language B. Language design, however, means that how A and B solve problems can be markedly different. Without exposure to other languages, it's far too easy to be blind to the fact that just because your language of choice can solve a problem, it may not solve it in the best way.

Take, for example, the canonical example of a QuickSort in Haskell:

  sort []           = []
  sort (pivot:rest) = sort [y | y <- rest, y < pivot]
                      ++ [pivot] ++ 
                      sort [y | y <- rest, y >=pivot]

If you understand Haskell, it's pretty clear that this is more elegant and expressive than the Java alternative. If you don't understand Haskell, you're more likely to have a "what the?" moment, and go back to hacking Java.

Having said that, I haven't ever programmed in Haskell (I coded in Miranda in first-year Computer Science, but haven't ever used it since). Nor, I suspect, will I soon. I contend, however, that knowing how different languages solve problems makes you a better programmer in any language. Some techniques can be adapted between languages, or can be embedded in a "little language" tailored to a particular problem domain. Even at the simplest level, knowing where your language of choice is limited helps you work around those limitations more efficiently.

The danger of learning new languages, though, is that each one increases the chance that you'll turn into one of those Internet whiners (like myself) for whom the best language for any job always seems to be the one you don't get to program in often enough to see its flaws close up.