Communications of the ACM
Where Is the Science in Computer Science?
We are all members of the Association for Computing Machinery. Sounds sort of electromechanical doesn't it? Given today's computing technology, it is probably a good thing we are mostly known as ACM! There was a time when the physical artifactthe computerreally was the focus of attention. These behemoths occupied rooms full of equipment. Now, in fairness, if you have ever visited a cloud computing data center, the dominant impression is still a (vast) room full of machinery. But we carry huge quantities of computing power in our pockets and purses too. Computing is a remarkable artifact and its origins centered on the ability to make a piece of equipment calculate under programmable control. Alan Turing, whose 100th birthday we celebrated this year, drew dramatic attention to the artificiality of these systems with what we now call the Universal Turing Machine. This conceptual artifact emphasizes the artificial nature of computation.
In the physical world, science is largely about models, measurement, predictions, and validation. Our ability to predict likely outcomes based on models is fundamental to the most central notions of the scientific method. The term "computer science" raises expectations, at least to my mind, of an ability to define models and to make predictions about the behavior of computers and computing systems. I think we have a fairly good capability to measure and predict the physical performance of our computing devices. We can measure clock speeds, latencies, memory sizes, and computational capacity against standard computing tasks. In my view, however, we are much less able to make models and predictions about the behavior and performance of the artifact we label "software." An almost flippant analogy is the difference between measuring, modeling, and predicting neural brain functions and trying to do the same for "thought."
That software is an artifact seems obvious. Moreover, it is a strikingly complex artifact filled with layer upon layer of components that exhibit dependencies and complex and often unpredicted (not to say unpredictable) behaviors. Even though we design software systems and ought to have some clues about how these systems behave and perform, we generally do not have a reliable ability to anticipate the states these systems can get into, their vulnerabilities, their performance, and ability to adapt to changing conditions.
When we write a piece of software, do we have the ability to predict how many mistakes we have made (that is, bugs)? Do we know how long it will take to find and fix them? Do we know how many new bugs our fixes will create? Can we say anything concrete about vulnerability? What about the probability of exploitation? Murphy's Law suggests that if there is a bug that can be exploited for nefarious purposes, it will be. ACM Turing Award recipient Fred Brooks' wonderful book, The Mythical Man-Month1 captures some of the weakness of our understanding of the nature of software. A complementary look at this topic is found in ACM Turing recipient Herbert A. Simon's The Sciences of the Artificial.2 Chapter 8 deals with hierarchy and complexity, touching on the way in which we try to bound complexity through modular and hierarchical structures but are still challenged by the emergent behaviors masked, in some ways, by the beguiling apparent simplicity of the hierarchy.
The richness of our field has only grown in the 65 years of our existence as an organization. Computers, computing, software, and systems are seemingly omnipresent. We are growing increasingly dependent upon what must be billions of lines of code. Some unknown wag once quipped that the only reason all the computers in the world have not failed at once is that they are not yet all on the Internet. But that may be coming (not the collapse, I hope, but the interconnection of a vast number of programmable devices through the Internet or its successor(s)).
As a group of professionals devoted to the evolution, understanding, and application of software and hardware to the myriad problems, opportunities, and activities of modern society, we have a responsibility to pursue the science in computer science. We must develop better tools and much deeper understanding of the systems we invent and a far greater ability to make predictions about the behavior of these complex, connected, and interacting systems. I consider membership in the ACM a mark of recognition of that responsibility. I hope you share that view and will encourage others in our profession to join ACM in the quest for the science in our discipline.
References
1. Brooks, F.P. The Mythical Man-Month, Anniversary edition, 1995. Addison-Wesley, Reading, PA, ISBN 0-201-83595-9.
2. Simon, H.A. The Sciences of the Artificial, 3rd edition, 1996. MIT Press, Cambridge, MA, ISBN 0-262-19374-4.
©2012 ACM 0001-0782/12/10 $15.00
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from [email protected] or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2012 ACM, Inc.
Comments
Jacques Sauve
Science is about studying existing entities. It is done empirically, through observation and using inductive reasoning.
These entities are sometimes natural (as studied by physicists, say) and sometimes man-made (as made by engineers).
A lot of "computing" is about building things. As such, it is engineering.
But once the things are built, they must be studied (evaluated, validated, their attributes predicted, etc.) through the scientific process, using hypotheses, refutation and everything else that science does.
Some of computing is also based on deductive reasoning (math, logic) and, as such, is not science.
Anonymous
There should hardly be any doubt about CS being Science, by its nature as well as evolution primarily from scientific diciplines. Moreover, irrespective of the context all the disciples are tending to be formalised or scientified. At the deepest level the things emerge to be largely computational leading to evolution of disciplines viz bioinformatics, computational biology/ chemistry/ linguistics etc. So calling shots for CS even to be 'natural' science may not be bad idea but may be a step forward to move on and exlain using the context.
Anonymous
Software architects/engineers who ignore (or are ignorant of) the 'laws of computing' that have been discovered by computer scientists and try to go against them will waste their time and effort.
While I was in graduate school at a certain university, the university's IT department decided that too many first year programmers were writing programs containing infinite loops. They wrote up a project spec. for a filtering program that would scan each submitted program and if it contained an infinite loop, would reject it and display an error message for the student; otherwise, it would run the program normally. Never having heard of the Halting Problem, they spent 6 person-months on the project before asking someone in the CS department why they were having so much trouble engineering a solution.
So I believe CS is a science in the sense that its practitioners seek to discover fundamental laws of computing, to classify problems and their algorithmic solutions, to identify provably optimal problem solutions, and so on.
Raju Chiluvuri
Sir, with all due respect, 500 years ago there is no science in the basic sciences because they had been evolved by relying on myths such as Earth is static at the center. Toady computer science is not real science, because it has been evolving by relying on unsubstantiated axiomatic assumptions since 1960s. The computer science can be real science, when each of the errors in basic axioms of computer science and software engineering are exposed. This is focus of my research spanning more than a decade. I provided comprehensive proof to expose certain errors in very critical basic axioms of computer science and software engineering openly in my website: http://real-software-components.com/ simple proofs are provided at blogs: http://real-software-components.blogspot.in/2014/02/a-simple-proof-for-high-school.html and http://raju-chiluvuri.blogspot.in/2014/02/most-software-experts-lost-their_27.html.
I agree computer science is not a real science today, but I respectfully insist computer science can be transformed in to real science (in short span of time). The focus of my research is only limited to exposing errors in software components and CBSD (component based design for software), in order to invent real-software-components and real-CBSD. So I believe this kind research can be replicated to formalize other areas of computer science.
CACM Administrator
The following letter was published in the Letters to the Editor in the January 2013 CACM (http://cacm.acm.org/magazines/2013/1/158757).
--CACM Administrator
To the question Vinton G. Cerf addressed in his President's Letter "Where Is the Science in Computer Science?" (Oct. 2012), my first answer would be that there isn't any. Max Goldstein, a mentor of mine at New York University, once observed that anything with "science" in its name isn't really a science, whether social, political, or computer. A true science like physics or chemistry studies some aspect of physical reality. It is not concerned with how to build things; that is the province of engineering. Some parts of computer science lie within mathematics, but mathematics is not a science and is rarely claimed to be one.
What we mislabel as computer science would more aptly be named "computology"the study of computational processes and the means by which they can be realized. Its components can broadly be grouped into three interdependent areas: software engineering, hardware engineering, and the mathematics of computation. Just as the underlying discipline of chemical engineering is chemistry, the underlying discipline of software engineering is mathematics.
But not so fast. To qualify as a subject of science, a domain of inquiry needs two qualities: regularity and physicality. Reproducible experiments are at the heart of the scientific method. Without regularity they are impossible; without physicality they are meaningless. Digital computers, which are really just very large and complicated finite-state machines, have both these qualities. But digital computers are artifacts, not part of the natural world. One could argue either way whether that should disqualify them as a subject of science. Quantum computing and race conditions complicate the picture but not in a fundamental way.
None of this detracts from Cerf's essential pointthat when we design software we rarely understand the full implications of our designs. As he said, it is the responsibility of the computing community, of which ACM is a vital part, to develop tools and explore principles that further that understanding and enhance our ability to predict the behavior of the systems we build.
Paul W. Abrahams
Deerfield, MA
CACM Administrator
The following letter was published in the Letters to the Editor in the January 2013 CACM (http://cacm.acm.org/magazines/2013/1/158757).
--CACM Administrator
In his President's Letter (Oct. 2012), Vinton G. Cerf wrote: "We have a responsibility to pursue the science in computer science [...and to develop] a far greater ability to make predictions about the behavior of these complex, connected, and interacting systems." This is indeed a worthwhile cause that would likely increase the reliability and trustworthiness of the whole field of computing. But, having picked up the gauntlet Cerf threw down, how do I make that cause fit the aspects of computer science I pursue every day?
Cerf discussed the problems software developers confront predicting the behavior of both software systems and the system of people developing them. As a professional developer, I have firsthand experience. Publishing a catalog of the issues I find might lead analysts to identify general problems and suggest mitigations would be subject to two limitations: probably not interesting enough for journal editors to want to publish and my employers likely viewing its content as commercially sensitive.
I could instead turn to the ACM Digital Library and similar resources, looking for ways to apply it to my professional work. However, this also has limitations; reading journal articles is a specialized, time-consuming art, and the guidance I would need to understand what and how results are relevant is often not available. Many of the "classic results" quoted by professionals turn out to be as verifiable as leprechaun sightings.(1)
To the extent the creation of software can be seen as "computer science," such creation is today two distinct fields: creating software and researching ways software can be created. If we would accept the responsibility Cerf has bestowed upon us, we would have to create an interface disciplinecall it "computer science communication"between these fields.
Graham Lee
Leicester, U.K.
REFERENCES
1. Bossavit, L. The Leprechauns of Software Engineering. Leanpub, Vancouver, B.C., 2012; https://leanpub.com/leprechauns
Displaying comments 11 - 16 of 16 in total