Chad said:
One of my friends who attends Harvard took Math 55. He mentioned that
a lot of it was being able to prove major theorems with only the aid
of the definitions. This got me to thinking. I've had a lot of people
help with me a programming problem by only providing defintions.
Is the thought process to proving some major theorems in math with
only the aid of the defintions similar to implementing some kind of
data structures when given only the definitions of a data structure?
Sometimes it may be overlooked but programming is inherently and
fundamentally a mathematical endeavour, which basically involves nothing
else than a set of operators being applied to a set of fields in a specific
order in order to reach an intended outcome. Following this interpretation,
any API is nothing more than a set of definitions of a mix of operators and
sets which a programmer may apply to his sets of data. With this in mind,
the answer to your question would be a clear yes, mathematical reasoning is
as vital to a mathematician as it is to a programmer. It is because
mathematics and programming are the same thing.
But then the real world sets in.
The thing is, mathematicians spend their time and energy studying the
implications of some set of definitions but they also invest a lot of
themselves trying to prove that the stuff they come up with is correct.
This mindset is lost in software development, whose approach to the
mathematical problem of developing a program often ends with providing code
which only works as expected in very limited circumstances which no one
knows or cares to know. Even those who actually care for this sort of stuff
and actually know their onions shy away from this goal, a fact which may be
represented by Knuth's quote "Beware of bugs in the above code; I have only
proved it correct, not tried it."
Meanwhile, the programming world occupies itself hacking together sets of
instructions which no one actually cares they are proven to be correct, or
even if they are valid in the conceivable scenarios which they are designed
to operate. That is, when compared to how a mathematician may tackle a
problem, programmers don't actually know what they are doing and instead
embrace the fact that the stuff they create does break and that they can't
do anything to prevent it. The disregard for this mathematical correctness
has reached a level that some programming errors committed by programmers
are so widespread and so frequent that, instead of trying to make sure that
the programmer is sufficiently competent to avoid them, they are simply
embraced as a natural occurrence and technologies have been developed to be
able to sweep those programming errors under the proverbial rug, which is
the case of technologies such as garbage collection and sandboxes.
And the thing is, this isn't necessarily bad. Of course, it would be better
if every piece of softwar ever written would have been developed with enough
care to be successfully demonstrated to be correct. Yet, that would mean
that an ungodly amount of time and energy (and, of course, money) would be
spent on developing even the smallest program. Although it would save a lot
of time and energy in some areas (for example, the software security
business, at least as we know it, would have never existed) it would simply
be too cost-prohibitive and also time-consuming to develop any piece of
software.
So, to sum things up, programming is in fact applied math and therefore a
programmer needs to employ mathematical reasoning to develop software. Yet,
as no one bothers to prove their code to be correct, either by incompetence
or by simply not being able to afford it, the "correctness" aspect of
mathematical reasoning isn't really valued by a programmer, which represents
a chasm between programming practices and how a mathematician is expected to
tackle problems. And this means that the thought processes may be seen as
very similar, but the details in which programming has been drifting away
from the correctness aspect of math have since made them considerably
different.
Rui Maciel
