That may be, but it didn't stop me from crashing an entire LPAR, knocking the entire development staff off the mainframe by running a simple select sql statement against DB2.

One of the simplest constructs in C++ that makes me cringe is when I see people do:

std::string foo = "";

instead of:

std::string foo;

The reason being, although functionally equivalent, the second version results in faster, smaller code. On every implementation I've looked at the first one results in calls to strlen, a possible memory allocation and a strcpy. The second is a mere memset of the internal pointers to null. Even though us humans that understand C++, the compiler knows only the language. It typically does not know anything about the standard library. Yes, there are exceptions, such as compile-time warnings/errors for mismatched arguments to printf style functions. But, those are exceptions, not the rule, and they are few and far between.

When I see the first form, I immediately understand that I am looking at code from some whose primary language is not C++, but instead likely Java or C#.

Name mangling is not standardized, still, and it probably never will be unless there is a formalized ABI. It sounds like you were using STL from pre-standard days. Even post standardization, it took all of the compiler vendors to catch up. The landscape is a lot better now. In particular it's been great to see the effort MS has put into becoming standards compliant and treating C++ as a first-class citizen on Windows instead of the ugly step child locked in the attic because they can't kill it.

iostreams are a bit ugly, but at least they're type-safe. iostreams also have the added benefit of operator overloading, allowing types to format themselves. You can't do that with printf - you'd at a minimum have to have an extra string buffer to defer to a type to format itself to then pass to a printf for additional formatting.

I think it's more a function of what people "know" than "like". I also think this is true regardless of the language/tool set used. It is also usually an indicator of the developer's experience. A junior dev is far more likely than a senior to have a need for something and reinvent the wheel out of ignorance of available options rather than a justified reason to do so.

Or a library written in another language, in which case C, or more exactly, the ABI (usually dictated by your C runtime of choise), is the common dialect.

I agree that language comes down to preference and usually comfort level. Having +10 years experience with C++, C# and Python each, while roughly a year experience with Java & Ruby, my languages of choice, in order are: C++, Python, C#, Ruby, Java.

I particularly like C++ because of it's raw unabashed power. There's very little magic, and nearly every language construct is straight forward and easy to understand. Granted, there are a ton of subtle gotchas an nuances that will trip up the inexperienced and even the veterans. I like Python because the language itself is clean, succinct and terse (but not perl level terse). It also has the benefit of generally being easily readable by non-Python folks. I hear a lot of complaints about the whitespace, but when it comes down to it, it's a non-issue when you're used to it. If you indent your code well and normally in other languages, your code looks the same, but you've saved having to type the braces. One of the other things I like about Python is how well and cleanly it interfaces with C/C++. It's C object model is one of the cleanest and most straight forward I've ever seen. It is a breeze to interface with and expose C/C++ APIs to. Unlike perl with its abomination of a library: XS. I like C# for a lot of the same reasons: mostly clean language, expansive built-in library and removed a lot of the idiocy of Java (exception specs? ew. Double is an object, double is a value, wtf?

I have very little experience with Ruby, and I'm still learning. It seems a mix of Python & Perl which, I tend to stay towards the more Python-ic approaches in Ruby because they're clearer and make more sense to me.

As far as looking for a job, money isn't everything. A year ago, I left a job pulling in $155K base with bonuses around $40K per anum doing mostly C++ & Python, which I liked. But after a decade at the company, I'd enough of the stress and the B.S. politics, so I left for a job where I'm just pulling $145K base and little to no bonus doing mostly C#, Java, Ruby and maintaining legacy Python code. And, for now at least, I'm happier. Sure, I miss the money, but I still make enough.

Unfortunately, said small black holes often result in consuming the head attached to them, often resulting in what is colloquially referred to as rectal cranial inversion.

I think I'm allergic to Perl. Every time I see it, I have violent fits of sneezing.

Agree about the certifications. The only ones that aren't immediate red flags to me are government issued ones such as Professional Engineer (PE). The reason the government certs carry more weight is they also carry legally enforced responsibility, including, but not limited to, misrepresenting your abilities or competence in a given area or discipline. There are often legally enforceable ethical codes with the law typically deferring to the the discipline's governing body, for instance, for electrical engineers, the state of Illinois defers to IEEE for the ethics code (even better that the corrupt politicians don't attempt to come up with "ethics").

For the paid certs, it feels often as if the person took a crash course on $INSERT_VENDOR_HERE just long enough to pass a test, paid the money and got the cert. A cert doesn't make up for years of hands on experience. I know more about tuning SQL than most DBAs, but I'm not now, nor will I likely ever be certified by any vendor. People that can do. People that can't... get certified, or rather, plaster their certs all over their resume.

Enough said in the subject.

Doing the same thing over and over and expecting a different result is insanity. 10,000 hours of practice might be better thought of 10,000 hours of experimentation. Each repetition, you try something. If that doesn't work, you vary something slightly, repeat and observe the outcome. You then take that result and make another change, and repeat the whole process. If you just dedicated 10,000 hours doing the exact same thing, the exact same way, you're insane to expect anything other than the exact same result. Athletes don't spend 10,000 hours throwing a pass the same way, taking a shot the same way or swining a bat the same way. They make adjustments based upon (usually) microexperiments. There might be film involved or coaching (for the elite, there is definitely at least those 2 things).

Point is, there is far more to the superficial "10,000 hours will make you an expert" than pure repetition.

For an athlete, once the "ideal" motion has been identified, there is value in repetition insofar as to commit that motion to muscle memory, instinct and passive response instead of actively having to "tell" your body to do some specific set of motions.

Loss to infrastructure? Why did the US interstate highway system get built? It was a direct result of the US Army's difficulty in moving troops and equipment cross country. There are also requirements that every so often they roads remain straight long enough to be used emergency runways. I don't buy loss to progress, either. A lot of technological progress has been pioneered through military research. That I'm able to even post this comment right now was a result of DARPA funded work.

Yeah, and she's not biodegradable...

It's not a monopoly. It's just no one wants to learn reverse polish notation to use an HP calculator.