I was considering trying to use Python on Codeforces, so I wanted to find a top rated contestant who uses Python as their main language. Turns out no red contestant uses Python as their main language. I compiled this list of who uses which language.
Not surprisingly, C++ dominates — about 95% reds use it:
C++: 262
Java: 12
Python: 3
C#: 1
Note that all three Python users were actually just messing around with the language recently, but they use C++ as their primary language. See the gist to see who uses which language + which compiler/version.
I think this is a shame, because there are many wonderful languages that simply don't get used because people fear they are slower than C++. Many problems are designed in a way that requires careful optimization even in C++ and are simply not solvable in other languages.fr
I think having execution time multiplied by a constant that differs per-language would be are a reasonable solution to penalize C++ and Java. Hackerrank already does this. If Codeforces, the most popular platform, started doing this, it could help getting the competitive programming community out of the C++ feedback loop: everybody supports C++ because everybody uses C++ because everybody supports C++.
Another way of solving the problem is to use the open-data format, which is obviously not an option for Codeforces, but Google Code Jam statistics illustrate that there is a demand for other languages as well.
Getting out of the C++ loop would help getting more people in the community because they wouldn't be forced to learn C++ (not the easiest of languages) just to stand a chance. If more people started using different languages, they would have more support, resources, tutorials etc. -- think of how every tutorial on an algorithm, technique or trick is currently written in C++. For sure having implementations of crucial algorithms in something like Python would help a lot as well, if only because of how approachable it is compared to C++.
I'm strongly opposed to the idea of execution time constant (or even non-constant) multipliers.
Why?
It can be gamed. It's not like Java is always 2 times slower than C++ or Python is 10 times slower. Sometimes it might be even slower than that. Sometimes it can be much faster. Squeezing a slow solution may become about choosing the "right" language. I definitely remember improving my score at some Hackerrank contest by rewriting my solution in Java (it originally was in C++) because the time limit for Java is larger. I don't think that it's the desired outcome.
In the real world, the user doesn't care about the language you're using. It's just a tool. An argument "It's OK for me to do a worse job because I chose an unsuitable tool" is ridiculous.
On top of that, you don't really need to know C++ well to compete. Most of the features, idioms and design patterns of the language are never used in programming contests. It's not like one needs to become a good C++ developer to solve algorithmic problems in C++.
I agree. I know almost nothing about the features of C++, and even though I want to learn them, I have never needed them so far in competitions. Moreover, the ease of writing a code in python comes at a cost. If you were to let someone use hundreds of preimplemented functions and features to obtain a slower result with less effort, and score that solution as good, that'd really be the definition of absurdity. And whenever you need to squeeze your code in C++ to get accepted, that's because it was really hard for the authors to make the difference between different solutions in the same language. It's obvious that it's impossible for them to make the difference between alternative solutions in different languages. Now, I don't claim that it's not important to learn new languages (functional programming, for example, I heard that can really help you see everything from another perspective, broadening your mind), but that importance cannot and does not have to be seen in the context of competitive programming, at least not easily.
I have thought about the library argument, but I don't think it's valid. If anything, C++ probably has a lot more things relevant to competitive programming implemented somewhere — think of resources like e-maxx, geeksforgeeks, ACM-ICPC notebooks and similar.
Python might have a big standard library, but does it really contain modules relevant for competitive programming?
I hear what you're saying, but:
This goes both ways — people are essentially gaming the system already, but that consists of simply choosing C++ every time. You could keep the factors conservative so that this doesn't happen (something like 1.5x time limit for Java, 2x-3x for Python etc.) Also rewriting the solution takes quite a bit of time, so I don't think this is a big problem.
I wouldn't dare to compare competitive programming to the real world. You are right that using C++ is clearly optimal at the moment, but the question is whether the system should be designed that way.
Yes, you don't need to know C++ well (I am certainly no C++ expert). What I meant is that the entry barrier — learning it as your first or second language — is definitely higher in C++ than in Python. This argument was directed more towards beginners than more experienced programmers/contestants.
Choosing the right tool is not the same thing as gaming the system. For instance, is using a screwdriver to drive a screw instead of bashing it with a hammer means gaming the system? I don't think so.
I would argue that the disconnection from the real world is the reason why competitive programming isn't that popular. Most of the people I know who can code and don't participate in any contests say something like: "Why would I do that? I'd rather spend my time working on skills that matter for my job/studies", and it makes sense. A further disconnection from reality might make it even worse (I obviously don't have any hard data here and I don't think that anyone else does, but that's what my personal experience suggests).
I don't think there is a difference. We agree that CP is disconnected from the real world; the contest is an isolated system; a game. You are always playing against the system. Currently, the best choice is to use C++. I am simply proposing that the game be more balanced and have more options, so that choosing C++ is not the only good answer.
As for 2., I agree, but I think this would make matters better, not worse. If more languages were legitimate choices, it would allow people with more backgrounds to get into CP easily. It wouldn't really be more disconnected — to solve that problem, the whole nature of tasks would have to change, from algorithms to implementation tasks.
Your "solution" is only going to make it worse.
How it works nowadays: novices can participate in contests and enjoy it using almost any language; to not be in inferior situation you have to learn basics of one specific language (C++).
How it is going to work with your idea: novices can participate in contests and enjoy it using almost any language; to not be in inferior situation you have to learn basics of multiple languages — because with systems like this you need to know both C++ and Java; maybe also Python. Nowadays you may need Java for some BigInteger/BigDecimal stuff, Python for some regex etc., but with changes that you suggest knowing these two will be essential — I saw how it sometimes works bad even in ICPC contests with multipliers for languages on some problems, when these multipliers were kind of picked carefully for specific problems, not just thrown in as some "I picked slow instrument, give me bonuses for it" random multipliers.
I think you are greatly overestimating the number of cases where knowing multiple languages would help. "how it sometimes works bad" is a bit vague, could you elaborate? Again, choosing the coefficients conservatively would eliminate this problem. Keep it solvable in C++ but give others a chance.
I'm referring to my experience with ICPC contests from Petrozavodsk training camp and other cases when there were problems with something like "TL: 1s for C++, 1.5s for Java" in constraints. Upd. Also, I have to say that I know 3 platforms where such system have been used (CodeChef, HackerEarth, HackerRank), and so far it didn't work well at any of them, but that's a different story and I wasn't relating to it in my previous comment.
From my subjective point of view, it is not very good when you have to code these problems in Java simply because it will give you advantage in terms of TL; it is even worse when you can use Java to get AC with some trashy solution. From my experience, it was usually happening in as much as a half of such contests (with one or more problems).
It also makes problem preparation much, much harder — nowadays you need to check that model solution passes in C++ and other languages for which you want it to pass, and then checking that bad solution doesn't pass in C++ is usually enough. With your bonus constants setters will have to implement all possible bad solutions in all languages, not only in C++, and that will require setters to know all these languages at decent level in terms of competitive programming tricks and optimizations.
I have a similar suggestions from my side. For problems with shortest distance in a graph with constraints 1e5, can we test solutions which are using Floyd only on small tests of size <=500, because they are slower? And for problems involving multiplication of vectors, should we forbid problems with constraints as big as 2e5? We want to allow people multiplying vectors naively, and forcing them to learn FFT is bad for beginners. I'm sorry for my suggestions being a bit different from yours — I'm talking about something clearly inferior that stops you from performing well, while for language question it is not like that; there are Java contestants performing better than both you and me, so you can still do quite well with it. But I hope you got my analogy :)
Thanks for the in-depth reply.
If the time limit is so strict, that's simply the problem's fault — it should be designed so that a good solution passes easily. Similarly, problems where you get TLE for
cinand AC forscanfare bad.The problem preparation point is valid, but again, if the coefficients are not crazy high (1.5 for Java seems fine), this shouldn't be a problem.
As for your "similar" suggestion, the comparison is simply not fair. As kraskevich wrote, the language is just a tool. Choosing the right algorithm is part of solving the problem. Yes, Java has some (small) representation, but that's the only exception.
I guess multiplicative time limits comes with its own problems, and its not recommendable.
I just a have suggestion, the setters and KAN should be a little more caring and receptive towards other langs (Especially Java).
At the moment, it looks to me that they don't care at all, and there have been situations (Lewin's VK Cup round), where for a problem, it was absolutely impossible to solve it in Java.
Also, I think all programmers who use Java, should also become familiar with c++. I have used c++ a lot of late and I think I'm enjoying a little.
For sure the solution is not perfect, but I think that if the constants were chosen in a way that doesn't just bridges the gap a bit (rather than trying to make them precisely equal), it would be better than nothing.
Maybe Len can help!