Being a programmer is akin to being an athlete. You're up to speed in what you do, and easily able to perform in a variety of fields, but have better ability in some areas than others. A middle distance runner can switch to long distance easily, less so to cycling, perhaps poorly to biathlon.
From a hiring point of view, you usually have legacy code or a chosen developer environment, and you want your new hire to fit it as neatly as possible. If it's a teaching situation, you absolutely want your new hire to know the core languages being taught, not a reasonable facsimile. But you also don't want to hire too narrowly, someone that is so locked into a single language mindframe that they're trapped.
Looking at the employee side, on my resume, my criteria is I only list languages that I've used for code delivered to a production environment, and for which I'd feel comfortable being handed a task due by the end of the week.
To illustrate the confusion...some languages are also packages. Matlab, IDL, and Mathematica are good examples. Do you list them with tools like 'Office' and 'InDesign', or with languages like 'Java' or 'C'? SQL is a language, MySQL is an implementation of that language. If you know MySQL, you largely know PostgreSQL and can also use and develop for Oracle (but not list yourself as an Oracle DBA). Are HTML and XML 'languages' or 'skills'?
At my first NASA job interview, they asked if I knew LISP. I said I would by the time the 3 month start date arrived. I got the job. That's part of what being a programmer is... you learn languages the way athletes pick up new sports. Quickly, and with great facility.
Alex, the daytime astronomer