The grammar and logic redundancy checking system (Score 1)

The grammar and logic redundancy checking system is designed to check for errors caused by overly ambitious or inexperienced paper writers. Our relatively uncontroversial hypothesis is that confused or incompetent writers in English tend to make mistakes. Worse yet, they repeat themselves. We experimentally test this hypothesis by taking a large sample of words written by two programmers and subjecting them to redundancy analysis. In our tests, each page of the academic paper was found to be 45% to 100% more likely to suffer from mistakes in logic and grammar than papers written by graduates in the Humanities. This difference holds across different types of programmers.

With the exception of a few stylized cases, programmers are generally attempting to perform useful work. /* BUG - This statement always evaluates to true. (Or does it?) */ (p.1)
If they perform an action, it was because they believed it served some purpose. /* BUG -- missing ELSE case */ (p.1)
Both statements say the same thing.

This difference holds across different types of redundancies. (p.2)
Of course differences have the distinct quality of being different. This is the sign of an overly cautious academic writer, possibly attempting to make his prose seem non-volatile.

Redundancy correlates with confused programmers who will probably make a series of mistakes. (p.7).
It strongly suggests that redundancies often signal confused programmers. (p.7)
Redundancies seemed to flag confused or poor programmers. (p.9)
Should we conclude that redundancies, confusion, and programmers are highly correlated?

Assuming programmers do not do redundant permission checks... (p.9).
Wasn't it the thesis of this paper that programmers make redundancy errors, and those errors are significant?

In To appear in IEEE Symposium ... (p.10)
Redundancy: in to appear in ?

2) switch conditions with impossible case's (p.5)
The plural of case is cases. True in all cases.

It is hard to believe that this code was ever tested. (p.4)
Or the paper proof-read. Try eliminating that. It's superfluous.

Xie and Engler cite themselves three times in their endnotes.

One final thought: did Xie and Engler run their redundancy checking code on their own redundancy checking code?