Hacker News Reader

Comment by makmanalp | Hacker News Reader

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.

View on HN

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.

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."

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.

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.

Reply on news.ycombinator.com