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