I don't think you know enough to know that yet. Or at least if you know enough you haven't told us enough to justify it. As cliche as it is, I'm going to quote Knuth: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"

I suggest you just do a prototype in whatever's easiest, fastest, and most flexible. Python, Ruby, C#, whatever you like. Get it working . Then see if it's slow as you think it is and go from there.

I see lots of hostile responses here (either way) but as a practical person who has to use C++, Python, bash, C#, and (argh) dos batch every week I would start with C# or Java (since you know those) and once you get the logic working like you want, see where the bottlenecks are then replace critical sections with C++ as you need to. That's worked really well for us. To begin with, the parts that we thought would need to be low level rarely were. Smart algorithms are much more useful than brute force. Or using libraries that do the brute force for you smartly. After a while you get a feel for it - but you don't have that yet.

The key bit is that you'll be 10x more productive in an expressive powerful language like C# or python than you will be in a restrictive fine detail language like C++, so it makes sense to bang out the framework in something flexible then only optimize the very smallest of key performance critical sections. Experience says that's less than 5%, usually 1%... so again, Knuth is right on the nose with his 3% estimate.

> But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant...."

This is extremely meaningful and important if you have some experience, because a lot of managers (and devs!) seem to think that a process is a silver bullet. Things going wrong? Let's switch to another version of agile, that'll fix it!

You need a process, but if you have all good developers it doesn't matter what process you're using (they'll come up with some loose form of agile if you don't supply one... and source control, and release process, and build server, and...), and if you have bad developers it doesn't matter what process you're using either, it won't work. An official process gives you a framework for mediocre developers to hang on, and maybe learn something and become better developers, I've seen that happen too. But the people who /really/ care about which process are more interested in the process game and selling you training, consulting, and books than actually getting work done. Or they're managers who think it's a silver bullet.

The crushing smugness as you preen around the other plebeian Moms who obviously don't care enough about their children is the benefit.

(This is a joke, yet not a joke).

This kind of ridiculous stunt is why the Germans are sick and tired of giving Greece money. They've been model world citizens and have been subsidizing Greece for decades, and trying to use this now is the ultimate in spoiled screaming teenager tactics. Nobody bankrupted Greece except Greece - as the Nordics, who actually got their shit together, very painfully, like to point out.

Germany are somewhat dour and grumpy parents, and a Grexit now is much less harmful to Eurozone than it would have been two years ago, so being kicked out of the house isn't out of the question at all. I wouldn't push it too hard.

I'm not German or Greek, but have been following this for years in the Economist and Bloomberg, and I know lazy scammers trying to wheedle more money rather than earn it.

Its greatest achievement was to be a C-like language in which legions of mediocre corporate coders can work on the same codebase without hurting each other too badly. This lets you replace COBOL.

Then the whole bytecode on a virtual machine thing, which while it had been done before (UCSD Pascal), Java's VM really made practical. People complain about Java's slowness, but the VM is really quite speedy (and the sandboxing is amazing). You can write high frame rate FPSes in it (Quake!). It's usually bad coders and bad frameworks that cripple performance. And without the JVM we probably wouldn't have .NET, Mono, and the CIL. Certainly not as good - it really helps to have done a previous version.

From TFA - consumer SSDs can expect 2 years, which is better than lots of HDs which probably won't spin up. Enterprise SSDs are faster but more ephemeral.

On the other hand I wouldn't count on this - cell drift is what causes the Samsung 840 slowdown after just a month.

And yes, I back all my stuff up constantly since I don't want to lose it. To platter drives just because it's much cheaper and speed doesn't matter.

This is from actually dealing with outsourcing in China, Singapore, India and Romania. For 15 years.

I know there are *smart* people everywhere, and certainly if you hire an Indian or Chinese person here s/he's as good as anyone else. When outsourcing it's mostly a *culture* thing where actually solving a problem is far down the list of things they care about - at the very top is not pissing off their manager(s) by making waves or pointing out problems, or, say, saving 5 cents per unit by swapping out components for one that will fail in 1/10th the time but not telling anyone. For the outsourcing company, the thing they care about most is getting paid in the short term, then moving on to the next contract. Those values can change, of course, but since it's heavily cultural it's a slow ship to turn. The best people who don't fit this pattern get snapped up by good local companies and don't work on outsourcing.

Right now I'm not worried at all - maybe in 20 years, but still not really, because the number of people who can problem solve will always be miniscule compared to the number of problems, and globalization creates tons more new problems.

GE and IBM aren't very convincing. Those hidebound old lumbering farts got in during the goldrush and are just fine with mediocre results as long as it costs little and they can charge even dumber institutional clients more than it costs them. It'll probably pay off spectacularly in the long run when those countries do get their engineering cultures together. They'll be well situated.

Problem solvers are far more in demand than ever, and that won't go away till we get strong AI (at which point the problem won't be offshore, but inCPU).

I don't mean 'engineers' like code pigs or most IT drones (not a dig at IT, really good IT people are engineers too). You just have to be someone who can take all information about the problem, including the constraints, then design and implement the best solution given the constraints - that means time, budget, reliability, support needs, end of life, etc.

The trouble is that most people can't do that, which is why it's in high demand. Risk assessment and mitigation are crucial and mostly untaught skills. Most people will just do what you tell them to, or take their favorite hammer and chainsaw and use it on everything in disregard of practical requirements. Most offshore 'engineers' fall into this category as well, which is one reason engineering outsourcing has such a bad stink among those who jumped on the bandwagon in the 2000s.

Which leads to the other problem - it's nigh impossible to learn except by doing. Normal path is to get an engineering degree, then join an engineering firm and work on actual products - though if you join a big boring place like HP you still may end up just learning to be a code pig unless you're lucky enough to end up in one of their very few interesting divisions (memristors!). Obviously this is long term project, high expense. High risk till you get the degree, then fairly low risk.

The other option is to just start making things. Make 'products' for yourself and try to finish them - i.e. make it something you could sell, even if you don't. This is easier than ever now thanks to explosion of low cost boards, motor controllers, cameras, drones... Get your hands on. Someone who can code, breadboard, solder and do servo control is a highly contested prize.

The bad news is you may find you're just not suited for it. In which case your best hope is probably to find an avoided niche like COBOL.

The good news is that if you're suited for it it's ridiculously fun and rewarding. Some days are still gonna suck, but generally you're solving interesting problems and making real things and people are using the things you made (this is THE BEST). Usually not as lucrative as banking or politics, but making decent money and helping rather than being scum of the earth (unless you go to work for Facebook, *zing*) is worth a lot of peace of mind.

Because C is so sparse and clean (or primitive, ymmv!), and people using C tend to be more experienced (almost nobody starts with C anymore - you use it because the job needs it), I find C programmers are a lot more likely to recognize things as ugly hacks and label them. It's partly defensive, because other C programmers are also old and cranky, so you're tagging it with YES I KNOW don't start with me. You don't want to check this in and have, say, Linus think you don't realize compromises were required.

On the other hand, JavaScript people seem to be a lot more 'hey, doing this weird thing works without dying - I'll push it to production.' (YMMV, that's just my experience).

I get these every day even though I've had the current job for five years. For things that aren't anywhere near anything on my resume. Recruiters are just bottom feeding scum, and it's gotten a lot worse since people in India (and Africa, and Eastern Europe, etc) have realized they can just browse LinkedIn then shotgun resumes to companies. The hit rate is tiny, but all they need is one. Local firms are bad as well, with apparently every single person from TCC contacting me about the same job.

LinkedIn is no better - 'Jobs you might be interested in: Mechanical Engineering Manager in Baton Rogue'. Really. I'm not an ME, I specifically say no management roles, and I specifically say unwilling to move. Maybe you should contract me to rewrite your jobs candidates engine, because I think I could do better in 2 days with 300 lines of python.

So why are you still on LinkedIn, you might ask... well, it is fairly amusing, and I can handle one or two a day. And if I ever need a job my profile will be there.

Not believing a word of this till they let some practical types have at it. Scientists are really easy to trick - just ask Penn and Teller.

People at Google have no real idea why people left their service (obviously). I'm sure those reasons do have something to do with it, but if they really knew how normal people reacted to things they wouldn't have such consistent spectacular self-inflicted product failures.

What finally killed it for me and my friends who were on it when it seemed to be growing well (though slowly), and left, was Eric Schmidt being an arrogant f@#4ing douchebag and doing a one-two whammy with the real names thing and the 'you're just a bunch of pigs whose data we're selling' thing. Sure that was the obviously the case, as with Facebook, but coming out and saying it was just too much for my plausible ego denial. It had a tough uphill climb ahead, and then they strangled it in the crib.

Yeah, this is a little flamey, but it's legitimately how I feel, no trolling. I was pretty upset he'd just torpedo it like that, and I'm sure people inside Google were rocking themselves in fetal positions as their point-haired executive crapped over everything they were trying to do.

You can't shame the (mainland) Chinese government on this one. They were fairly overt about it by using their own govt search engine to do it. It's a scarcely veiled threat to anyone who might want to mess with them, like doing an atomic bomb test or running your aircraft carriers around in sensitive regions. I'm sure they welcome the extra publicity.

You could cannibalize some Linux desktop installs.

But it will never be The Year of the *nix on Everyone's Desktop until you get devs and UI people who actually have any idea how normal clueless users work (or even care) and completely shelter them from the *nix underneath. That's anathema to normal *nix devs, so it would take someone like Apple to do it again. But even there almost no OSX users have any clue they're using BSD, and the giving is all one way -> BSD to Apple. Is it really The Year of BSD on the Desktop when nobody knows or cares? If so, it's already here.

It's a pride thing. You want to think that because your OS is so superior under the covers that everyone should be using it and it'll get more of the press it deserves. So you want everyone using it as their desktop and knowing they're doing so, even Mom or your teen kids. But swca dislike that Mom or the kids just want to /use/ it and not RTFM (YMomMV), so we're incapable of making a GUI/application suite that's so amazing they'll feel they have to convert. Even the desperate 'but it's free!' hasn't made a big difference.

So if you want to make a great *nix desktop for yourself, that's great! But thinking you're going to get a random person who thinks the big box is 'the cpu' to use it is just expensive vanity, and has been for almost 20 years. It just leads you to things like Unity.

Besides, even now, five years from 2020, casual users can get everything they need from mobile or web already.

The purpose of java is to keep legions of mediocre corporate coders from doing too much damage to each other, and it does pretty good at that. Tediously spelling everything out is one way to try to force some context for code you don't see often. Think COBOL.