How To Criticize Computer Scientists
Avoiding Ineffective Deprecation And
Making Insults More Pointed
In recent exchanges, members of the faculty have tried in vain to attack
other Computer Scientists and disparage their work.
Quite frankly, I find the results embarrassing -- instead of cutting the
opponent down, many of the remarks have been laughably innocuous.
Something must be done about it because any outsider who hears such blather
will think less of our department: no group can hold the respect of others
unless its members can deal a devastating verbal blow at will.
This short essay is an effort to help faculty make their remarks more
pointed, and help avoid wimpy vindictives.
It explains how to insult CS research, shows where to find the Achilles'
heel in any project, and illustrates how one can attack a researcher.
The Two Basic Types Of Research
Most lousy insults arise from a simple misimpression that all researchers
agree on the overall aims of CS research.
They do not.
In particular, CS has inherited two, quite opposite approaches from
roots in mathematics and engineering.
Researchers who follow the mathematical paradigm are called
theorists, and include anyone working in an area that
has the terms "analysis", "evaluation", "algorithms", or "theory"
in the title.
Researchers who follow the engineering paradigm are called
experimentalists, and include most people working in areas that
have the terms "experimental", "systems", "compiler", "network",
or "database" in the title.
Complex Theory And Simple Systems
Knowing the tradition from which a researcher comes provides the basis
for a well-aimed insult.
Theorists Favor Sophistication
Like mathematicians, theorists in Computer Science take the greatest
pride in knowing and using the most sophisticated mathematics to solve problems.
For example, theorists will light up when telling you that they have
discovered how an obscure theorem from geometry can be used in the
analysis of a computer algorithm.
Theorists focus on mathematical analysis and the asymptotic behavior of
computation; they take pride in the beauty of equations and don't worry
Although they usually imply that their results are relevant to real
computers, they secretly dream about impressing mathematicians.
Experimentalists Favor Simplicity
Like engineers, systems researchers take pride in being able to invent
the simplest system that offers a given level of functionality.
For example, systems researchers will light up when telling you that they
have constructed a system that is twice as fast, half the size, and
more powerful than its predecessor.
Experimentalists focus on the performance of real computer systems;
they take pride in the beauty of their code and worry about constants.
Although they usually imply that their results can extend beyond real
computers, they secretly dream of filing patents that apply to extant
Knowing that CS can be divided into two basic groups helps immensely
when criticizing someone.
There are two basic rules:
identify the type of the researcher and
issue an insult for that type.
Avoid saying anything that inadvertently compliments them.
If performed well, an insult will not only stun the researcher (who will
be shocked to learn that not everyone agrees with his or her basic value
system), but will also intimidate others in the audience.
Identifying A Type
Identifying the type of a researcher is usually easy and does not require
a strong technical background or real thinking.
It can be done using keyword matching according to the following lists.
You can tell someone is a theorist because they slip one or more of the
following keywords and phrases into lectures and technical conversations:
"nondeterministic" or "nondeterminism",
"for large enough N".
They write lots of equations,
brag about knocking off the "extra log factor",
and often end their lecture with an uppercase "O"
followed by a mathematical expression enclosed in parentheses.
You can also recognize a theorist because they take forever to
prove something that may seem quite obvious. (I once sat through an
hour lecture where someone proved that after a computer executed an
assignment statement that put the integer 1 into variable x,
the value in x was 1.)
An experimentalist will slip one or more of the following keywords and
phrases into lectures and technical conversations:
(sometimes abbreviated "CISC" or "RISC"),
"I/O" or "bus",
"compile" or "compiler",
"OS" or "system",
"program" or "code",
They talk about building programs and running the resulting system on
real computer systems.
They refer to companies and products, and use acronyms liberally.
Their lectures often end with a graph or chart of measured system performance.
You can also recognize an experimentalist because they describe in
excruciating detail how they set up an experiment to measure a certain
value even if the measurement produced exactly the expected results.
(I once sat through an hour lecture where someone carefully explained how
they used three computer systems to measure network traffic, when
their whole point was simply to show that the network was not
the cause of the problem they were investigating.)
Forming An Insult
The key to a good insult lies in attacking whatever the researcher holds
most dear and avoiding whatever the researcher does not care about.
Thus, an insult lobbed at a theorist should focus on lack of sophisticated
mathematics such as the following:
In contrast, an insult lobbed at an experimentalist should imply that the
techniques were used in previous systems or that the work isn't
practical such as:
Despite all the equations, it seems to me that your work didn't
require any real mathematical sophistication. Did I miss something?
(This is an especially good ploy if you observe others struggling to
understand the talk because they will not want to admit to that
after you imply it was easy.)
Isn't this just a straightforward extension of an old result by
Hartmanis? (Not even Hartmanis remembers all the theorems Hartmanis
proved, but everyone else will assume you remember something they
Am I missing something here? Can you identify any deep mathematical
content in this work? (Once again, audience members who found the
talk difficult to understand will be unwilling to admit it.)
Wasn't all this done years ago at Xerox PARC? (No one remembers
what was really done at PARC, but everyone else will assume you
remember something they don't.)
Have you tested this on the chip Intel got running last week in
their lab? (No one knows what chip Intel got running last week,
but everyone will assume you do.)
Am I missing something? Isn't it obvious that there's a bottleneck
in the system that prevents scaling to arbitrary size? (This is safe
because there's a bottleneck in every system that prevents arbitrary
How To Avoid Having An Insult Backfire On You
A misplaced insult can backfire, turning into an embarrassment for
the attacker and a victory for the intended attackee.
To avoid such occurrences, remember the following:
Never attempt to attack theoretical work as not considering constants,
as unrelated to real computer systems, or as requiring too much
(The intended victim is likely to smile and thank you for the flattery.)
Never attempt to attack a system as too small, too simple, or as lacking
(Again, the intended victim is likely to smile and thank you for the
Never attempt to attack systems work simply by saying that it's so
simple and obvious that you could have done it.
(For years, people said that about UNIX and the TCP/IP protocols.)
In fact, this is merely an extension of a ploy used by children on a
playground: "Oh yeah? I could have done that if I wanted to."
Don't try using it or someone will tell you to grow up.
Attacking Crossover Work
Although rare, a few researchers include both theoretical and experimental
work in the same project.
Insulting such combinations can be tricky because a researcher can escape
unscathed by pointing to one part of their work or the other as the answer.
You can try to attack both parts simultaneously:
However, a clever insult can avoid talking about the work by suggesting
sinister reasons for the paradigm shift:
I note that the systems aspect of this project seems quite complex.
Do you think the cause of the convoluted implementation can be attributed
to the more-or-less "simplistic" mathematical analysis you used?
I notice that you did something unusual by combining both theory and experiment.
Did you decide to try a second approach because you had insufficient
results from the first?
You seem to have a little theory and a little experimental work combined
into one project.
Isn't it true that if you had a sufficiently strong contribution in one
or the other you would have lectured about them separately?
A Final Plea
I certainly hope faculty will take this essay to heart and sharpen their
In the future please make all your thrusts count.