One doesn't simply 'write to hard disk'. You ask the operating system to do that. The OS buffers writes and sends them to the disk in what it thinks is the most effecient blocking. And when you 'write to disk' you really 'ask disk device to write to disk (eventually)' A hard disk any more is a little computer dedicated to storing data on disk and retrieving it as quickly as possible.

Using the phrase "Macro metaprogramming" makes it sound like you don't understand C++. There are macros -- as in the C Macro preprocessor, which has been around for 40 years -- and there is Template Metaprogramming, which is a relatively new thing. But they're completely different. If one is serious about re-usable code in C++, one learns how C++ templates work. Templates complement C++ class inheritance by solving a different problem: where class inheritence allows re-use of code to manipulate similar data, Templates allow to reuse code on different data. The simplest example being something like: template Adder { T Add(T a, T b) { return a+b; } }; This template code works on anything -- built-in types or class objects -- that implements the '+' operator. Objective C had one advantage over C++ -- Closures/lambda expressions. Closures are now part of the latest C++ standard, and they're implemented in a more rigorous, type-safe manner.

I'm a musician and this is the #1 reason I don't use Linux for music. Every couple of years I drop a Linux distro on a computer -- and usually a Distro tailored for music production. Aside from the basic install time, I set a hard time limit of an hour from first login to being able to use a sound application productively. If I can't I give up on Linux for audio.

I think I've been doing this for 10 years, without ever breaking the one hour barrier.

I don't know about other media content creators, but musicians don't want to have to edit scripts, reboot repeatedly, and troubleshoot system logs in order to make music. The fact that Linux audio is such a rats nest of low level configuration difficulties and incompatible hardware and software feels like a huge roadblock to me.

And there is a fundamental issue with Linux software in general: It isn't finished the way for-profit software is. There isn't the extended, expensive QA and beta testing that is a significant part of any commercial developer's budget. This is doubly important when it comes to a musician's tools. If you can't depend on the software, you find different software, or go back to real instruments.

Bomb-proof wallpaper is great -- if the bomb goes off outside. If someone sets off a bomb INSIDE, it wll keep the force inside the room. Result? Soldier soup!

Every time I read one of these 'boo hoo more cores don't make things fasterer' stories I find it strange, since the problem domains with which I'm familiar -- Image Processing and Audio Software -- can and do already take advantage of multiprocessing.

In the audio world, you're pushing samples through a directed graph from inputs to outputs, and it's unambiguous to split the processing into threads that can keep the CPU fairly busy.

In Image Processing, and particularly in the Insight Toolkit that I work with daily, image filters are written to run separate threads on regions of the images. It isn't even particularly hard for most tasks, that iterate through a pixel at a time, requiring only read-only access to an input image.

And for software development, where you run builds and rebuilds all day, make -j 8 makes a hell of a difference in how long you wait to do something.

Computer games could really use more cores as well, because the view on screen has the same property as most image processing -- each pixel on screen is an independent computation. If you do parallel ray tracing, doubling the cores can nearly double the frame rate. That's why hardcore gamers pay the big bucks for multi-card solutions -- the graphics cards are rendering in parallel.

Now if you're talking about a spreadsheet or a web browser, it's hard to see the benefit. That's why so many people buy pokey little Atom netbooks -- nothing they do would have taxed a 1GHZ PIII ten years ago particularly.

I would defer to people with more experience with the ins and outs of hiring in mainstream IT to comment on that, but I have one observation:
Whatever you've done that is unrelated to software development can be spun as a positive, on a resume and in interviews. My personal experience is that having a B.A. in English has been a very positive thing on my resume, primarily because engineering attracts so many people who hate writing for human readers, and have the poor writing skills to back it up.
Your success in finding a software job are really going to be determined more by your ability to sell yourself as a problem-solver whose general intellectual abilities can make up for your lack of experience and education.
The other thing I'd say is that the number of jobs for pure C++ programmers is diminishing, and it's quite valuable to have some training and experience in the area of web development. The software industry as a whole seems to be moving towards a lot more web-based client-server programming, which means Java, JavaScript, Flash, SQL, and whatever the current flavor of the month is for web development -- Ruby on Rails, C#, etc.
And love it or hate it, learning to use the Microsoft web tools can get you a lot of jobs. Personally I think it's a lot like joining the Church of Scientology -- a whole lot of hermetic jargon, a whole lot of pointless BS -- but some companies are in bed with MSFT to the bitter end, and they love to see those certifications on resumes.

Reminds me of the old EE joke about the guy who says "to save connection count, we're going to multiplex power and ground ..."