2024-04-24 12:51:12
Yesterday I came across an article that discusses mathematical
vs. programming interests, in how a math-oriented person might
approach some problem differently or with different intents than
a programmer.
https://lobste.rs/s/vkqqvl/programming_vs_mathematical_curiosity
This article really resonated with me, because I feel exactly the
same way. I've been practicing cp for a few months now, every now
and then I get distracted with the programming aspects, when
attempting to focus on problem solving.
The article starts off with introducing an interesting
observation in math. The author goes on to implement brute-force
checking with programming (Ruby specifically). Along the way,
they get "distracted" with the implementation -- discussing
different ways and achieve the same task and how one is better
than another. At the end, the program successfully verifies the
theory. But we note that, interestingly, how the author
approached attempting to construct a proof using a brute-force
program was different to how a math-oriented person might do it.
Let A be the mathematician and B be our programmer, for
convienience.
Personally, I am not an A-type person, so my analysis would base
solely on imagination and fragmented personal experience.
Given a problem, both A and B start off with figuring out how to
solve the problem.
Once they come up with the solution, both A and B attempt to
implement the solution.
A is driven by the desire to "get the thing done". A wishes to
write/implement a _correct_ proof. Whereas B is caught up in
implementation details and might finish their proof slower. B
contemplates on different ways to do the same thing, whether one
way of writing the code is more maintainable, more readable, more
performant.
Both A and B might do some finishing touches on their proofs once
it's complete, to save it for the future. But B might incessantly
continue to try and improve it -- even though its purpose had
been fulfilled by satisfactory means. B might consider how they
can "refactor" some function, extract it into its own module,
attempt to make the code more elegant, make use of some language
faeture (or rewrite it in their own toy programming languaage),
just for the sake of it.
What I've described of B, is based off my experience in CP, quite
literally. A more seasoned competitive programmer might move on
to the next problem (in search of the sense of gratification when
having found an elegant solution), where as I relish in the
beauty and robustness of my code. In the case of CP, one may be
useless -- contestants are judged on how many problems they
solve, rather than how well their solution is implemented.
However, that's where I see the line between CP and software
development. In CP, code we write might possibly be only visited
once -- that is at the time of writing. In the future, they might
only be brought up for reference or sharing purposes. In software
development, code must be maintainable because this same code
would be exposed to scrutiny every day, added to, improved upon,
rewritten, argued about. In this perspective, I sometimes almost
view those who focus more on problem solving as "machines that
just solve problems". They get the job done -- such as A in the
example. All efforts are focused on the sole goal of solving the
problem. Once that is done, I imagine them to have little
motivation and the continued persuit of writing the code for this
solution.
This distinction does not stop at writing code.
A lot of people in CP tend to encounter "meta" problems every
once in a while -- the environment setup -- whether that be due
to switching workstations, reinstalling, disk reformat, and so
on. I've come to realize that most of these people, _despise_
this process. They bicker others on online communities begging
for help, complaining how "life is just so painful" when it
doesn't work (perhaps they forgot to add that binary to $PATH),
and "I wanna kms" when their situation appears different to that
youtube video tutorial they're following. Once they finally,
_magically_ get it to work, they leave the downloaded .zip files
there, not even bother to take a note on what solved the issue
(to be used in the future), and proceed to solving that
Codeforces round from yesterday they'd missed.
It pains me.
They know segmentation trees and the Floyd's algorithm in and
out. They can tell you in what cases might DP not be applicable,
yet they can't tell the difference between "an editor with
compiler integration" and a "compiler program" apart.
You can't make good use of your CP knowledge until you dive into
software development and transform it into an actual product that
customers will pay you for.
Now, I digress, we're supposed to explore the differences of
mathematical ("problem solving") vs. programming interests in a
civilized manner, not loathe on fellow CP people not knowing how
to setup their environment for the 100th time.
In software development, we need _both_ the problem solving
aspects and the continual improvement and refactoring. I guess
people are different, some just don't enjoy spending a whole
weekend tweaking their emacs config, read the entire Nix Home
Manager manual, or write a lengthy post comparing different
dotfile managers. Perhaps a lot of these CP people I've observed
aren't even interested in learning about the inner workings of
C++, the spec, how the spec gets updated, how the
mission-critical compilers they rely on, work. Nay, when their
code ends up with a "Runtime Error" on the judging server they
try using the C++20 option, then switch back to the C++17 option.
Still doesn't work? Let's try GCC! What's the difference between
g++ and gcc anyway?
Software cannot progress without these pure problem solvers. Nor
can perhaps physics/engineering without those pure mathematicians
that ponder about unspeakably abstract and philosophical ideas.
Well, but I'm just not one of them. I *enjoy* learning about how
things work, why they must be that way, what are those stories on
the failures that led to this thing being implemented this way.
Why Rust is so popular and claiming to be more memory safe than
C. I enjoy spending a whole afternoon perfecting an automation
script for my convenience when I'd use it some time in the
future -- if ever. I can do CP, but I'm just not one of those who
might excel at it, because how can I grind pass as many problems
as A, if I'm still pondering on whether I should refactor this
function and rename that variable when they've already moved on
to the next Kattis problem?
