I wonder how many people here consider themselves scientists versus engineers. I think computer science is in a pretty unique position because people in our field solve both scientific and engineering problems. Indeed, the heritage of our field comes from both mathematics/physics and companies that made things like typewriters. Building computational systems has always required solving problems of both types; I'm not sure this has been the case for a while in other engineering or science fields.
The main distinction that I've seen between EE (at least the part focused on computational things), CompE, and CompSci is what part of the stack you focus on; does this reflect others' experiences, particularly those in EE or CompE?
I'd like to make a point here that Computer Science is not really a science. This is not an insult - I'm a computer scientist myself. Computer science derives from mathematics, which also is not a science. My premise here is that for something to be a science, it needs to be guided by the scientific method. Science generally deals with empirical observations and the change in the observation when one single controlled factor is changed.
Mathematics on the other hand already works in an idealized world where everything is logically connected to the base premises, and so experimentation is not required because we can formally prove things, which is strictly better than experimentation.
I have a computer science degree, although I wouldn't refer to myself as a computer scientist. However, as a programmer there frequently are times when I do resort to a basic scientific approach, in terms of hypothesis, experimentation, analysis of results... Someone might say that programming is supposed to be axiomatic, but things are typically complex enough that even with basic understanding of the axioms, beyond a basic level there is some level of trial and error that goes along with it.
Programming more generally is about solving problems. That involves a certain degree of scientific knowledge, mathematical knowledge, and some engineering since we generally build things that people will use. There is also a certain amount of creativity, both in expression and in terms of the ways we find solutions to problems as well. In my view, it doesn't exactly mimic any of those disciplines, but can be a mixture of all, and in varying degrees depending on the person and task at hand.
I have an impression that today too many programmers use engineering 'trial and error' approach in preference to formal reasoning. While the laws of nature does not change, runtime environment of a program changes rather frequently with every update of OS and libraries which is why the prevalence of the 'trial and error' approach results in the overall poor quality of software.
Perhaps, but as I mentioned in my last comment, formal reasoning often breaks down when dealing with anything more than the simplest of systems. What kind of axioms can you reason from in software? The network is always slow: not always, memory is always abundant, not always, the disk is always slow, with virtual memory, not always, exponential time complexity is always bad... not always. And especially, factor in cost, which is one of the most important aspects, and that severely impacts even the ability to formally reason since the most correct version can also be the most expensive and time consuming to implement..
Anyways, I didn't mean to downplay formal reasoning, but just to indicate that it is not often practical to use those methods exclusively when building software.
It makes sense to reason from the specifications of the runtime environment. For example, the spec for memcpy says that it's behavior is undefined when memory areas overlap. Then it would not be correct to use it for overlapping memory areas even if it works in some particular implementation as trial and error may show.
Definitely agreed. On the other hand, the act of programming itself is not quite Computer Science either, it's rather a feature you get as a result of it. It's more like applied math in my opinion.
Dijkstra said: "Computer Science is about computers as much as astronomy is about telescopes."
An alternate viewpoint is that mathematicians discover truths and laws about the mathematical realm, just as physicists, chemists and others discover them about the physical realm.
Mathematicians do in fact do "experiments" before proving a theorem - it's just that those experiments are often thought experiments, in terms of asking "what does (or would) this mathematical object look like, or how would it behave?", and those experiments are not mentioned in the final formal write-up.
I agree that your definition of science is the proper one, but then it makes distinguishing between engineering and science very difficult, doesn't it? I would guess that the classical scientific method (observe, hypothesize, test, iterate) is actually used on an every day basis more often by engineers than most basic scientists.
That said, as a physicist quite far removed from any applications, I staunchly agree with the thesis of the article: "Although a good deal is already known about those things, it certainly would not hurt to know more, but what would really move things forward would be investments in engineering."
I think most people outside of a particular corner of academia don't realize how less compelling the case is for basic scientific research leading to applications than it was (say) 50 years ago.
I can't agree more. I think computer science is somewhat unique amongst fields that are typically called engineering. While mechanical and electrical engineers build things that are based off of scientific theories, computer scientists build things that are based off of mathematical theories.
I generally agree with you -- I avoided stating that CS is more similar to math than the physical sciences for the sake of conciseness, and to highlight the science vs. engineering aspect.
That said, I find CS has some elements of what we generally think of as science. We can make hypotheses about unknown (and sometimes even quasi-natural) phenomena, and then test those hypotheses with empirical evaluation. The networking and Internet measurement literature is a good example of this, and I'm sure there are others as well (any measurement study, really). I don't think that's really the case in math.
The way I see it, any time you are building a system, you're an engineer. Theoretical computer scientists aren't really building systems, they're uncovering the mathematical foundation for the work that we do, so they don't count as scientists.
In contrast, someone implementing algorithm, is by this definition, an engineer. A good algorithm necessarily needs you to get your hands dirty with the nitty-gritties of the system the algorithm is going exist in. So, these guys are engineers.
I also think the guys who are deciding our taxes, studying economic policies and government should all be considered as engineers because these folks area also building systems, with the caveat that these systems have human beings inside them.
Interestingly my degree was in Computer Science (from a respected British University), yet this was part of the Engineering faculty. That seems quite apt for the duality of Computing, which I agree definitely straddles across both.
I think most Computing studies cover both the engineering (eg. programming), and science (eg. algorithms, grammars etc.) sides.
there's always been a lot of debate about whether software engineering is part of computer science or a separate profession.
looking at it through my own personal lens ... PREfix and PREfast (the static analysis tools i architected) were primarily software engineering -- we published in the Journal of Empirical Software Engineering. others working in the same space took more of a computer science approach, developed far more precise models and made breakthroughs in SAT and BDD. over time the two streams merged, which is a big win all around.
on the other hand, some of my other work was very CS-y -- looking at formalizing security algebras, for example, and applying standpoint epistemology to graph theory. so in the end i consider myself both a computer scientist and a software engineer.
In the US, you can call yourself an engineer whenever you feel like it, and you can put it on your resume and tell your employers that you're an engineer.
Here in Canada, it's illegal to call yourself an engineer without having a license.
And it's understandable, since accredited university engineering programs are rigorous. All engineers need to study chemistry, physics, math, and you have to go through "how to be an engineer" programs that teaches you ethics, engineering tools, and safety regulations that need to be followed. The programs are not easy, and you end up having spent 4-5 years of your life mostly studying. My friends in science programs are off playing around or partying all the time, but most of the people in my engineering program are studying, with the occasional day off where they go drinking.
I'm in Computer Engineering, and when I compare my schedule to my friends in Computer Science, it's a complete joke. I have 30 hours of lectures and labs a week, while the computer science people only have 15-20. My roommate in second year computer science just games all the time. At 2AM and I'm trying to sleep, and I can still hear him playing with my other roommate, yelling across the hall.
You can also double major computer science with business. My friend is doing that right now. You can't double major engineering with anything, because there's not enough time in a day to fit in that many courses.
Most people are under the impression that the difference between computer science and computer engineering is that one is theoretical, and the other is more practical. (which is what my guidance counselor told me) But when you actually enter the program, you realize computer engineering is far more than just about computers.
The running joke in Canada is that if you graduate computer engineering, you can go build a bridge. (legally, because you have an engineering stamp!)
Yes, computer science solves scientific and engineering problems. But do you really call a toddler an engineer when he builds lego stairs to reach the cookie jar on the shelf?
If so, I hope you're the only person on the bridge he builds.
True but here in the US "engineer" is not the term that matters. "Professional Engineer" is the term given to licensed and accredited engineers - generally identified by the initials "p.e." after their name, and you usually include some indication of the state you are licensed in.
Since graduating with an engineering degree is not enough to become a "Professional Engineer" in the US, you can actually argue it makes some sense to differentiate the terms - being licensed as a PE requires 6 years of professional engineering experience before you can even take the exam. So simply listing a job title of "engineer" might help demonstrate relevant engineering experience but means nothing with respect to your actual license.
If you can't double major in engineering and something else, you're either lazy or not very smart. Especially at a Canadian university... I mean, come on we're not talking MIT here.
My computer science education has been a schizoid mixture of classes geared to the practical, which I think of as "engineering" classes, and classes geared to the theoretical, which I think of as "computer science" classes. The latter are not about a science though, they are about a branch of mathematics.
Computer programming used to be applied maths. You followed the correct lemmas in the language and if you didn't make any errors you had a correct program.
Now there are so many layers of indirection between you and the world (huge complex APIS, graphics drivers, optimizing compilers, hyperthreading, cache, etc) that the actual behaviour of a program - especially in high performance, real time world - is no longer possible to calculate from the published specs.
It becomes experimental science, you adjust various parameters and measure the result. Certainly to get performance but sometimes just to get APIs to work together.
It becomes experimental science, you adjust various parameters and measure the result. Certainly to get performance but sometimes just to get APIs to work together.
This confuses the issue. The relevant question is --- as a programmer, would you consider yourself a "scientist" or an "engineer"?
In that context, we would not want to conflate the two, for example by trying to define why engineering ("adjust various parameters ... to get APIs to work together") is in fact science ("it becomes experimental science").
During the process of engineering, we of course employ the scientific method to accomplish our goals. But we would not want to consider engineering a purely scientific endeavor, in the way that, say, theoretical physics is a purely scientific endeavor.
Some universities call their program "computer and information sciences," which I think captures the notion that there's a distinction between the technical and theoretical training. What I've done since leaving school hardly qualifies me as a scientist, but I certainly draw on the principles.
Comments
I wonder how many people here consider themselves scientists versus engineers. I think computer science is in a pretty unique position because people in our field solve both scientific and engineering problems. Indeed, the heritage of our field comes from both mathematics/physics and companies that made things like typewriters. Building computational systems has always required solving problems of both types; I'm not sure this has been the case for a while in other engineering or science fields.
The main distinction that I've seen between EE (at least the part focused on computational things), CompE, and CompSci is what part of the stack you focus on; does this reflect others' experiences, particularly those in EE or CompE?
I'd like to make a point here that Computer Science is not really a science. This is not an insult - I'm a computer scientist myself. Computer science derives from mathematics, which also is not a science. My premise here is that for something to be a science, it needs to be guided by the scientific method. Science generally deals with empirical observations and the change in the observation when one single controlled factor is changed.
Mathematics on the other hand already works in an idealized world where everything is logically connected to the base premises, and so experimentation is not required because we can formally prove things, which is strictly better than experimentation.
I have a computer science degree, although I wouldn't refer to myself as a computer scientist. However, as a programmer there frequently are times when I do resort to a basic scientific approach, in terms of hypothesis, experimentation, analysis of results... Someone might say that programming is supposed to be axiomatic, but things are typically complex enough that even with basic understanding of the axioms, beyond a basic level there is some level of trial and error that goes along with it.
Programming more generally is about solving problems. That involves a certain degree of scientific knowledge, mathematical knowledge, and some engineering since we generally build things that people will use. There is also a certain amount of creativity, both in expression and in terms of the ways we find solutions to problems as well. In my view, it doesn't exactly mimic any of those disciplines, but can be a mixture of all, and in varying degrees depending on the person and task at hand.
I have an impression that today too many programmers use engineering 'trial and error' approach in preference to formal reasoning. While the laws of nature does not change, runtime environment of a program changes rather frequently with every update of OS and libraries which is why the prevalence of the 'trial and error' approach results in the overall poor quality of software.
Perhaps, but as I mentioned in my last comment, formal reasoning often breaks down when dealing with anything more than the simplest of systems. What kind of axioms can you reason from in software? The network is always slow: not always, memory is always abundant, not always, the disk is always slow, with virtual memory, not always, exponential time complexity is always bad... not always. And especially, factor in cost, which is one of the most important aspects, and that severely impacts even the ability to formally reason since the most correct version can also be the most expensive and time consuming to implement..
Anyways, I didn't mean to downplay formal reasoning, but just to indicate that it is not often practical to use those methods exclusively when building software.
It makes sense to reason from the specifications of the runtime environment. For example, the spec for memcpy says that it's behavior is undefined when memory areas overlap. Then it would not be correct to use it for overlapping memory areas even if it works in some particular implementation as trial and error may show.
Definitely agreed. On the other hand, the act of programming itself is not quite Computer Science either, it's rather a feature you get as a result of it. It's more like applied math in my opinion.
Dijkstra said: "Computer Science is about computers as much as astronomy is about telescopes."
An alternate viewpoint is that mathematicians discover truths and laws about the mathematical realm, just as physicists, chemists and others discover them about the physical realm.
Mathematicians do in fact do "experiments" before proving a theorem - it's just that those experiments are often thought experiments, in terms of asking "what does (or would) this mathematical object look like, or how would it behave?", and those experiments are not mentioned in the final formal write-up.
Haskell Curry made this argument in his "Outlines of a Formalist Philosophy of Mathematics": http://www.amazon.com/Outlines-Formalist-Philosophy-Mathemat...
His idea is that mathematics is the empirical study of the implications of systems of rules.
I agree that your definition of science is the proper one, but then it makes distinguishing between engineering and science very difficult, doesn't it? I would guess that the classical scientific method (observe, hypothesize, test, iterate) is actually used on an every day basis more often by engineers than most basic scientists.
That said, as a physicist quite far removed from any applications, I staunchly agree with the thesis of the article: "Although a good deal is already known about those things, it certainly would not hurt to know more, but what would really move things forward would be investments in engineering."
I think most people outside of a particular corner of academia don't realize how less compelling the case is for basic scientific research leading to applications than it was (say) 50 years ago.
I can't agree more. I think computer science is somewhat unique amongst fields that are typically called engineering. While mechanical and electrical engineers build things that are based off of scientific theories, computer scientists build things that are based off of mathematical theories.
I generally agree with you -- I avoided stating that CS is more similar to math than the physical sciences for the sake of conciseness, and to highlight the science vs. engineering aspect.
That said, I find CS has some elements of what we generally think of as science. We can make hypotheses about unknown (and sometimes even quasi-natural) phenomena, and then test those hypotheses with empirical evaluation. The networking and Internet measurement literature is a good example of this, and I'm sure there are others as well (any measurement study, really). I don't think that's really the case in math.
The way I see it, any time you are building a system, you're an engineer. Theoretical computer scientists aren't really building systems, they're uncovering the mathematical foundation for the work that we do, so they don't count as scientists.
In contrast, someone implementing algorithm, is by this definition, an engineer. A good algorithm necessarily needs you to get your hands dirty with the nitty-gritties of the system the algorithm is going exist in. So, these guys are engineers.
I also think the guys who are deciding our taxes, studying economic policies and government should all be considered as engineers because these folks area also building systems, with the caveat that these systems have human beings inside them.
In some countries (and increasingly in the US), applied econ/finance/policy is considered a form of engineering - quite true.
Interestingly my degree was in Computer Science (from a respected British University), yet this was part of the Engineering faculty. That seems quite apt for the duality of Computing, which I agree definitely straddles across both.
I think most Computing studies cover both the engineering (eg. programming), and science (eg. algorithms, grammars etc.) sides.
there's always been a lot of debate about whether software engineering is part of computer science or a separate profession.
looking at it through my own personal lens ... PREfix and PREfast (the static analysis tools i architected) were primarily software engineering -- we published in the Journal of Empirical Software Engineering. others working in the same space took more of a computer science approach, developed far more precise models and made breakthroughs in SAT and BDD. over time the two streams merged, which is a big win all around.
on the other hand, some of my other work was very CS-y -- looking at formalizing security algebras, for example, and applying standpoint epistemology to graph theory. so in the end i consider myself both a computer scientist and a software engineer.
In the US, you can call yourself an engineer whenever you feel like it, and you can put it on your resume and tell your employers that you're an engineer.
Here in Canada, it's illegal to call yourself an engineer without having a license. And it's understandable, since accredited university engineering programs are rigorous. All engineers need to study chemistry, physics, math, and you have to go through "how to be an engineer" programs that teaches you ethics, engineering tools, and safety regulations that need to be followed. The programs are not easy, and you end up having spent 4-5 years of your life mostly studying. My friends in science programs are off playing around or partying all the time, but most of the people in my engineering program are studying, with the occasional day off where they go drinking.
I'm in Computer Engineering, and when I compare my schedule to my friends in Computer Science, it's a complete joke. I have 30 hours of lectures and labs a week, while the computer science people only have 15-20. My roommate in second year computer science just games all the time. At 2AM and I'm trying to sleep, and I can still hear him playing with my other roommate, yelling across the hall.
You can also double major computer science with business. My friend is doing that right now. You can't double major engineering with anything, because there's not enough time in a day to fit in that many courses.
Most people are under the impression that the difference between computer science and computer engineering is that one is theoretical, and the other is more practical. (which is what my guidance counselor told me) But when you actually enter the program, you realize computer engineering is far more than just about computers. The running joke in Canada is that if you graduate computer engineering, you can go build a bridge. (legally, because you have an engineering stamp!)
Yes, computer science solves scientific and engineering problems. But do you really call a toddler an engineer when he builds lego stairs to reach the cookie jar on the shelf?
If so, I hope you're the only person on the bridge he builds.
True but here in the US "engineer" is not the term that matters. "Professional Engineer" is the term given to licensed and accredited engineers - generally identified by the initials "p.e." after their name, and you usually include some indication of the state you are licensed in.
Since graduating with an engineering degree is not enough to become a "Professional Engineer" in the US, you can actually argue it makes some sense to differentiate the terms - being licensed as a PE requires 6 years of professional engineering experience before you can even take the exam. So simply listing a job title of "engineer" might help demonstrate relevant engineering experience but means nothing with respect to your actual license.
If you can't double major in engineering and something else, you're either lazy or not very smart. Especially at a Canadian university... I mean, come on we're not talking MIT here.
How much karma do I need before I can downvote people?
My computer science education has been a schizoid mixture of classes geared to the practical, which I think of as "engineering" classes, and classes geared to the theoretical, which I think of as "computer science" classes. The latter are not about a science though, they are about a branch of mathematics.
I think programming is becoming a science.
Computer programming used to be applied maths. You followed the correct lemmas in the language and if you didn't make any errors you had a correct program.
Now there are so many layers of indirection between you and the world (huge complex APIS, graphics drivers, optimizing compilers, hyperthreading, cache, etc) that the actual behaviour of a program - especially in high performance, real time world - is no longer possible to calculate from the published specs.
It becomes experimental science, you adjust various parameters and measure the result. Certainly to get performance but sometimes just to get APIs to work together.
It becomes experimental science, you adjust various parameters and measure the result. Certainly to get performance but sometimes just to get APIs to work together.
This confuses the issue. The relevant question is --- as a programmer, would you consider yourself a "scientist" or an "engineer"?
In that context, we would not want to conflate the two, for example by trying to define why engineering ("adjust various parameters ... to get APIs to work together") is in fact science ("it becomes experimental science").
During the process of engineering, we of course employ the scientific method to accomplish our goals. But we would not want to consider engineering a purely scientific endeavor, in the way that, say, theoretical physics is a purely scientific endeavor.
Diligently following the prescribed rules and making careful measurements and calculations = Engineering.
Deciding how to measure something so you can determine what it's doing without knowing the internal rules = experimental science.
Some universities call their program "computer and information sciences," which I think captures the notion that there's a distinction between the technical and theoretical training. What I've done since leaving school hardly qualifies me as a scientist, but I certainly draw on the principles.
http://news.ycombinator.com/item?id=1207721 < Why writing software is not like engineering.