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?