Is CS not real science? or just in its infancy?

[Titan]

This is borderline HT, but I want to keep this discuccion philosphical. It comes from a question I discussed with a friend.

I remember in my first chem class in HS, my teacher told me "now you all get to work in real science. All that other stuff you did like biology and earth science is not real science. Real science requires math."

Well, that's not a basis for my argument, but it is an interesting statement. I was thinking about how science relates to engineering the other day. It seems to me that math is an engineer's tool for creating something, while math is the corresponding verification method of the existence of science. It seems that existing math, usually calculus, provides an operating framework for the scientist to conduct research in chemistry, and physics, which leads to Mechanical, Electrical, Civil, and Chemical engineering (the classical ones). Computer engineering could be thought of as a sub-class of EE.

However, Software Engineering has it's roots in computer science, and as many of you know, the practice of SoftE is wrought with problems. Products break left and right, in heaps of massive errors, this is mainly due to improper testing. But, the only way to verify software is to test it, there is nothing else you can do, it's hard to measure, and tough to run it through a formula to see if things are working within designed tolerance. Why? Because the science works in the same way, there is no math that allows the CS researcher to verify his claim on his work, he can only test the code.

My suspicion is that CS (in its current state) is really more of a psuedoscience, much like psychology, where there is no formal mathematical methodology, but just a way of testing behavior. If we had something that was maybe psychological engineering, we might see similar problems with what we build.

Now, I know that you can use math in verifying some computational ideas. There is discreet math, and there are ways to write proofs. But it's simply not done, nor is it a main requirement of the scientist to do any such thing. Most CS people are hackers who write code, test it to see that it works, and are done. This translates into software engineers not doing any such thing for sure, for many reasons such as time, cost, and near impossibilty. You take a big piece of software, there is no way you can use math to verify that it is correct.

I know CS is a very different animal than normal science, and it is about how we go about solving a problem. It is kind of an abstract to math, not what to do, but how to do. Many kinds of mathematical approaches are attempting to define new math that applies to CS, but i think they have it backwards, maybe we should try to come up with CS that generalizes math.

But I am no big CS guy, I'm a software engineer, and I'm not trying to offer a solution, I'm just trying to pick a good spot to look at the problem.

Thoughts?

 

[Matthias99]

However, Software Engineering has it's roots in computer science, and as many of you know, the practice of SoftE is wrought with problems. Products break left and right, in heaps of massive errors, this is mainly due to improper testing. But, the only way to verify software is to test it, there is nothing else you can do, it's hard to measure, and tough to run it through a formula to see if things are working within designed tolerance. Why? Because the science works in the same way, there is no math that allows the CS researcher to verify his claim on his work, he can only test the code.

See also: Alan Turing, Turing Machines, and especially "the halting problem". Complete and correct (in the mathematical sense) software testing and verification is, in the most general case, theoretically impossible. Now, for any *realistic* system, it can usually be done to at least some extent, but it involves a lot more investment of time and effort up front. This tends to make it unpopular from a business perspective. In fact, "test as you build" is one of the cornerstones of the 'Extreme Programming' approach; they advocate using automated testing wrappers to ensure that complex systems don't break as new functionality is added.

Furthermore, this is not a problem with just CS, but with *any* complex system; observe (for example) the number of cars that have safety recalls because of some design issue. Even NASA is not immune to this sort of thing. Large, interrelated systems are just really, really hard to test fully.

Now, I know that you can use math in verifying some computational ideas. There is discreet math, and there are ways to write proofs. But it's simply not done, nor is it a main requirement of the scientist to do any such thing. Most CS people are hackers who write code, test it to see that it works, and are done. This translates into software engineers not doing any such thing for sure, for many reasons such as time, cost, and near impossibilty. You take a big piece of software, there is no way you can use math to verify that it is correct.

Ah yes, discreet math. Psst! 2+2 = 4!

Oh, you meant discrete math. I find that more useful, too. However, you're blurring the lines here between algorithm design (which is usually a very formal, mathemetical process and not necessarily related to a particular piece of software) and software engineering (which tends to be more of a hands-on 'building' process). There's a significant difference between proving the correctness of an abstract algorithm and proving the correctness of an implementation of that algorithm (in fact, the latter may be impossible).

 

[f95toli]

CS is most definitly a science, and it is closely related to math.
However, I guess a lot of what goes into CS courses is not what you would consider "pure science" but the same could be said about for example physics when it is taught to civil engineers.
If you are going to work in software engineering (or any other form of engineering) you need "applied" skills most of the time, and the courses taught at the universities are designed for that. Unless you are planning on getting a Ph.D you rarely encounter "real" science in in engineering.

 

[Titan]

Oh, you meant discrete math. I find that more useful, too. However, you're blurring the lines here between algorithm design (which is usually a very formal, mathemetical process and not necessarily related to a particular piece of software) and software engineering (which tends to be more of a hands-on 'building' process). There's a significant difference between proving the correctness of an abstract algorithm and proving the correctness of an implementation of that algorithm (in fact, the latter may be impossible).

sorry, pardon the spelling error. I agree with what you said, but I'd like to clarify that I'm not talking about algorithm design, I'm talking about the academic practice of computer science. Most CS students I know are taught how to proove algorithms, but the meat of what they do is actually software construction. I know some schools where CS students are called software engineers. Many of them become software engineers in industry without knowing about doing good work up front. I was only saying the science seems in it's infancy since research and production are so intertwined, like they were at once for all sciences.

 

[CTho9305]

Originally posted by: tkotitan2
Computer engineering could be thought of as a sub-class of EE.

I'd argue it's more than that, but that argument is separate from the rest of this discussion

However, Software Engineering has it's roots in computer science, and as many of you know, the practice of SoftE is wrought with problems. Products break left and right, in heaps of massive errors, this is mainly due to improper testing. But, the only way to verify software is to test it, there is nothing else you can do, it's hard to measure, and tough to run it through a formula to see if things are working within designed tolerance. Why?

Because programmers have to meet deadlines.

Because the science works in the same way, there is no math that allows the CS researcher to verify his claim on his work, he can only test the code.

Hardly. For one thing, languages like ML allow formal verification of programs. If you write something in ML, you can mathematically prove its correctness. Of couse, writing in ML is very difficult.

My suspicion is that CS (in its current state) is really more of a psuedoscience, much like psychology, where there is no formal mathematical methodology, but just a way of testing behavior. If we had something that was maybe psychological engineering, we might see similar problems with what we build.

As I said above, programs can be written in languages that allow formal verification of functionality... it is just very difficult. As a business, would you rather hire a comp sci major from a good school, pay him $70k/year, and get flawless software, or some kid with a communications degree from the local community college, get programs out 5 times as fast, pay him half as much, and deal with a few bugs?

Now, I know that you can use math in verifying some computational ideas. There is discreet math, and there are ways to write proofs. But it's simply not done, nor is it a main requirement of the scientist to do any such thing.

In academia it is. In algorithm design, it is. In the real world, it's not cost effective.

Most CS people are hackers who write code, test it to see that it works, and are done.

A real CS person would use thorough tests.

This translates into software engineers not doing any such thing for sure, for many reasons such as time, cost, and near impossibilty. You take a big piece of software, there is no way you can use math to verify that it is correct.

You said yourself, it's not done because it's expensive. But it is NOT impossible.

But I am no big CS guy, I'm a software engineer, and I'm not trying to offer a solution, I'm just trying to pick a good spot to look at the problem.

Thoughts?

Software engineers are fake CS guys .

edit: So, in summary... Computer Science is a verifiable science. Programming, as normally done, is not rigorously checked, because 1) you need to be good to be able to do it right, 2) it takes a long time to do it right, and 3) 1 and 2 mean it's very expensive.

 

[Mday]

CS is computer science. it is a science, by name. it deals with optimization and application of algorithms for the most part. while it is not a "natural science" (physics, biology, chemistry), it is an area of study. CS is NOT programming. programming is just the tool (means to an end) to represent the algorithms. just like math is not numbers or letters or operations. math is a science which uses numbers, letters and operations as the tools.

once you apply computer science, you get programming and computer engineering.

 

[gherald]

computer engineering does not come from CS... it comes from EE

When you apply CS, what you get is SOFTWARE, pure and simple.

 

[CTho9305]

Originally posted by: gherald
computer engineering does not come from CS... it comes from EE

When you apply CS, what you get is SOFTWARE, pure and simple.

No, when you apply CS, you get ALGORITHMS, pure and simple. Stuff like that is very important in processor design - e.g. how to multiply two large numbers quickly. The CS guy comes up with the algorithm, and the EE makes the circuit. Except usually CEs are taught enough CS to design the fast adder themselves, while EE guys are really low-level stuff.

I know a few EEs, and most fo them know NOTHING about how CPUs actually work, even though they can design circuits very well. No CS major I know can design circuits, and a lot don't know more than the basics about computer architecture.

 

[Matthias99]

I agree with what you said, but I'd like to clarify that I'm not talking about algorithm design, I'm talking about the academic practice of computer science. Most CS students I know are taught how to proove algorithms, but the meat of what they do is actually software construction.

A good CS program differentiates those skills. I had 'theory' courses (where we talked algorithm design and discrete math), in-depth 'hands-on' courses on particular software topics, and more general 'software engineering' courses (as well as some intro courses that taught basic programming skills).

I know a few EEs, and most fo them know NOTHING about how CPUs actually work, even though they can design circuits very well. No CS major I know can design circuits, and a lot don't know more than the basics about computer architecture.

<raises hand>You know one now. I only took two semesters of circuit design, though, because I wasn't nutty enough to be a Comp Engin major. I'd say about a third of the CS students at my school took at least one full circuit design course, and the class on computer architecture and low-level system design (which was required for all CS majors) included a considerable amount of circuit simulation work. The first half of that class was logic gate and circuit design (ending with 'building' a simulated -- and very simple -- RISC microprocessor from the gate/chip level), and the second half was MIPS assembly languge programming (ending with building the code generation logic for a very simple compiler). I had separate courses on 'software engineering' itself (studying the *process* of building software, while applying that information to work as part of a programming team), as well as more specialized classes on particular programming topics (operating systems, graphics, networking, etc.)

A CS major who couldn't build a simple circuit out of logic gates, or tell you the details of how a compiler/assembler works, or prove things (such as correctness, and bounds on execution time) about a new algorithm you presented them, is just a (hopefully) well-trained programmer. I wouldn't expect a CE major to necessarily know all that much about software, but they should definitely know *something* about it if they want to work with CPU design or the like. I would think it would be quite difficult to build a microprocessor if you didn't know anything about assembly language...

 

[gherald]

Originally posted by: CTho9305
No, when you apply CS, you get ALGORITHMS, pure and simple.

Yes you get alrgorithms, but not "purely and simply". While it is theoretically possible to sit down and derive algorithms without doing any type of programming, no one does this (or at least, very rarely). CS involves the whole package that is software.

Stuff like that is very important in processor design - e.g. how to multiply two large numbers quickly. The CS guy comes up with the algorithm, and the EE makes the circuit.

No, the CE guy does that. The CS dudes are too busy messing with their compilers.

Except usually CEs are taught enough CS to design the fast adder themselves

And most of the other 'adder' as well.

while EE guys are really low-level stuff.

Of course.

I know a few EEs, and most fo them know NOTHING about how CPUs actually work, even though they can design circuits very well.

That does not take away from the fact that CE is directly derived from EE.

No CS major I know can design circuits, and a lot don't know more than the basics about computer architecture.

Which is why their job is software.

 

[buleyb]

Originally posted by: Matthias99

I agree with what you said, but I'd like to clarify that I'm not talking about algorithm design, I'm talking about the academic practice of computer science. Most CS students I know are taught how to proove algorithms, but the meat of what they do is actually software construction.

A good CS program differentiates those skills. I had 'theory' courses (where we talked algorithm design and discrete math), in-depth 'hands-on' courses on particular software topics, and more general 'software engineering' courses (as well as some intro courses that taught basic programming skills).

I know a few EEs, and most fo them know NOTHING about how CPUs actually work, even though they can design circuits very well. No CS major I know can design circuits, and a lot don't know more than the basics about computer architecture.

<raises hand>You know one now. I only took two semesters of circuit design, though, because I wasn't nutty enough to be a Comp Engin major. I'd say about a third of the CS students at my school took at least one full circuit design course, and the class on computer architecture and low-level system design (which was required for all CS majors) included a considerable amount of circuit simulation work. The first half of that class was logic gate and circuit design (ending with 'building' a simulated -- and very simple -- RISC microprocessor from the gate/chip level), and the second half was MIPS assembly languge programming (ending with building the code generation logic for a very simple compiler). I had separate courses on 'software engineering' itself (studying the *process* of building software, while applying that information to work as part of a programming team), as well as more specialized classes on particular programming topics (operating systems, graphics, networking, etc.)

A CS major who couldn't build a simple circuit out of logic gates, or tell you the details of how a compiler/assembler works, or prove things (such as correctness, and bounds on execution time) about a new algorithm you presented them, is just a (hopefully) well-trained programmer. I wouldn't expect a CE major to necessarily know all that much about software, but they should definitely know *something* about it if they want to work with CPU design or the like. I would think it would be quite difficult to build a microprocessor if you didn't know anything about assembly language...

I'm in complete agreement. CS shouldn't be looked upon as coding. Software Engineering is supposed to be intelligent programming, with specific principles of CS being utilized. Programming can be trial and error, but for most solid business projects, there should be planning and design work done. Computer Scientists should have a knowledge well beyond programming, and a part of that should be the logical construction of hardware. CEs should be more concerned with the combination of logical design and physical construction, as it relates to computing electronics, a more narrow field than EE, but a highly specific one.

Like you said, a good program teaches more than programming, and exposes the field to all areas of
the field

 

[gherald]

Originally posted by: buleyb
I'm in complete agreement. CS shouldn't be looked upon as coding. Software Engineering is supposed to be intelligent programming, with specific principles of CS being utilized. Programming can be trial and error, but for most solid business projects, there should be planning and design work done. Computer Scientists should have a knowledge well beyond programming, and a part of that should be the logical construction of hardware. CEs should be more concerned with the combination of logical design and physical construction, as it relates to computing electronics, a more narrow field than EE, but a highly specific one.

Like you said, a good program teaches more than programming, and exposes the field to all areas of
the field

So in summary, you consider 'CS' to be 'coding + x'

But from your post it is unclear what exactly you take 'x' to be, in part because your ambiguity in introducing the term "Software Engineering".

Could you be more precise?

 

[CTho9305]

Originally posted by: Matthias99

I know a few EEs, and most fo them know NOTHING about how CPUs actually work, even though they can design circuits very well. No CS major I know can design circuits, and a lot don't know more than the basics about computer architecture.

A CS major who couldn't build a simple circuit out of logic gates, or tell you the details of how a compiler/assembler works, or prove things (such as correctness, and bounds on execution time) about a new algorithm you presented them, is just a (hopefully) well-trained programmer.

One of my friends is doing some very advanced data storage stuff... which requires absolutely zero knowledge of building circuits. He only needs to know the limits of what can be implemented (in his case, the moving parts of the drives are actaully more important than the speed of the circuit). The rest he knows very well (as all CS majors should). Not all parts of CS relate to logic gates, and you could have a brilliant CS person with only a minimal understanding of circuits.

I wouldn't expect a CE major to necessarily know all that much about software, but they should definitely know *something* about it if they want to work with CPU design or the like. I would think it would be quite difficult to build a microprocessor if you didn't know anything about assembly language...

Of course.

Originally posted by: gherald

Originally posted by: CTho9305
No, when you apply CS, you get ALGORITHMS, pure and simple.

Yes you get alrgorithms, but not "purely and simply". While it is theoretically possible to sit down and derive algorithms without doing any type of programming, no one does this (or at least, very rarely). CS involves the whole package that is software.

I was replying in the form of the original post "pure and simple"... obviously it's more than just that.

Stuff like that is very important in processor design - e.g. how to multiply two large numbers quickly. The CS guy comes up with the algorithm, and the EE makes the circuit.

No, the CE guy does that. The CS dudes are too busy messing with their compilers.

I would venture a guess that Booth wasn't a CE or EE. In fact, I think he was a actaully math guy.

I know a few EEs, and most fo them know NOTHING about how CPUs actually work, even though they can design circuits very well.

That does not take away from the fact that CE is directly derived from EE.

You consider CE a subset of EE? There is a lot more CS in CE than there is in EE. An EE designing a fancy radio doesn't need to know about virtual memory or assembly language. (Obviously that's an extreme case).

 

[gherald]

EE and CE are very closely related for obvious reasons.

CS and Math are also closely intertwined when it comes to dealing with algorithms.

The relationship between CE and CS can be ambiguous at times... they both give and take a lot from each other.

But the simplest way to look at their relationship is:

CE = the hardware, with some LL programming overlap to CS
CS = the software, with some LL programming overlap to CE

If a CS guy knows about logic gates, more power to him. Same for a CE who knows HL programming stuff. It's just not precisely in their job description.

 

[buleyb]

you wouldn't happen to be a EE would you?

 

[gherald]

Nah, first year student. Intended major is CE with a possible ~30 additional credits for CS double.

I have talked to a lot of career CS people (including two uncles) and a few CEs to make a decision between the two, and in the end decided since they are so similar and it's easy to do both I may as well give it a try.

Plus CS majors nowdays are such a fad that I simply do not want to risk getting caught up in that. There are about five people on my dorm floor intending CS, and most don't know sh!t about computing. Most of them are hoping to do 'game programming'

. Everyone wants to code games, but no one wants to pay for them.

 

[Matthias99]

Originally posted by: CTho9305

Originally posted by: Matthias99

I know a few EEs, and most fo them know NOTHING about how CPUs actually work, even though they can design circuits very well. No CS major I know can design circuits, and a lot don't know more than the basics about computer architecture.

A CS major who couldn't build a simple circuit out of logic gates, or tell you the details of how a compiler/assembler works, or prove things (such as correctness, and bounds on execution time) about a new algorithm you presented them, is just a (hopefully) well-trained programmer.

One of my friends is doing some very advanced data storage stuff... which requires absolutely zero knowledge of building circuits. He only needs to know the limits of what can be implemented (in his case, the moving parts of the drives are actaully more important than the speed of the circuit). The rest he knows very well (as all CS majors should). Not all parts of CS relate to logic gates, and you could have a brilliant CS person with only a minimal understanding of circuits.

You'll note the careful use of "or" (as opposed to "and") in the above statement. A 'CS' program that teaches nothing but "here's how to write code in C/C++/Java" would be doing a great disservice to its students. Obviously not everybody with a CS degree is going to be an expert in all those fields, but I would hope that anybody who spent four years studying computers picked up at least a passing knowledge of logic gates and how they fit together to make low-level hardware. However, in many cases it's not directly relevant; you can certainly be an *outstanding* programmer/software engineer without having a clue about any of the topics I mentioned above.

 

[andyman7]

im a computer engineering major right now
it is a major administered by BOTH the CS and EE departments and it can easily be looked at as getting two beefed up minors in CS and EE
at my school, most CPE majors pick a focus (CS or EE) and choose their courses accordingly
most end up taking almost every class that a CS or EE major takes (depending on their focus)

while most schools have departments called "electrical and computer engineering" its silly to think that computer engineering is a subset of or derived from either CS or EE
both are important for the computer engineer

of course, this is just how its taught at my school.....it could be different other places

 

[krazykilluh]

When I walked into my theory of computation class on the first day, the professor said something like "Without this branch of the field, I have a hard time calling CS a science." Is software engineering a science? Obviously not. Computer architecture? It seems more like engineering to me. But in CS theory a precise definition of "computation" is given and certain problems are proven to be impossible to solve, absolutely requiring a certain amount of computational resources even in the best case, etc using mathematical techniques -- this is a real science.

 

[Peter]

You're calling the architect a bricklayer. "But ... all he does is position bricks - the architect does it on the CAD screen and the bricklayer does it in reality." The difference, and the science, in architecture lies in the process of figuring out the theories of erecting a building that doesn't come back down and also serves its purpose.

 

[Mday]

Originally posted by: gherald
computer engineering does not come from CS... it comes from EE

When you apply CS, what you get is SOFTWARE, pure and simple.

CS techniques are used to optimize digital circuits. CpE is all about digital circuits. CpE is EE with CS applied to it.

 

[gsellis]

Originally posted by: tkotitan2
This is borderline HT, but I want to keep this discuccion philosphical. It comes from a question I discussed with a friend.

I remember in my first chem class in HS, my teacher told me "now you all get to work in real science. All that other stuff you did like biology and earth science is not real science. Real science requires math."


Thoughts?

Man, using that argument, Economics is real science. Of which, I would disagree. Economics is more art than science. Too many variables, too much to quantize.

As for natural sciences, they would also require math, but no one has figured out how to quantitatively describe them. A real science, we are just not smart enough to explain it?

The real answer is that a conclusion is being drawn on a false premise.

 

[KoolAidKid]

IMO math is a tool like any other (albeit a powerful one), and I don't see why the 'science' label should be contingent upon its use. I feel that a definition should be more tied to a rigorous and well-controlled method of study rather than the particular tools used to do the studying. Of course, science is almost impossible to define well. To me, the more basic (theoretical) the research is, the more I tend to associate it with 'science'. I see engineering as the process that moves the findings of scientists toward real-world application.

 

[Titan]

Thanks everyone for the intelligent comments. Many of you brought up the point that CS plays a role in EE and compE, which i hadn't considered. I want everyone to realize I'm not really comparing academia-to-academia, but rather academia-to-industry, the latter is what I mean by engineering. All engineering students are studying to go into industry, while most scientists are not. Right now CS students go into industry and software enginneering is a mess.

Historically, there has always been a confusing time when a new technology pervades our world and engineering for that science arises. When electricity first became a viable technology in the late 1800s, there were very few engineers and the scienctists had to become engineers. There were of course many problems in the early days because engineering process was still in its infancy, and part of the problem may have been that physicists coming out of college knowing about electricity were working as engineers.

So, my question is simple: is this CS/SoftE relationship still in such an infancy? Will we one day have procedures that make software bug-free and perfect? Or is something else at work that will make such a level of maturity unattainable?

As a footnote: I will probbaly make the judgement that yes CS is a real science, since so many other fields use that word. But, a good question is, is CS rooted in math, or are we just tacking the math onto CS as a form of "logic."

Originally posted by: gsellis

Originally posted by: tkotitan2
This is borderline HT, but I want to keep this discuccion philosphical. It comes from a question I discussed with a friend.

I remember in my first chem class in HS, my teacher told me "now you all get to work in real science. All that other stuff you did like biology and earth science is not real science. Real science requires math."


Thoughts?

Man, using that argument, Economics is real science. Of which, I would disagree. Economics is more art than science. Too many variables, too much to quantize.

As for natural sciences, they would also require math, but no one has figured out how to quantitatively describe them. A real science, we are just not smart enough to explain it?

The real answer is that a conclusion is being drawn on a false premise.

You sir, are engaging what is called selective hearing. If you actually read the whole post and paid attention to it, you would have realized that is not a premise of my argument, I even say that. I am observing the real world relationship between academic science and engineering and hypothesizing, I haven't drawn any conclusions. Every form of engineering has roots in a science. The are also forms of science which have no form of enginnering derived from them, such as biology, geology, nutrition and many others which operate primarily on emprical observation rather than being math-heavy. Many of these are science for science's sake, gathering knowledge that is not put to use in industry. All I am saying is there seems to be a major disconnect between software engineering industry and academic computer science, which is dangerous since many science students become engineers. There is always such a disconnect, but it seems bigger for the industry of software.

 

[xts3]

CS is a real science, IMHO its just poorly understood. That and not everyone in CS is doing real science.

As to the comments about software quality, I do not believe current development tools are advanced enough to design error free software. that and people can intentionally design things that are broken from the get go (i.e. there was an oversight somewhere).

Science is a VAGUE term you guys seem to use so lets define it shall we?

Merriam websters def -- Science:

2 a : a department of systematized knowledge as an object of study b : something (as a sport or technique) that may be studied or learned like systematized knowledge <have it down to a science>
3 a : knowledge or a system of knowledge covering general truths or the operation of general laws especially as obtained and tested through scientific method b : such knowledge or such a system of knowledge concerned with the physical world and its phenomena