There's an old saying that my friends in other fields love to bring up from time to time: any discipline that has science in its name, probably isn't a science.
Are they right? Is there some truth in that statement?
When I started to think about this question, I thought I could get it all into a single post. But the more I thought about it, the more I realized how complex this question really is. So this will be the first post in a series exploring whether (or under what circumstances) computer science can be considered a science.
First, some background. Why am I interested in this question anyway? I'm a computer scientist, I identify myself as such, I don't have any inferiority complex about the work that I do, or in general the work going on in my field. Call me biased :), but I truly think that computer science as a field offers some of the most interesting, challenging, and fundamental questions and areas of exploration. Computer science, and technology in general, already has transformed society and culture and science and art and [insert favorite field here] in fundamental ways, and we've just begun to scratch the surface of what's possible. I mean, what can be cooler than that?
The thing is, though, that as a computer scientist, I don't fit neatly into any of the traditional groupings of disciplines. I work with scientists. And engineers. And humanities types. And artsy folks. And social scientists. And librarians. Did I leave anyone out? Because I probably work with them, too.
Let's just take science as an example. I am often, as a computer scientist, associated with the other scientists on campus. And up to a point, that association works well, since we share some experiences and lingo and such in common. But there are fundamental ways in which we differ (the need for a traditional, physical lab being the one that comes most readily to mind). And there are a nontrivial number of scientists who think that computer science shouldn't be considered a science, because it doesn't pass the "litmus test" of what science is.
Substitute "art" or "engineering" or [insert favorite field or discipline here] for "science", and you could make similar arguments.
Computer science is in many respects a tool. It's a discipline that has its reach into many other disciplines. And that's one of the coolest, most interesting things about it. But that's also what makes it so hard to classify, to quantify. Computer science doesn't have to neatly fit anywhere, of course. But classifying it as something could make it a bit easier for non-computer scientists, and even computer scientists, to begin to understand just what it is and what its purpose should be. Having this strong sense of "self", of identity as a field, is, I believe, crucial to the survival of computer science as a field.
In subsequent parts of this series, I'll look at some definitions of "science" and "engineering" and maybe even "art" and discuss how computer science does or doesn't fit those molds, and what that means for the acceptance of computer science as part of those disciplines.
- Log in to post comments
While you're at it, I'd appreciate hearing your take on the intersection/overlap or any other relationship between computer science and information science.
Hi Jane, I just discovered this space today, like right now. You happen to be posting on one of my favorite topics!
I'll try to keep my $0.02 here short: Most of those who question the status of computer science as an actual science assert that it is more properly classified as engineering. The problem with this is that all engineering is an application of scientific knowledge. If computer science is engineering, what is it an application of?
That's a rhetorical question, of course. Computer science is an application of our knowledge of computation. What brings computer science into contrast with almost all other disciplines is that the central phenomenon we study is almost entirely defined and investigated through abstract mathematics. On the other side, it's also distinctive in that it has been so tightly intertwined with its technological applications that it is difficult to make finely grained distinctions between the preceding and the purely scientific content.
But the scientific content is certainly there, IMO. For instance, whether efficient algorithms exist for NP-hard problems is an objective scientific question that has yet to be resolved.
In terms of its impact as a science, I think it's often underrated. It doesn't have the perception of reality altering impact of physics, for instance, but it would be difficult to think of a scientific notion that has been more socially transformative in the last half-century than that of computation. Hell, we're swimming in an artifact of its impact right now...
I've worked with people who were computer people and people who were computer science people. The ones in the second group always seem to be the ones to first grasp the essence of the problem and to see the way to a lasting solution.
I think of them as analogous to mechanics versus physicists.
The discipline is the same, the subject environment is different.
One of the things I've noticed as a developer/engineer for the last 20 years is that I use the techniques of science all the time, only I'm not studying "nature" (be it the physics world, chemicals, biology, or people). I'm applying the disciplines and the scientific process to stuff that other people have done.
When I'm optimizing, for example, I can make some mathematical prediction on performance improvement based on algorithms itself, but if the algorithm depends on memory I have to worry about the paging algorithm of the OS (not my code); if the algorithm depends on file reads I have to worry about the size of the files and the disk IO access (not my code); if the algorithm depends on significant graphics I have to worry about the speed of the graphics card and the library calls available (not my code). Maybe I'm writing in Java and thus bounce into non-optimizations caused by the virtual machine layer.
So I can make a prediction, but to fully use the scientific method i need to then write the code and compare the results to the prediction to figure out which of the millions of lines of code and hardware firmware that I *didn't* write is causing my performance to fall short of that prediction, and accommodate that the next time.
Things that make this type of application of the scientific method different also include 1) the rate at which one can write an "experiment" (MUCH faster than any of the others), and 2) that cost-benefit trade off, the infamous 80-20 rule (20% of your code is 80% of your problem - don't optimize the wrong thing) which is a Law in the Arthur Clarke sense, but all of us have our anecdotal proof.
In addition, being in User Interfaces, I'm always carrying out mini-experiments effectively in sociology when trying to improve a screen (browser or desktop, doesn't matter), and that requires research in the technology AND research in human behaviour. It was easy when everybody on a computer was a "geek" (who didn't give a crap), but that's not the case anymore. Again, a balancing of trade-offs - a better technique vs. what are the users used to and expecting.
At a higher level, we also deal with sociological aspects as well. When writing anything that "improves the process" (i.e., more automation of trivial tasks), you inevitably hit two questions of resistance:
1) "how will this improve what i'm doing?"
It won't. You won't be doing the tedious crap you're doing, you'll be doing a lot more a lot faster.
they never "Get" that answer until its there in front of them.
2) "will this mean someone gets fired?"
That's a big scary one, because the likely answer is "yes". Automation and process control code tends to make some jobs redundant because of the increased productivity of the others, AND also can reveal who's doing the most/best work and thus help in weeding out the lesser employees.
Always defer this answer to the manager. They can be better at lying than we are.
And that's the final thing that makes CS like a science to me: you can't lie. Other code and other users depend on your code doing its job. Bumping up your resume or your claims as to your codes quality get picked out by the others REAL fast, just as a crappy science paper and false credentials gets weeded out in the peer review process of a journal.
Yeah, marketing can lie all they want, but that's between them and the customer. For you and your code, honesty matters.
Another thing about these "mini-experiments" in programming (be it debugging, optimization, or user interface testing) - one thing that makes it easy to write these experiments is the fact that your "control" case usually already exists: it's the code as its written now. It never goes away (unless your SCM process sucks) and is quickly re-run for comparison to your "experiment", the new code.
And a lesson learned from the scientific process as applied to this type of work is a critical one: minimize variables and isolate your differences. only change the least number of things you need to change and complete the comparison before moving on to other parts of the code. if you changed 10 things and only 3 were directly related to the optimization, well, your results may be nice and positive, but not really reliable as lessons learned for the next time.
Really interesting post! I'm looking forward to the rest of this series...
P.S. for the uninitiated, could you talk a little bit about what you do on a day to day basis?
Frances Grundy has some interesting articles on this question - which, interestingly enough, also has a gender aspect to it:
Where is the Science in Computer Science?
http://www.cs.keele.ac.uk/content/people/a.f.grundy/science.htm
Computer Engineering: Engineering What?
http://www.cs.keele.ac.uk/content/people/a.f.grundy/eng.htm
Wow, great comments everyone!
chezjake, that's a great question! I will add it to the series.
Tyler, thanks for stopping by! Your insights are spot on, particularly the pull between science vs. engineering. I'll probably quote your comments in subsequent posts, because a lot of the points you bring up are exactly what I'm thinking about.
6EQUJ5, you also raise a good point, and I think this is related to the question that chezjake brought up (although I think your point is a bit more analogous to computer science vs. information technology). I will make sure to address this as well in a future post.
Joe Shelby, thanks for raising the points and giving the examples of experimentation in CS. This is what immediately comes to my mind when thinking about what is science-y about CS. Of course some would say that this is also evidence that CS is more engineering-based (which I think you also bring up as well). That's what makes this question so interesting and so vexing! I'll be referencing some of your questions and examples in future posts, too.
ScienceMama, funny you should ask---I am planning on starting a new series about Demystifying Technology, and the first post is going to be a day in the life of a computer scientist! So yes, I will talk about what I do---look for that coming soon.
WiseWoman, thanks for the links! I will definitely check out those articles and probably incorporate them as well into future posts.
I think part of the challenge here is that there really isn't one answer. There are definitely computer scientists who do science, some who are engineers, and some who would fit in a math department. Sometimes different work by the same person fits in different categories. At various points the same project can be science or engineering.
I'm also in the interdisiplinary field of bioengineering which is much more often science rather than engineering, but these terms are fuzzy anyway.
My guess of a 3 sentence difference between science and engineering is:
Science is more than just hypothesis testing. It requires a hypothesis without a clear answer. If the answer is clear then you are a mathematician making design specs or an engineer building to design specs.
I think part of the computer science confusion is that very little of the undergraduate education in computer science is science. In a good education, there's a lot of underlying principles and discussions of useful algorithms, but the testing of unknowns and history of discovery is often left out. Only in the grad level and beyond do the science aspects become more clear.
I can't say too much for the Grundy articles so far. It seems "framing" (in the poor sense) is all to obviously noted when reading it. There are factual, historical claims that are well written and supported just fine.
Then there's crap like this: "As [programming techniques and languages] developed in sophistication men wanted to make sure that this newly emerging field was a male one."
It was unsupported (and unsupportable) blanket statements like that which gave feminism and feminist writing a VERY poor reputation throughout the '60s and '70s. One would think by the late 1990s such poor writing would have stopped.
In fact, the whole point of her exercise in the label identification of computing ("science", "engineering", whatever) is all really more focused on the perennial question: why are there so many more men than women in computing?.
But rather than address that question directly, since not being a sociologist it is out of her scope, she hits it indirectly by attacking labels. The label discussion is fine, a valid one. The sociological implications she throws in there are vapid and unsupported.
bsci, that's definitely why I started this series---my answer tends to change depending on the day. I totally agree with you re: lack of a lot of the 'science' in computer science at the undergrad level---the exception being some (very) upper-level classes and, of course, undergrad research.
Joe, I haven't had a chance to look at the articles yet, but a friend of mine who studies rhetoric likes to talk about some of the language associated with engineering/science/technology and how it can harm rather than help. It's an angle I never considered before, but certainly makes sense in a way.
I actually heard a story---wish I could remember the source!---that back in the halcyon days of CS (1980's) when the gender ratios were much better, there was a somewhat concerted effort to change the way that CS was taught, to actively *discourage* too many people from studying the subject. And of course this had a much bigger impact on the number of women who chose to study CS. (Has anyone else heard this story? What's the origin?)
Actually, I don't see the teaching methods having an impact on how many people study having seen the 1980s boom, the early 1990s wane, and then the late 1990s second boom.
In all cases, I can name a sociological factor completely outside the educational community and certainly outside of their control: the popularity of the PC(s) and the idea that one could actually get a job with them.
In the 60s and 70s, most students fresh outta high school had no idea what a computer was until they actually got there.
In the '80s, the boom of the wide variety of PCs, all with their own little BASICs, meant anybody could be a programmer (in the Ratatouille "Anyone Can Cook" sense). Most of us went into CS because we were already half-way decent programmers before we even got there. The old 6502 boxen (Atari, Apple ][, Commodore 64, TRS-80) made it easy.
Now, around 1989, the 6502 revolution was over, a victim of Moore's Law. IBM had "won" and the PC became the exclusive domain of the business world. PCs didn't have programming languages for "anybody to use", and even the basic BASIC it might have on it nobody bothered with 'cause the applications didn't leave as much room for itch-scratching (that urge that generates the best of the Hacker community). Nobody came in looking for CS degrees because the computing world had quite literally become boring (Apple's 1984 parody commercial come true).
Come 1995 and Netscape, with its images and tables for layouts and javascript and easy access to free web servers and Linux means anybody can run Unix with all of its non-PC features and WOW there's MONEY to be made in programming (a MAJOR factor) and WHAM, a brand new boom.
Come 2001 and the dot-com boom has busted and Microsoft has one the browser wars and enough itches have been scratched and you start to find a wane in the numbers again - computing has either turned into a business (as it always was, boring), or merely a social construct (the web as the great virtual world). Once again, there are enough applications of reasonable quality that the urge to right your own has waned again.
JMU had CS graduating classes in the 100-200 range in the mid 80s.
I graduated from JMU in 1993, one of only 24.
In 1998, they graduated 150 and have never been smaller since.
What changed? The public perception that there could be a job in CS, AND that the work could actually be interesting.
Why did it change? The ability to program from home. The ability to create the "Hacker" mindset before even leaving high school and looking for a direction.
No professor at JMU changed how they taught what they taught between 1984 and 1998 (and today). The numbers of CS students had nothing to do with anything they did. Everything about the booms and busts has been because of the entry of the computer into the home and what the children could do with it and did with it before they left high school.
As I look at it computer science is a form of math. The question of whether CS is a science then reduces to whether or not math is a science.
It should be noted that I'm talking strictly the undergrad perception.
As for CS undergrads who choose to stay in CS as a lifetime thing rather than hit the outside world as programmers or IT specialists, that I know little of except that for myself, 1) I was sick of school as a whole (never going back, ever ever ever), and 2) I'm a greedy craven little coward (Daffy Duck is a personal hero) who wants the money. Of course, I happen to like what I do as well, but there you go.