I'd wage most programming still is done either in C++ or some C variety, especially if you take all the non-PC software into account. Other languages tend to be confined to niches (like databases, GUIs, or whatnot).
The language you use is heavily dictated by which part of the industry hires you. Insurance, financial, and telecom companies cover all manner of "dead" languages and platforms (even this far past Y2K, 20-year-old assembler code on mainframes is still in use, slowly being migrated to newer platforms and languages). Anyone who programs embedded or specialized hardware is likely using C and C++ (I'd never consider writing a video driver in any other language). All new Windows graphical interface-level work seems to be going on in C# with .Net, since it easily takes the route of Java by automating memory management and algorithms, making it quick and easy to get all of those buttons and widgets on the screen.
Given the sheer size of insurance, finance, and telecom industries, you'll find that assembly, COBOL, and mainframes are still very much alive. Or at least trying to gnaw on your brains. Lots of non-C++ languages are confined to niches, but some of them are very large niches with epic levels of inertia against change.
As NN indirectly pointed out, there's a very large industry demand for tech-school level programmers to do simplified programming, where the quantity of code and total number of features implemented is important, with relatively little complexity in the code. It becomes a matter of industry driving education -- most companies need a core team of skilled programmers for the complex work, and a team of trained code monkeys who pound out the simple stuff so the senior programmers don't get bogged down with shoveling monkey poo.
In a perfect world, the "code monkey" role is taken by recent graduates so they get experience with the real world, learn what college didn't teach them, and get promoted up to the more challenging roles.
Industry, on the other hand, is more than happy to hire in code monkeys with a minimum of training, so they push education to teach the minimum of knowledge, focus on simplified languages like Java and C# (since those are the languages they need), and in the end you have a lot of programmers who are competent to do the intro-level programming jobs, but lack the knowledge and background to get promoted out of the intro-level work. It also makes them cheaper to hire, and eliminates a lot of specialized knowledge, making them interchangeable -- companies love it when employees are simply resources that can be reassigned and replaced without risk. Or outsourced.
But teaching C++ as a core language is not a solution in and of itself. I used to work for a company whose hiring practices could be best described as "start with scraping the bottom of the barrel, then get out the pick and shovel" -- they obtained skilled employees by acquiring companies like mine, then watching the talent hemorrhage away. And that's the job where I developed a seething hatred for templates, STL, and Boost -- a rage that really applies to all programmers who have no clue what they're doing, rely on all possible crutches, and don't understand memory management ("What's wrong with caching an iterator?"), algorithm complexity ("It runs fine on my test set. Why does it take CNN three days to import their clip library?"), data structures ("I'm just indexing into this linked list."), and so many other things.
Whenever you hear anyone preaching about how awesome C++ is, there's generally two things at work. First, there's the elitism -- you can't really get away from that anywhere, can you? Second, most of us who've been around long enough to easily recognize the shortcomings of specialized languages have learned enough other languages to understand the value and problems inherit to specialized languages.
That's the main issue with only teaching specialized languages to programmers: they won't learn the trade-offs of specialized languages. Anything you want to do, you can do in C++, which makes it both powerful and unwieldy. It's both a scalpel and a rocket launcher at the same time (polymorphism at work, folks). The value of specialized languages is that you can design them to make certain tasks easy, while not supporting operations that are deemed unnecessary or dangerous (Java's pointers). A specialized language can make you very productive for its intended purpose, but hampers you if you try to do anything unusual -- especially shoehorning in a feature deemed "essential" by marketing, but not directly supported by the language.
Companies that do web programming want Java/Brew programmers. Those doing Windows apps want C#/.Net programmers. They want them fast, cheap, and interchangeable. Which short-changes the students who get fast-tracked for a corporate code-monkey job.
Maybe it's just my personal C++ elitism, but if I have to work with a programmer proficient in C++, odds are good he has a solid education in computer science (or real-world programming), and will probably be able to follow along if I have to delve into complex subjects -- i.e., fix something that's broken. When I'm working with someone who does not know C++ and thinks C# or Java is the shizznit, odds are good his eyes will turn hazy when I try to discuss any advanced subject that a four-year CS major should know cold -- i.e., explain why his code is broken.
Traversing data structures, for example, is an essential part of programming. If you don't understand data structures or pointers, and your language or STL/Boost is doing all of the heavy lifting for you so you never have to think about what's going on under the hood, you've got a serious problem. How can you debug something if you don't know what's really going on? It's one thing to understand reference counting, but to use smart pointers because you don't want to be bothered. It's something entirely different to use smart pointers
because you don't understand reference counting -- and then run into bugs when SQA detects major leaks because of circular references, and the code review reveals that the problem is so pervasive that fixing it would require pushing out the shipping date by a month.
That's the main problem I have with the current crop of programmers -- they're competent enough to do intro programming work, but as soon as any serious problems arise in their code, they're in over their heads and floundering. Give 'em tasks within their comfortable skill set, and they frequently can knock out a whole bullet list of features with impressive speed. Face them with a bug that results from the deep logic in the libraries they're using, and they are completely lost. Unless a google search hits on someone else who faced the same problem and posted their work-around.
The smarter ones eventually learn, but it takes them much longer to grow into being more than just another interchangeable code monkey. And that's why I think that education is failing anyone who goes through a program that focuses on delivering what industry asks for instead of teaching the essentials of programming. It's also why myself -- and probably a lot of others -- do not like hearing anyone proclaim C++ a dead language that is not worth learning. If you're not learning C++, you're very probably not learning a lot of other essential subjects as well.
) anyway thank you all for the links etc 
