Flame bait: D vs. Rust vs. Go Benchmarking

[Joseph Rushton Wakeling]

On Friday, 26 July 2013 at 12:08:06 UTC, deadalnix wrote:
> You put the limit at the wrong place. It is ok to say that some 
> piece of code is a shitty monstrosity, but ok to say that to 
> someone.

But you can also convey the same negative opinion about the code 
without using that kind of language. If it makes it more likely 
the code author will take on board the criticism and react well 
to it, why not? It costs you much less to temper your language, 
than to deal with an offended or angry developer.

> People get often offended because they associate themselves 
> with their code. This isn't a good thing, and a indicator that 
> the dev may have trouble to adapt/be territorial.

Yes, it's good to draw a line between "me" and "my code", and in 
my experience good people in any discipline are more harshly 
critical of their own work than anyone else's. But I wouldn't use 
pejorative descriptions of code as a deliberate technique to 
smoke out too-possessive developers. It's important to 
distinguish between people who are arrogant or bad team players 
versus people who react badly because they're not confident and 
read, "this code is crap" as a euphemism for "the developer that 
wrote this is crap". (Which, be fair, is sometimes what people 
mean, and they use criticism of code as a technique to bully a 
developer they don't like.)

If you avoid pejorative language, you can still deal with the 
problem people but you have less risk of causing other problems 
with abrasive behaviour.

> You don't always more dev in your boat as it means management 
> overhead (yes, even with FOSS, as someone have to review the 
> code, discuss it, etc . . .).

Sure, it's just that I wouldn't make "can they deal with abrasive 
criticism?" the selection criteria. If I had to, I'd prefer "Can 
they handle problems and disagreements, even severe ones, with 
intelligence and courtesy?"