puter deployments.
Imagine how different OLPC implementation would be if it were instead
conceived as “one laptop per teacher.”
Julian m. Bass, addis ababa, Ethiopia
Refocus fragmented cs
conference culture
Moshe Y. Vardi was brave (and absolutely right) in taking on CS conference culture in his Editor’s Letter “Conferences
vs. Journals in Computing Research”
(May 2009). Consider how a new technique develops: Prof. Fragment has an
idea and publishes it at a workshop.
Several of his students refine and modify it over the next few years, publishing
their work in various conference proceedings. Another of his students iden-tifies a crucial application of the work.
Finally, Prof. Fragment gives an invited
lecture at a major conference, covering
the full story supplemented with compelling empirical evidence. Unfortunately, the lecture is not accompanied
by a paper. Now everyone wants to use
the powerful new technique, asking
Prof. Fragment for permission to spend
a sabbatical term with him at Jigsaw
University. He is able to accommodate
only one old pal, while everyone else
makes do with his group’s five conference papers and the online slides of the
invited talk. This typically consists of
more than 100 pages of material with
overlaps, omissions, and contradictions, because each paper represents a
different stage of the overall work.
Prof. Fragment would do the CS community a service by publishing his technique in one coherent journal article,
presenting the method, together with
refinements, applications, and empirical results. But if he were to write such
a paper, some referees would likely recommend rejection on the grounds it
contained nothing new.
Lawrence c. Paulson, Cambridge, England
Begin with an Author’s
Response to Reviews
We agree with Ken Birman’s and Fred
B. Schneider’s Viewpoint “Program
Committee Overload in Systems” (May
2009) regarding the shortcomings of
the conference-review system. A key factor is the lack of incentives for authors
to submit their best possible papers,
leading, as Birman and Schneider described it, to yet more submissions,
along with larger program committees
to accommodate them, overworked volunteer program-committee members,
and less-informed decisions, as these
members are able to read only a small
percentage of all submissions.
To discourage repeated submission of
the same manuscript—often unchanged
—to many different conferences, we propose a simple solution: require that all conference submissions provide two things:
History. A review history of the submission that includes the previous venues to which it was submitted, along
with the submitted versions and the reviews the authors received; and
Summary. An explanation of how the
authors addressed the concerns cited in
previous reviews.
This approach would allow program
committees to build on the expert
knowledge of the previous review committees where the level of expertise might
have differed from their own. Broadly
used, it would reinforce the argument
that publishing in a CS conference
is like a journal publication in other
disciplines. It also means authors are
further motivated to address or rebut
the concerns cited in previous reviews,
resulting in a better understanding of
the concerns. Finally, authors would be
discouraged from “shopping the paper
around” until it meets the bar of a particular program committee, encouraging
them instead to prepare an acceptable
manuscript before its initial submission.
Though this requires extra work by
authors at submission time, that work
is worth the benefit ultimately received.
The concern that some authors might
not disclose previous submissions can
be addressed the same way simultaneous submissions are treated—by clearly
stating the policy and consequences for
violating this trust.
Changing the existing system is not
difficult. All it takes is one program-committee chair doing an experiment.
If it’s a good idea and works, others
will follow. If not, it will get everyone
thinking about alternatives. Using an
author’s response to reviews is a recent
innovation but is already widely used in
the CS community.
Jose nelson Amaral,
Edmonton, alberta, Canada
michael hind, Yorktown Heights, n Y
name the field: computer
or computing
The words we use to describe things
profoundly affect how we think about
them, and once a term has gained a
foothold in a field, changing it and
its effects is nearly impossible. An
example is Peter J. Denning asking
“What is computer science?” in his
Viewpoint “Beyond Computational
Thinking” (June 2009). It has always
seemed strange to me that we call our
field “computer science” rather than
“computing science,” focusing our attention on the hardware and its design
and programming rather than on the
higher-level great principles that are
in fact independent of hardware and
historically part of other scientific disciplines.
Perhaps we should change our titles
and business cards to read “computing
scientist” from “computer scientist” to
emphasize this point.
harry J. foxwell, McLean, va
Author’s Response:
I endorse Foxwell’s view of “computing
science.” Old names stick when they
establish a brand that people generally
like. That seems to be the case for “
computer science,” a name established by
the founders of the field in the 1950s.
At that time, people in computationally intensive application areas (such
as physics and statistics) called what
they did “computing science,” but the
computer scientists of the day felt that
“computing” represented applications
and not the central focus of R&D. In the
1980s, we began using the term “
computing” in place of “computer science
and engineering.” Twice in ACM history some members proposed calling
the organization the Association for
Computing, but the required constitutional amendments failed, probably
because the voting members liked the
long-established brand name. Today,
ACM goes by the motto “Advancing
Computing as a Science and Profession.” We’re getting there.
Peter J. Denning, Monterey, Ca
Communications welcomes your opinion. to submit a
letter to the editor, please limit your comments to 500
words or less and send to letters@cacm.acm.org.
© 2009 aCM 0001-0782/09/0800 $10.00