How To Criticize Computer Scientists
or
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 about constants. 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 hardware.

The Insult

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.

Detecting Theory

You can tell someone is a theorist because they slip one or more of the following keywords and phrases into lectures and technical conversations: "theorem", "lemma", "proof", "axiom", "polynomial time", "logarithmic", "semantics", "numerical", "complexity", "nondeterministic" or "nondeterminism", and "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.)

Detecting Systems

An experimentalist will slip one or more of the following keywords and phrases into lectures and technical conversations: "architecture," "memory," "cpu" (sometimes abbreviated "CISC" or "RISC"), "I/O" or "bus", "network", "interface", "virtual", "compile" or "compiler", "OS" or "system", "distributed", "program" or "code", and "binary". 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:

• 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 have forgotten.)
  
• 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 scaling.)

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 sophisticated mathematics. (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 sophisticated mathematics (Again, the intended victim is likely to smile and thank you for the flattery.)
  
• 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:

• 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 insulting skills. In the future please make all your thrusts count.