Recently a friend of mine, who is reasonably well rated on Codeforces (1800+) talked about how Codeforces/Atcoder/Codechef tasks are very important in teaching us how to implement efficient code and how it is very important when you are writing general libraries (think Tensorflow, PyTorch, React, Express etc). I don't agree with him. I told him that people like Linus Torvalds wrote a lot of code that a lot of critical infrastructure uses. These people wrote fast and fault-tolerant code without having any experience in algorithmic competitions. But his argument is that the low-hanging fruits of algorithmic optimizations have already been achieved and in the coming years only those who have good experience with competitive programming will be able to improve these systems reasonably. What do you guys think?
Is it really that to learn to write fast and fault-tolerant programs you need competitive programming; or is there a better way to learn the same? If so, what's that better way?
Also, what, in your opinion, is a real-world skill that competitive programming teaches?
[P.S: I can already sense the downvotes coming after me.]
In my point of view, competitive programming it is not about writing faster code.
The main deal of CP is improving your logical think and your problem solving skills.
The majority of the algorithms that you learn on CP, you won't use them in the real world, however the skill of interpreting and solving a problem is one of the most important in the real world, and we train it every day here in codeforces !
you are barely pupil, what CP you are talking about ?
Well, I think the point of competitive programming is to be a cool hobby :)
That being said, I do think there are some practical benefits. For example, I've noticed that people who are good at competitive programming tend to be good at realizing there are edge cases before they come up (at least those who do not rely overly much on "proof by AC").
I think that is arguing $$$A$$$ from $$$B, A \to B$$$.
Makes sense.
I don't understand this though: I think that is arguing A from B, A→B.
What's A? What's B? And what's wrong arguing like this?
Basically correlation != causation
It's logic notation. To use a silly example, if $$$A$$$ means "animal is a dog" and $$$B$$$ means "animal has four legs", then $$$A \to B$$$ means "if an animal is a dog, then it has four legs", which is true. But certainly cats aren't dogs, so even if I know that an animal has four legs, that is not sufficient to claim that that animal is a dog.
In this case, just because it is possible to write fault-tolerant fast code without doing CP doesn't mean that CP can't teach you that.
No, it's not at all "basically correlation != causation".
No, in order to be good software developer you do not need competitive programming at all.
Competitive programming is for those who are too weak to succeed in online chess. I don't think that there are any irl benefits except for getting better at technical interviews.
Competitive programming teaches you to devise non-trivial solutions to abstract problems. That is the most important part. If you read "implement a filesystem stack for an OS" and go "I'll just use NTFS/FAT32", that's ging to work, but it's not going to be fast, by a large margin. Here's just a few things in the Linux kernel that are hard to get right and whose solutions lie far from the original problem:
A graph structure is often read but seldom written. Devise a thread-safe way to work with it. Hint: mutexes are slow even without contention. The Linux answer: RCU.
OSes in VMs typically have quite a few memory pages with identical content. How do we merge them to reduce physical memory pressure? Hint: look for better researched problems in the same area. Answer: adapt multi-generation GCs, also keep pages in a B tree ordered by their byte contents.
Schedule processes "fairly". This is an open problem, sort of, because we don't quite understand what "fairly" means. Linux has historically tried multiple solutions. The current solution uses priority queues, so you could probably say a DSA course has helped someone here.
There's so many times you face a problem and the most obvious solution is also the wrong one. Operating systems, databases, consensus and fault tolerance, API design, dev tooling, the list goes on. It probably doesn't matter much if you're just writing CRUD, but that's not all there is to programming.
The typical way to develop this skill is to throw yourself at lots of different problems. The more problems you solve, the more you learn. But it's not just about solving problems, it's about solving them the right way. If you use the same inefficient pattern all the time, that isn't going to teach you anything. You need to set goals that you think are unachievable, and then work hard to meet them.
Competitive programming does that at soul-crushing speed.
Are there other ways to generate lots of problems? Sure! But that's going to be less efficient no matter how you look at it. I've had all the time in the world, I've been routinely doing side projects for years. This certainly helped me, a lot, but even then, competitive programming taught me stuff I never thought I wanted to know. So there's that.