Another interesting site question states:
In the book The Pragmatic Programmer, the authors suggest that you learn a new language every year. With so many new languages these days, what will be your next programming language and why?
I consider my time a valuable and scarce resource, as do many others here, I imagine. With that in mind, what languages do you think would be least useful for deepening and widening my understanding of good software development principles?
Intercal -- for the obvious reason that it was never meant to be used.
MUMPS!
http://en.wikipedia.org/wiki/MUMPS
http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx
That said, a better question would be what language should you learn...the list would be shorter. The list of ones not to learn come a dime a dozen as there are heaps of obscure languages.
J# is a dead end by now.
I would also try to avoid languages with limited tool/platform support.
Choose a language which provides a new way of abstracting things. This is the defining criteria for me. For example Haskel/f# are a good candidate for professional programmers who use imperative languages like C++/C# on a daily basis because its has a totally different way of looking at things (no mutable data, higher order functions i.e. functions as data, pattern matching etc.)
Or learn a quick to use and fun to learn language like python, boo, powershell scripting laguage, Javascript which might be helpful in meeting various odds and ends like use as a glue language, automation of routine tasks, quick prototyping etc.
Edit: Since this is a question about what not to choose I will add that do not waste your time with languages which do not have anything to add your problem solving skills. For example if you are a C# developer do not waste your time with java (and vice versa) unless you have some business requirement. (BTW I think C# is much cooler than Java :) just kidding)
Visual Basic for Applications (VBA) - (not to mix up with VB.NET).
As of July 1, 2007, Microsoft no longer offers VBA distribution licenses to new customers. Microsoft intended to replace VBA with .NET-based languages ever since the release of the .NET Framework.
Did one of your customers ever ask you: "Could you fix that small problem in this Word/Excel/Access application written by someone else?" and then you look at some virtually unmaintainable code (argh!)?
Moscow ML - a very pure functional programming language, highly recommended if you want to get a good feel for functional programming, not as complex as F#, more pure in its form and still performant.
The language to avoid is one that is badly designed, teaches you little new, and looks like it is in the process of being superseded by a competitor. It's hard to think of any clear candidates but I will place my reputation at risk by recommending two languages to avoid:
C++ is badly designed (read The Evolution of C++) and is largely superseded by its successor Java and its predecessor C.
Perl's design is at the very least highly controversial, has lost mindshare to Python and Ruby among others, and it looks like Perl 6 is never going to get off the ground, despite the heroic efforts of Audrey Tang.
Your question has not much sense without a context. What kind of programming are you interested in or already doing? If you are making real time embedded systems with C, C++ or Forth, I would say don't learn Java, C#, Python or any other high level language. If you are making "enterprise" programs, my advice would be exactly the opposite.
Although I agree with the concept of learning a new language to stay on top of the industry, I would argue that it's much much more important to learn methodologies, architectural, and design patterns.
The way I look at it is this: OOP is pretty much a mainstay. As a result, the major difference between languages is going to be syntax. It's how you design solutions that's going to change. Look at SQL -- regardless of whether you're using MSSQL, Oracle, MySQL, etc -- at the end of the day, it's still SQL. Granted, each one has it's benefits and it's differences, but would it serve you to learn all of the above? Or would it be better to learn things such as the Repository Pattern to loosely couple your solution between your DAL, BLL, and UI?
If you know C#/Ruby/Java, etc like a superstar ninja, but don't know what or how to implement a Singleton Design Pattern for instance, then you've wasted your time learning that language. Think of it as a hurdler -- with the language being your sneakers. You're going to reach the finish line, but it's your form (design patterns and methodologies) that's going to get you the gold. Running through the hurdles will just get you truck-fulls of disappointment.