Yeah you'd have to take them one-by-one and see if there is some proxy if you can't measure the behaviour directly. For example, with testing you could use code-coverage or even a binary variable for the existence of tests - not perfect, but would give better results than no control at all.

Definitely. Heck, in .NET's early days, there was a distinct difference in quality of the software and of the team using VB.net vs C#, when they were 99% the same language (they had some features unique to each, but they were very few). But C# was used a lot in new projects or by people familiar with Java while VB.net was used in VB6 migrations or teams coming from VB6. That had a drastic effect on the end result, but the language had very little to do with it.

The VB shops I've seen code from tended to really like `On Error Resume Next`, too...

Sure, I've seen global try/catch blocks swallowing all errors in C#/C++ code too, but definitely not as prevalent in my anecdata.

Some developers seem to be more along the lines of "On Error Resumé Next".