You prefer that everybody in this industry earns a precarious income and operates dirt-cheap stuff ? No high-end equipment whatsoever ? Yeah, that makes sense if you earn about as much as a McDonalds worker. Unfortunately, I do think your wish will come true.
Regarding IBM mainframes, they are worth their money and if you cannot see the difference to the cheap x86 stuff from Dell, that's your fault. Finally, every skilled factory worker stands in front of 500k Euros/dollars worth of hardware these days. You prefer that 10k$ Dell "server" ??

Sorry for messed-up formatting.

Most importantly, read the papers of David Kuck. A MUST for your professional development as a Computer Science graduate who wants to continue to work in this field (as opposed to doing "business" things). http://www.computer.org/portal/web/awards/pioneer-kuck http://www.dtjcd.vmsresource.org.uk/pdfs/dtj_v06-03_1994.pdf

Well, men use FORTRAN. Real men are not beancounters, they work on some lethal machinery. Semi-real men like me at least use C++ to do beancounting, which they call "statistics".

I don't think that you actually understand what you write. The CPUs are definitely not commodity, even if it would make sense to emulate the S/390 instruction set on x86 CPUs. Which it doesn't from a reliability/serviceability perspective. And "supercomputers" were the "men's" toys to simulate the weather and how to evaporate Russian cities, amongst other belligerent stuff. Mainframe != supercomputer. Mr Watson of IBM once tried to disprove that and got his fingers burned when he tried to compete with Seymour Cray. Actually, his little army of engineers got their fingers burnt when they competed against that single guy Cray.

Yeah, you ran Women's stuff on a Man's computer.

MapReduce is just the latest form of Batch Processing, with a fancy new name from the Googlers. So in 2005 Google discovered something IBM knew in 1955.

In the hands of a capable professional, objects can be at least as efficient as structures+procedures. Plus, you need a language with real destructors to immediately reclaim memory when you are done. I would argue that properly used classes and objects will improve your program in several dimensions. Think of automatically closed file and database handles when a method returns or the containing object is being destructed.
I currently work on a data analysis application which processes 32Mbyte/s of input data using C++ PER CORE. I tested it to linearly scale to 50 cores. And yeah, it works similar to a record-oriented Cobol program. Full-table scans are not as bad as they might sound. Index-oriented access is actually a very restrictive way of accessing large data sets and CS professionals should break out of the jail called "relational database". Not every lose part requires fixing by nail.

I am now at the middle of my life expectation and growing a bit smarter. And, I talk to a Cobol programmer then and now in the bus home. He works for an insurance company and will probably retire as a Cobol programmer for that company. He is a mathematician and I am a CS guy; I know much more than he about algorithms, C++, templates, macros, databases and whatnot.
But just recently I realized that Map-Reduce and "record-oriented processing" are actually very similar in that they do NOT consume voracious amounts of main memory. Both perform full-table-scans, in database parlance, which has unique advantages over index-based access for many scenarios.
That's all important if your data set is 100 times larger than your main memory. So the mainframers have that capability since 1955 and the C++ guys just discover this in the year 2005 or so ??
Cobol is here to stay for very systematic reasons very few people understand, including those with a CS degree and those developing in Cobol for a very long time. The latter do Cobol simply because it always paid nicely and there is absolutely no end in sight.

The term is "loop reordering". Essentially, you can iterate matrices row-wise or column-wise. If your matrix is stored row-wise, you better iterate it row-wise, or your cache locality will be very bad. Typical use case is matrix multiplication and solving linear equation systems. So that Mr Kuck of the uni of Illinois (now at Intel, still working !) created optimizing compilers which can do impressive things, including estimating how long a typical Fortran program run will take (surely that does not work for all categories of Fortran programs). In addition to that Mr Kuck developed compilers which would automatically exploit parallelism of "vector" hardware like the machines designed by Seymour Cray. Note that there is no need to explicitly say "parallelize this loop" as you need to do with OpenMP; the compiler can figure that itself ! Again, this proves that new != better. Fortran still beats C++ in numerical processing and that is quite interesting, considering the fact that Fortran is one of the very first programming languages ! Google Mr Kuck and his papers regarding Fortran compilers - it's an impressive part of computer science from the CDC6600 to the present day !