Well, not all of it; but a good part of it is.

A significant subset of ComputerScience is essentially mathematics, which is as hard of a science you can get. The following topics in ComputerScience fall into that category:

* TheoryOfComputation, including:
** Algorithm and complexity analysis
** Formal languages, grammars, and ComputationalModels
** Various calculi modelling computational processes (LambdaCalculus, ProcessCalculi)
* Quite a bit of the RelationalModel (though not all of it)
* TheoremProving, FirstOrderLogic, etc.
* Much of TypeTheory

Others are dependent on physical devices with complex EmergentBehavior (computer systems and their constituent parts) and thus don't admit axiomatic proof; but are still "hard" in that repeatable controlled experiments can be conducted to generate solid empirical evidence.

* Performance analysis of computer systems, including CPUs, memory systems, I/O, networking, you name it.
* Much of OperatingSystem theory

However, many parts of what are known as ComputerScience (or SoftwareEngineering - unlike other disciplines, there is no bright line between the two) are dependent on economics or cognitive factors - humans and human behavior (whether programmers or users) are part of the material which is under study. This includes:

* ProgrammingLanguage theory, excluding the "math" parts like parsing. Much of which focuses on how easily the language is programmed by humans.
* UserInterface theory.
* Much of computer security analysis (again, there is a "hard" core to this subdiscipline, but social engineering is a fundamental issue here)

And things which are clearly "engineering" rather than "science" aren't even being considered, such as:
* Project scheduling and budgeting
* Tasks involving ''design'' rather than analysis (analysis should always be a key part of design, unless all the underlying problems are solved; but analysis - the science - can exist without design).

Given that, ComputerScience has - as a whole - more in common with many of the social sciences than it does with the "hard" sciences (chemistry, physics). Many of the social sciences do employ or incorporate "hard" subsets - all employ statistics (or should, if they are to be considered "science") and other branches of mathematics, cognitive sciences and medicine invariably have to consider biology and biochemistry; and even the "middle" sciences like biology (which deal with complex EmergentBehavior but not with human factors) are firmly grounded in chemistry and physics. However, the "hard" sciences do not have dependencies on soft sciences; the results of physics research do not depend on psychology or economics (and any results that did would be suspect).

Given that, ought ComputerScience be classified as a soft science? Or perhaps it should be cleaved into a hard subset and a soft subset, and the two recognized as different disciplines?
----

Alternate perspective:

* ComputingScience is a '''formal science'''. Just like mathematics, there's no need for empirical evidence. ComputingScience operates with self-consistent '''formalisms'''. Just like mathematicians do not conduct experiments to verify the validity of 2+2=4, so computing scientists do not need to conduct experiments to test their prediction that BubleSort is O(n^2). It's sufficient that they prove that. The most formal scientists do sometimes is they construct a proof of soundness, i.e. they prove that the formalism they devise is non-contradictory. Of course, as TopMind will be the first to complain some formalisms appear useless (i.e. with no practical value). There's a long and sometimes heated discussion with regards to what is the extent to which formal scientists (mathematicians and computing scientists especially) should ensure that they work on problem of practical relevance, but that's a subject on its own. The tradition has been that formal scientists can choose to work on whatever formal systems they do please, because practical results may appear decades later and many other consideration, but that's just the tradition. 

* SoftwareEngineering is an '''engineering discipline'''. Unlike computing scientists, software engineers practice an engineering discipline. Therefore they are '''bound''' to conduct empirical experiments (including but not limited to usability tests, unit tests, psychological exploration, measurements about how programmers are confortable/productive with various programming paradigms, languages, tools, etc) for validating their approaches. However some such experiments are prohibitively expensive, and SoftwareEngineering is still in the incipient phase as a discipline.

So rather than muddle the waters about "soft" vs "hard" science, it is much easier and arguably more beneficial to distinguish SoftwareEngineering as an '''engineering discipline''' and ComputingScience as a ''''formal science'''. A lot of inappropriate analogies with physics, chemistry, fashion design, architecture, etc., will thus disappear. -- CostinCozianu

''I agree with what you've said, but it leaves certain things undefined. For instance - is computer security ComputerScience? It's definitely not formal.'' -- LayneThomas

* Parts of the problems with computer security are definitely amenable to formal treatment (cryptographic algorithms and protocols, formal proof of security, even TypeTheory has been applied "in theory", etc). And without the decisive help of formal ComputingScience we wouldn't be far in terms of security. Other practical aspects of computer security definitely belong to engineering a good solution. With the best of algorithms, engineers can trivially create a crappy and insecure solutions. I think the problems in computer security divide quite easily along the axis science <-> engineering. Maybe you have something more specific in mind?

''I do tend to agree, Costin (as the originator of the page), however: I think there needs to be a 3rd leg on this particular stool. Let's examine the discipline of civil engineering.''

''Civil engineering is the discipline of cost-effectively designing and analyzing large-scale, mostly-stationary projects such as buildings, bridges, roads, railways, tunnels, etc. Someone could probably write a better definition of Civil Engineering, but that's beside the point. Many consider civil engineering the canonical engineering discipline - it's by far the oldest.''

''Civil engineering is '''only''' considered with the application of known scientific principles to practical problems; civil engineers aren't generally engaged in pure research. While there is considerable overlap (and engineers must be aware of these other disciplines), there is a clean segregation between the engineering discipline and other aspects of the building trade (the actual implementation/construction of a project, the aesthetic/functional portion of design that we call "architecture"), as well as the underlying scientific disciplines (physics, mechanics, soil chemistry/mechanics, materials science, hydraulics, mathematics). Civil engineers don't generally act as crew foremen, nor do the perform pure research on new types of steel - that's handled by other folks. Civil engineers do one thing and do it well.''

''In SoftwareEngineering, including the definition you propose above, the "engineering" portion of the task - cost-effectively designing software systems which are functional, useful, and safe - is comingled with pure research. This, I believe, is one sign (or perhaps a cause, I'm not sure) of the immaturity of SoftwareEngineering as an engineering discipline. Too many people who claim to practice "software engineering" are in fact engaging in research (albeit poorly) and using the results of their "research" directly in their designs, with little or no scientific scrutiny. And I'm not just talking about cowboy hackers and ThreeStarProgrammers who write CrudScreen''''''s; this occurs on major software products sponsored by major corporations who can certainly afford to do it right. Were a CivilEngineer to conduct ad-hoc experiments on a new variety of steel (created in his backyard forge) and then use it as part of a bridge he was designing, he'd be shot. (Or at least subject to claims of professional malpractice.) But programmers invent new techniques, including ones not expressible in terms of existing techniques, and subsequently deploy them all the time. And we often think that it's cool when this occurs. (Sometimes it is, but not when you're designing switches for the phone company).''

''Thus, I would propose a third item - "software science", for lack of a better term, which encompasses those problems of pure research (UI design, language design, OS theory, computer architecture, etc.) which are empirical but not mathematical in nature. It would sit alongside computational science as a branch of the computer '''sciences'''. The term SoftwareEngineering would then only be used for what "engineering" traditionally means - the application of known scientific principles to practical problems. This doesn't mean that applications programmers couldn't invent something new, necessarily - you don't need to hire a civil engineer to build a toolshed - but it does constrain what could be considered "software engineering".''

''-- ScottJohnson''

I agree that there's a great deal of fuzzy, blurry, spongy area in between the formal science and the engineering discipline. Maybe I refuse to acknowledge it as such because I feel a bit guilty about it.

From where I stand, this may be as well, because scientists are working hard on the wrong formalisms. Just witness how many formal methods languages, they invented, all but a handful of exceptions requiring advance knowledge of LaTex for type-setting strange symbols. It's almost like they bet for failure sometimes. Never mind the particulars about latex and formal methods, but there's a huge gap between the majority of theory and what can be realistically tried and validated in engineering practice.

On the other hand it goes the other way around as well, with engineers preferring to ignore a large body of good scientific knowledge that is immediately applicable to practical problems, for the purpose of reinventing the wheels. 

So is this gray area there because it just needs to be something there? Or is it there just by accident because we cannot do a better, smoother transfer of knowledge and feedback between the engineering discipline and the science?
----

I agree that computer science as a whole is about as soft as marshmallows, or psychology, take your pick.

I disagree that there is anything hard about Operating Systems theory. That's assuming there is such a thing as OS theory beyond the OperatingSystemsDesignPrinciples.

''Much of the low-level details of OS design - things like how to do caching/paging, scheduling, synchronization - in short, all the muck covered in an undergraduate OS course - is fairly hard. Once can measure and observe the performance of different scheduling algorithms; granted there are numerous dependencies on the configuration of the system in question. The matters you concern yourself with are "soft" in nature - InteractionDesign and other specialties are human-centric. It's very difficult to empirically determine that one UI paradigm is "superior" to another - too many confounding factors.''

''<RANT>Thus you get luddites clutching fast to their CLIs and punchcards, and fellows like TedNelson and other self-proclaimed geniuses attracting fawning cults of personality about them and their latest gimmick - and both camps hurling invective and spite at the status quo, as well as the poor scientists who actually try to advance the state of the art by conducting real, painstaking research.</RANT>''

On the other hand, I disagree that computer security is soft. It's by far the hardest of all of computer science's many subfields. -- RichardKulisz

''Are you using the word hard to mean "difficult" or to mean "rigorous/based on fact"? - Because breaking into systems is most definitely an abstract affair that can involve anything and everything - and computer security tries to prevent that.''

Cryptography and capabilities theory are very rigorous. I use the term 'computer insecurity' to differentiate the BS from the desirable engineered traits. Note that computer security as I use the term admits to a reasonably complete and coherent theory. It has a well-defined goal and well-defined limits entirely independent of technology. In contrast, the irrelevant shite they teach in an undergrads course on OSes is just a hodge podge of rules of thumb and other such, all of them highly dependent on the state of the art. (Capabilities are a good idea even in a calculator, paging isn't.) So I wouldn't call the stuff they teach a ''theory''.

''OTOH, if calculators had hard drives and were managing datasets in the terabytes and larger, paging might become useful in calculators too. You're not suggesting that paging is a bad thing in a server, are you? Theory or not, paging systems can be measured and analyzed reasonably well - even if they aren't as neat and clean as the mathematical parts of ComputerScience.''

''Certainly there is a fundamental part of security - crypto and capabilities - which are applied maths. One can, starting with a set of axioms on capabilities, prove lots of things. Of course, practical security systems have to deal with human elements and human issues like TransitiveTrust - while there isn't any foolproof solution, you can't sweep it under the rug, either. And here security gets soft.''

TransitiveTrust is one of those things that provably ''cannot'' be dealt with by any security system. Any that tries only guarantees itself insecure by promising things it can't ever deliver.

I'm well-aware that much more is needed than raw capabilities. I'm the one advocating that people should BuildSecurityAbstractionsIntoCapabilities. But even counting the higher level security abstractions, and I always did count them in, the whole admits to more coherence than anything in the OS field. -- RK

----
EditMe: Merge with DisciplineEnvy

I'm not sure a merge with DisciplineEnvy is entirely appropriate - that page is a bit more general - but the topic is germane to this page. One of the fundamental problems I see ''in'' the realm of ComputerScience is this:

* Many practitioners ''do'' have DisciplineEnvy, and like to see CS as a HardScience.
* Certain disciplines within ComputerScience and SoftwareEngineering, as noted above, are soft in nature.
* '''Therefore''', these practitioners, rather than accepting these disciplines as legitimate fields of study within ComputerScience, instead reject them out-of-hand.

At my place of employment, we employ a team of HumanFactors experts to assist with UserInterface design and other such tasks. Most of these folks work for a central support organizations, rather than product lines. Many if not most of the PL engineering staff regard the HumanFactors experts with the same contempt that marketing is held in; in fact the two are often equated. The HumanFactors experts do hold the title of "engineer" (as a company job description) and may hold degrees which say "engineering" on them; however the self-proclaimed RealEngineer''''''s at my employer roundly scoff at this. Why? Because human factors engineering, being a soft science, isn't seen by many as a legitimate science at all. Someone who studies HFE might as well be studying French Literature or journalism or art history, in the minds of these folk.

There are other factors at play as well, such as a lack of PL-specific DomainKnowledge among the HumanFactors staff. But I strongly suspect my workplace is ''not'' unique in this regard. Many programmers seem to consider the research conducted in such disciplines to be PseudoScience at best, utter claptrap at worst - and the folks who ''do'' the research are considered second-raters.

Which is unfortunate. Many of the important problems of ComputerScience, especially when it comes to enhancing user experience and productivity, ''are'' problems of the "soft" sort. Greater rigor in the development of solutions would be extremely beneficial. Unfortunately, the folks who attempt to provide such rigor are frequently ignored, and instead "advancement" comes from whoever has the best marketing department and can sell the most seats, or whichever smooth-talking snake oil salesman can pen the most withering and entertaining rants about how everything about computers today sucks.

''It's often a case of the SovietShoeFactoryPrinciple. The easiest factors to measure may not be the most important or a complete picture. WetWare issues are important, but very difficult to apply rigor to.''

----

I would divide the discipline into three categories:

* Theoretical: studying and presenting internally-consistent models (maths). Being internally-consistent does not by itself guarantee that something is useful in the real world. At the most it is one of many prerequisites for being useful. Sometimes to be on the cutting edge you have to sacrifice internal consistency, similar to how early programming languages often had messy syntax and contradictory notions.

* Empirical: This is the process of doing experiments and collecting information about the usefulness or productivity of something. Such analysis is mostly about measuring the outcomes and is not concerned with internal-consistency and related theoretical purities. As somebody pointed out, such research in software development is expensive and difficult to repeat for verification. However, performance analysis (on machines) can and does rely heavily on this.

* Psychological (WetWare): Because humans must currently do much of the work, how well they relate to a technology and how well they can mentally map it to the domain subject are important factors. Unfortunately, psychology is a "soft science", which means that software management will also be a soft science by depending on psychology.

----
CategorySubjectivityAndRelativism