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?
Slashdot Mirror
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) /* BUG -- missing ELSE case */ (p.1)
If they perform an action, it was because they believed it served some purpose.
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?