[thisisit]

I normally use the - Half way there approach, trying to explain in detail as to why - realizing well that there are my biases at play but in the world of agile and fast moving changes, it is difficult to justify time for experiment and see what happens.

But then I look at author's claimed non-bias approach. The perl conversation is still the "half way approach". If a particular language is not used frequently it is easy to lose track of changes and new features/issues popping in.

Then there are company coding standards. Sometimes I look at a project where majority of the stuff is written in Java while a particular component is in C++. A lot of time the answer is, it was "easy to do". Even with documentation, it only leads to issues.