A reprint from

American Scientist
the magazine of Sigma Xi, The Scientific Research Society

This reprint is provided for personal and noncommercial use. For any other use, please send a request Brian Hayes by
electronic mail to bhayes@amsci.org.
 Computing
Science
Cultures of Code
Three communities in the world of computation are bound together by common
interests but set apart by distinctly different aims and agendas.
Brian Hayes
K
im studies parallel algo-
rithms, designed for comput-
ers with thousands of proces-
sors. Chris builds computer
simulations of fluids in motion, such as
ocean currents. Dana creates software
for visualizing geographic data. These
three people have much in common.
Computing is an essential part of their
professional lives; they all spend time
writing, testing, and debugging com-
puter programs. They probably rely on
many of the same tools, such as soft-
ware for editing program text. If you
were to look over their shoulders as
they worked on their code, you might
not be able to tell who was who.
Despite the similarities, however,
Kim, Chris, and Dana were trained
in different disciplines, and they be-
long to different intellectual traditions
and communities. Kim, the parallel
algorithms specialist, is a professor in
a university department of computer
science. Chris, the fluids modeler, also
lives in the academic world, but she is
a physicist by training; sometimes she
describes herself as a computational
scientist (which is not the same thing
as a computer scientist). Dana has been
programming since junior high school
but didn’t study computing in col-
lege; at the startup company where he
works, his title is software developer.
These factional divisions run deeper
than mere specializations. Kim, Chris,
and Dana belong to different profes-
sional societies, go to different confer-
ences, read different publications; their
paths seldom cross. They represent
Brian Hayes is senior writer for American Scien-
tist. Additional material related to the Comput-
ing Science column can be found online at http://
bit-player.org. E-mail: brian@bit-player.org
10 American Scientist, Volume 103 © 2015 Brian Hayes. Reproduction with permission only.
different cultures. The resulting Bal-
kanization of computing seems unwise
and unhealthy, a recipe for reinventing
wheels and making the same mistake
three times over. Calls for unification go
back at least 45 years, but the estrange-
ment continues. As a student and ad-
mirer of all three fields, I find the stand-
off deeply frustrating.
Certain areas of computation are go-
ing through a period of extraordinary
vigor and innovation. Machine learn-
ing, data analysis, and programming
for the web have all made huge strides.
Problems that stumped earlier genera-
tions, such as image recognition, finally
seem to be yielding to new efforts. The
successes have drawn more young peo-
ple into the field; suddenly, everyone
is “learning to code.” I am cheered by
(and I cheer for) all these events, but I
also want to whisper a question: Will
the wave of excitement ever reach other
corners of the computing universe?
Setting Agendas
What’s the difference between com-
puter science, computational science,
and software development?
When Kim the computer scientist
writes a program, her aim is to learn
something about the underlying algo-
rithm. The object of study in computer
science is the computing process itself,
detached from any particular hardware
or software. When Kim publishes her
conclusions, they will be formulated in
terms of an idealized, abstract comput-
ing machine. Indeed, the more theoreti-
cal aspects of her work could be done
without any access to actual computers.
When Chris the computational sci-
entist writes a program, the goal is to
simulate the behavior of some physi-
cal system. For her, the computer is
Contact bhayes@amsci.org.
not an object of study but a scientific
instrument, a device for answering
questions about the natural world.
Running a program is directly analo-
gous to conducting an experiment,
and the output of the program is the
result of the experiment.
When Dana the developer writes
a program, the program itself is the
product of his labors. The software he
creates is meant to be a useful tool for
colleagues or customers—an artifact of
tangible value. Dana’s programming
is not science but art or craft or engi-
neering. It is all about making things,
not answering questions.
Should these three activities be treat-
ed as separate fields of endeavor, or are
they really just subdivisions of a single
computing enterprise? The historian
Michael Mahoney, an astute observer
of computing communities, suggested
that a key concept for addressing such
questions is the “agenda.”
The agenda of a field consists of
what its practitioners agree ought
to be done, a consensus concern-
ing the problems of the field, their
order of importance or priority,
the means of solving them (the
tools of the trade), and perhaps
most importantly, what constitutes
a solution…. The standing of the
field may be measured by its ca-
pacity to set its own agenda. New
disciplines emerge by acquiring
that autonomy. Conflicts within a
discipline often come down to dis-
agreements over the agenda: what
are the really important problems?
The issue, then, is whether Kim,
Chris, and Dana set their own agen-
das, or whether each of them has
merely chosen to concentrate on se-
 computer science
understand the nature of computation
Determine what can be computed.
Determine what can be computed
with finite resources.
Determine what can be computed efficiently.
Compare models of computation (e.g.,
classical and quantum).
Organize data for efficient storage
and retrieval.
Define the syntax and semantics of
programming languages.
Improve the human interface with computers.
Ensure the correctness of concurrent
operations.
Communities that share an interest in computing but have distinct goals
can be distinguished by their agendas: the lists of problems to solve and
tasks to accomplish that members of each community agree on. The idea
lected parts of a shared agenda. There
are certainly questions that would in-
terest all three of them. A prominent
example is “What can be computed
efficiently?” Theoretical computer sci-
ence seizes on this question as one of
its most central, existential concerns,
but the answer also matters to those
who write and run programs for prac-
tical purposes. Thus the three groups
might seem to stand on common
ground. The trouble is, a theorist’s an-
swer to the question may not be much
use to a practical programmer. Know-
ing that the worst-case running time
grows as some polynomial function of
the problem size doesn’t actually tell
you whether a specific computation
will take seconds or centuries.
The issue here is not that all comput-
er scientists are otherworldly theorists.
Sometimes the theoretical challenges
arise elsewhere. As a fluid dynamicist,
Chris has on her agenda the tricky
theoretical problem of partitioning a
continuous fluid into discrete parcels
suitable for processing by a digital com-
puter. Solutions to such problems have
come mainly from mathematicians,
engineers, and physicists rather than
computer scientists.
One of the glories of computer sci-
ence in its early years was a deep
analysis of programming languages.
Everyone who does computing would
seem to have a stake in this work. In an
interesting collaboration between com-
puter scientists, mathematicians, and
linguists, the languages were classified
www.americanscientist.org
computational science
use computation to understand nature
Map natural processes onto
computational ones.
Simulate the behavior of physical,
biological, and social systems.
Capture and manage large volumes of data.
Minimize numerical errors.
Solve large systems of linear equations.
Approximate the solutions of
differential equations.
Encode continuous quantities in
discrete form.
Devise ways to visualize spatial and
temporal patterns, such as vector fields.
of defining a community by its agenda was introduced by the historian
Michael Mahoney. Shown here are some possible to-do items for com-
puter science, computational science, and software development.
according to their expressive power.
The next project was to devise algo-
rithms for parsing programs—break-
ing statements down into their basic
grammatical units—and then assigning
meaning to the statements. Most of this
work was completed by the 1970s.
Programmers today are intensely
partisan in their choices of program-
ming languages, yet interest in the
underlying principles seems to have
waned. Two years ago I attended a
lunch-table talk by a young graduate
student who had turned away from hu-
manities and business studies to take
up a new life designing software. She
had fallen in love with coding, and she
spoke eloquently of its attractions and
rewards. But she also took a swipe at
the traditional computer science curric-
ulum. “No one cares much about LR(1)
parsers anymore,” she said, referring
to one of the classic tools of language
processing. The remark saddened me
because the theory of parsing is a thing
of beauty. At the very least it is a histori-
cal landmark that no one should pass
by without stopping to read the plaque.
But, as Edith Wharton wrote, “Life has
a way of overgrowing its achievements
as well as its ruins.”
Roots of Computing
Schisms in the computing community
can be traced back all the way to the
beginning of the digital electronic era,
circa 1950. The designers of the early
machines, such as the ENIAC in the
United States and the EDSAC in Brit-
© 2015 Brian Hayes. Reproduction with permission only.
Contact bhayes@amsci.org.
software development
write useful programs
Learn to manage complexity.
Map abstract concepts onto concrete
program structures.
Provide tools for debugging.
Provide tools for collaborative work and
code sharing.
Manage versions and variants of code.
Define mechanisms and standards
for exchanging data between programs.
Learn what factors influence programmer
productivity.
Learn what features make programming
languages more expressive.
ain, wove together ideas from sources
that must have seemed unlikely bedfel-
lows. Basic notions of how to “mecha-
nize thought” came from mathematical
logic, including the 19th-century work
of George Boole on a form of algebra
in which the elements are not numbers
but the values true and false. Electrical
engineering, and in particular switch-
ing theory, provided circuits that imple-
ment Boolean operations in hardware.
Mathematical logic became one of
the seed pearls on which theoretical
computer science grew. Circuit theory
also remains a core component of com-
puter science and engineering. Indeed,
the design and manufacture of hard-
ware represents yet another indepen-
dent computing culture.
Alongside mathematical logic and
electrical circuits, there was a third tra-
dition present at the birth of modern
computing. The users of those first
high-speed computing machines came
mainly from applied mathematics and
closely allied areas such as physics.
Prominent among the users were table-
makers, who compiled tables of loga-
rithms, trigonometric functions, and all
sorts of other quantitative information.
(The ostensible reason for building the
ENIAC was to compile ballistic tables
for artillery.) Another important con-
stituency among the users were the nu-
merical analysts, who devise schemes
for finding approximate solutions to
equations that cannot be solved ex-
actly. Most of the interesting problems
in the sciences fit this description. For
2015 January–February 11
the tablemakers and the numerical an-
alysts, the electronic computer was a
problem-solving or question-answering
tool; the heirs of these pioneers are to-
day’s computational scientists.
Notably absent from the planning for
early computer projects was any seri-
ous discussion of programming. For
each problem to be solved, a mathema-
tician or other professional was expect-
ed to design the scheme of computa-
tion, perhaps in the form of a flow chart
annotated with equations. Translating
this plan into instructions suitable for
the machine was viewed as a routine
clerical task, requiring no intellectual
engagement with the underlying ideas.
In the case of the ENIAC, six women
were recruited as “coders” to do this
work. Three of the six had majored in
mathematics in college, and all of them
were absurdly overqualified for clerical
The investment of effort that once printed
“Hello, world” on the computer screen now
brings the world itself to that screen.
duties. As it turned out, their qualifi-
cations were put to the test, because
the work of preparing programs for the
machine was anything but routine.
The discovery that programming
presents serious intellectual challenges
apparently came as a surprise to the
early leaders of the field. Maurice V.
Wilkes, the principal architect of the
EDSAC, had an epiphany while writ-
ing the first substantial program for
that machine in 1949:
The EDSAC was on the top floor
of the building and the tape-
punching and editing equipment
one floor below.… It was on one of
my journeys between the EDSAC
room and the punching equip-
ment that … the realization came
over me with full force that a good
part of the remainder of my life
was going to be spent in finding
errors in my own programs.
Recognizing that programming
requires skill and ingenuity elevated
the status of the occupation. Unfortu-
nately, not everyone benefited from
this upgrade. Women who had pio-
12 American Scientist, Volume 103
neered in the art of programming were
largely displaced by men—an issue
the profession is still dealing with 60
years later.
Silver Bullets
By the time computers were being
manufactured for commercial use, pro-
gramming was recognized as a costly
bottleneck. The work was tedious and
slow; people good at it were hard to
find; even the most talented and dedi-
cated programmers made mistakes.
Programming projects became notori-
ous for running over budget and be-
hind schedule. Progress in computing
was threatened by a “software crisis.”
The subsequent history of program-
ming methodology can be read as an
extended campaign to slay this drag-
on. Higher-level programming lan-
guages—closer to the vocabulary of
the problem domain, further from the
minutiae of the hardware—were the
first weapon, and the most effective
one. A regimen called structured pro-
gramming tried to untangle the logic
of programs by allowing only a few
kinds of loops and branches. Under the
banner of modularity, programs were
to be assembled out of pretested, reus-
able units. Another movement called
for formal proofs of program correct-
ness. More slogans paraded by: ab-
straction, encapsulation, declarative
programming, functional program-
ming, object-oriented programming,
design patterns, test-driven develop-
ment, ­agile development. The sheer va-
riety of these remedies is a hint that no
one of them was a cure-all. Even now
the software crisis is still with us: Wit-
ness the debacle of the Healthcare.gov
website in 2013.
The debate over software quality
has included repeated calls to make
programming a proper engineering
discipline, with recognized standards
of proficiency and perhaps require-
ments for certification or licensing. A
related trend imposed more manage-
© 2015 Brian Hayes. Reproduction with permission only.
Contact bhayes@amsci.org.
ment structure on the programming
process. In the software shops of the
1960s and ’70s, the way to get ahead
was to rise above the actual writing of
code and become a system analyst or
architect.
At the same time, however, anoth-
er strand of computing culture—or
counterculture—was moving in the
opposite direction. The enthusiasts
who called themselves hackers, most
famously situated at MIT among mem-
bers of the Tech Model Railroad Club,
saw computer programming as a puz-
zle to be solved, a world to explore, a
medium of self-expression. They saw
it as fun. They resisted the idea that
only an elite with engineering creden-
tials would be allowed access to the
machinery. The notion that program-
ming could be regulated or restricted
was further undermined when person-
al computers became widely available
and affordable in the 1980s.
Coding Is Cool Again
Another wave of irrepressible hacker
enthusiasm is washing over us now,
as a new generation discovers that
coding is cool. Introductory program-
ming courses, which had disappeared
from many college curricula, now at-
tract hundreds of students. At Har-
vard, for example, a hands-on pro-
gramming course called CS50 has an
enrollment of almost 900, the largest
in the entire university. Online cours-
es engage millions more. And a group
called code.org is working to revive
the study of computing in elementary
and secondary schools.
Why this sudden infatuation with
the nerdy side of life? Fad and fashion
doubtless play a part. So does the pros-
pect of creating the next billion-dollar
app. And there’s always excitement
in joining your generation’s mission
to change the world. Beyond all that,
I would cite one more factor. Within
the past five years, programming tools
have crossed a threshold of accessibil-
ity and power. It’s not that we have fi-
nally found the magic elixir that makes
programming easy and error-free. The
learning curve is still steep. But the
view from the top of the hill is spectacu-
lar. The same investment of effort that
once printed the words “Hello, world”
on the computer screen now brings the
world itself to that screen.
In 1984 I saw a demo of a mapping
program created by Michael Lesk and
his colleagues at AT&T Bell Labs. The
graphics were crude by modern stan- uisite to becoming a good program- Felleisen, Matthias, and Shriram Krish-
dards, but the program could answer mer. There’s abundant evidence to namurthi. 2009. Viewpoint: Why computer
science doesn’t matter. Communications of
geographic queries and recommend the contrary. But it is a necessary step the ACM 52(7):37–40.
routes from point to point in the New in absorbing the culture of computer Fritz, W. Barkley. 1996. The women of ENIAC.
York area. I was wowed. science. I am sentimental enough to IEEE Annals of the History of Computing
A key innovation in Lesk’s program believe that an interdisciplinary and 18(3):13–28.
was storing the terrain map in small intergenerational conversation would Gramelsberger, Gabriele (ed.). 2011. From Sci-
square tiles that could be loaded into enrich both sides, and help in knitting ence to Computational Sciences: Studies in the
History of Computing and Its Influence on To-
memory as needed. Twenty years lat- together the communities. day’s Sciences. Zürich: Diaphanes.
er, Google Maps employed the same Mahoney, Michael Sean. 2011. Histories of Com-
principle (with better graphics) to Bibliography puting. Cambridge, MA: Harvard Univer-
create the illusion that the computer Baldwin, Douglas. 2011. Is computer science sity Press.
screen is a window onto a vast unfurl- a relevant academic discipline for the 21st Wegner, Peter. 1970. Three computer cultures:
century? IEEE Computer 44(12):81–83.
ing map of the whole planet. New Computer technology, computer mathe-
Denning, Peter. 1985. What is computer sci- matics, and computer science. Advances in
tiles are fetched over the network
ence? American Scientist 73:16–19. Computers 10:7–78.
whenever you move the window or
zoom in and out. I was wowed again.
Google Maps was state-of-the-art
wizardry in 2005; in 2015 anyone can
do it. With a dozen lines of code—plus
an open-source library called Leaflet
and a free web service that supplies the
map tiles—you can create your own
mapping program, offering the viewer
the same breathtaking window-on-the-
world experience.
The grizzled curmudgeon in me
wants to object that this instant car-
tography is not real programming, it’s
just a “mashup” of prefabricated pro-
gram modules and Internet resources.
But building atop the achievements
of others is exactly how science and
engineering are supposed to advance.
Still, a worry remains. How will the
members of this exuberant new cohort
distribute themselves over the three
continents of computer science, com-
putational science, and software devel-
opment? What tasks will they put on
their agendas? At the moment, most of
the energy flows into the culture of soft-
ware development or programming.
The excitement is about applying com-
putational methods, not inventing new
ones or investigating their properties.
In the long run, though, someone needs
to care about LR(1) parsers.
Guy Lewis Steele, Jr., one of the orig-
inal MIT hackers, worried in the 1980s
that hackerdom might be killed off “as
programming education became more
formalized.” The present predicament
is just the opposite. Everyone wants to
pick up the knack of coding, but the
more abstract and mathematical con-
cepts at the core of computer science
attract a smaller audience. The big en-
rollments are in courses on Python,
Ruby, and JavaScript, not automata
theory or denotational semantics.
I would not contend that mastery of
the more theoretical topics is a prereq-

www.americanscientist.org © 2015 Brian Hayes. Reproduction with permission only. 2015 January–February 13
Contact bhayes@amsci.org.