I agree. My bottom line was meant as a joke 
(But yes, Iâm implying that Python might be a tool on par with the best, even when it comes to performances.)
Fair enough. I shall stop here.
PS. Deliberately I didnât mention explicitly the other site (doesnât really matter). If youâre interested drop me a PM.
My wording can probably use some work too. Rest assured my intent is to be all friendly in debating this. 
At the moment, every one in the top use C++ because itâs the fastest language (side note : actually, C is as fast as C++, but C++ has best features). And in almost every challenges, performances are mandatory. You canât build a strong AI without it.
I understand the argument âthereâs only C++ in the top and thatâs not fairâ. I do not agree with that. Thereâs not only C++ at the top. Thereâs only âstrongly optimized C++ codeâ at the code. Donât forget that we canât use the STL on codingame or our code will be too slow.
If tomorrow codingame change the time response for other langages and try to balance them, no one will use C++. Weâll all code in python / javascript / ruby / C# or whatever we like. Thereâs no reason to stick to âC++ without O3 and STLâ if we can do the same thing in other languages.
But thereâs a very very big problem. If you want Python to do the same as C++, youâll have to give something like 3 seconds by turn. Do you imagine how long the submits will be ? Remember Hypersonic ? It will be 30 times worse. Impossible.
So youâll say âno problem, just give 100ms to python and then C++ have 3.33ms by tyrnsâ. Well you can. You just force every one to use heurestic code because you canât do more than that in 3ms, but you can.
This.
This.
Do you think top Java code uses tons of abstractions, generics and produces tons of garbage? Let me say itâs the same very optimized very ugly Java code. I bet itâs almost the same for any language.
So, you saying you hate C/++, but CG forces you to write C/++ code. Sounds like that.
Half of the arguments so far â is if Python will receive 1h time per turn and get infinite advantage while C++ will sit at 100ms.
Letâs be realistic and think about you can do almost the same number of calculations in each language compared to baseline C++ 100ms without giving absurd arguments.
This topic is not about giving Python 1h per turn. But about closing the gap between C/++ and other languages so they can be competitive.
You can see it that way. When i play a contest, i use the best tools i have. At the moment, C++ is the best tool i have. If tomorrow the best tool is Python, iâll use Python.
As I understand it, currently all languages are compiled/run in debug mode. Compilers which have optimization options do not have them turned on.
But some languages have ways to turn some or all of those optimizations on in the source code itself. This can lead to massive performance differences. making those languages a clear best choice in contests where performance is a factor, even if you would rather use one of the others.
Solutions to this problem?
Optional release mode checkbox in the IDE so any language can be compiled with some reasonable release mode setting?
Disable optimization pragmas in languages that have them? This would still have the problem that some languages debug modes are much closer to release modes than others.
Thoughts?
Hey! We have a good relevant discussion here â https://www.codingame.com/forum/t/time-allowance-for-different-languages/1270. =)
[Done by the trolling moderator]
Just weighing in here, I donât think differing time limits makes sense at all. If a language has design trade offs that make execution slower for some positive gain, this should not be artificially erased. It would also be impossible to choose time adjustments that make sense in all situations. The performance difference between say Java and C++ can be anywhere from negative-a-little to positive-a-ton depending on the code in question.
However, the current situation where you can use pragmas to get release builds out of C++ code, but canât with Rust and others is definitely a broken situation. I think also Java only has release builds so it gets a bit of an unfair boost as well. Maybe other languages are similar.
I understand that this is a really hard situation to resolve since it massively complicates the back end, and there will be endless arguing about what compile flags are appropriate, but even a sub optimal situation would be better than the current.
One might also consider using some of the JIT options for LUA and Python, to bring their performance up, rather than using artificial adjustments.
âI think it works as expected.â
It does work as expected in a non competitive environment.
In a competitive environment it will be completely broken.
Say you given Python a 5x multiplier because the obvious solution is 5x slower, but the Python programmer figures out an ugly workaround where the interpreter load is made lighter and so it is only 2x slower.
This will be the kind of gaming that will happen. I will do it. I am ready. But it is silly and I do not want to do it.
âBut about closing the gap between C/++ and other languages so they can be competitive.â
The biggest problem I have with this is that younger programmers today are already WAY too uninterested in performance and this will only encourage it even more. As long as the performance gaps here reflect the real performance gaps innate to those languages, then people will learn real lessons, and maybe be encouraged to learn different languages where they can get better performance, or encourage the slower languages to improve (Iâm sure the Python community totally cares about Codingame!)
Disabled people have their own olympics. The only way I see is to split leaderboard in two pieces: for compiled languages and for interpreted languages.
The question here is that should this site be a âbattle of the witsâ or âbattle of programming languagesâ. If I can enable optimizations for C++ it will be the fastest solution around. If we take away the possibility, I can still write ugly fast code that beats the snot out of bytecode compiling languages.
So if this is language shootout I will be less interested, because then I only compete with people using the same language.
And if there is a competetive element here, you would like the competition be as fair as possible. For me having that advantage if I decide to use it is no fun. I like the challenge of a little more level playing field for the game.
I think a small time adjustment to bring languages more up to par trying to err on the conservative side would be an improvement. It should somehow take into account the quick prototyping and development speed gained by using an interpreted language.
That would be cheating in my opinion and I would expect it to be a reason for disqualification.
Cheers!
Thatâs not cheating when you use a good knowledge of the language about what is faster or slower. in particular with python, there are function that are purely compiled in c and thus are way faster than some other function that would be implemented in python without using much optimization. Itâs like saying to not use the STL in C++.
Many interesting remarks here. Iâll pick up two.
I agree, increasing time limits is a valid concern.
But unexpectedly, I see here another option:
not to increase but to decrease time limit, and nearly equally for everyone.
Less time means generally more power for heuristics, and less to bare performances.
Professional AI contests (e.g. Pac-Man) use something like 40ms per turn (CG could be less radical).
Obviously, compiled languages will always be at advantage, but less so by the simple power of speed.
A better eval or smarter algo would be more critical for the mission.
Given this, a âsmall conservative time adjustmentâ, as proposed by @acautin, could do the job. For example,
60ms for compiled, 120 for interpreted could be a viable option.
The analogy to sports is actually my favorite one (cf the last CG blog post on e-sports too).
And yes, in many sports you do have categories, e.g. weight classes.
Wording put apart, why not try to do more of that on CG?
We did this for code golfing since the differences between languages were just to blatant.
You could argue that in contests there are already rankings by language.
But you get no CG points and just one t-shirt vs top 50 general.
If the prizes were more âwidelyâ distributed across the categories,
maybe this discussion wouldnât be so recurrent.
In multiplayer contests I checked, C++ is roughly 7 times faster than Python. Which is why everyone has to use it for number-crunching contests.
But instead of aiming for parity, what if just make the gap smaller? Give Python (and others) a 2 times or 3 times speed boost. Itâll still be obvious that C++ is fastest, but those using other languages wonât be so ridiculously far behind.
Alternatively, we could rename this website âC++inGame.comâ to make it more obvious which language you must use if you want to compete seriously.
I think it would be better for Python developers if CG will give them more computational power by allowing Cython and all the stuff like that. Limiting C, C++, C#, Java is not the right way, because it looks childish, like: âYou are so fast! It is not fair! You should run slower, so we could compete!â
In my opinion, adding some time to Python/Javascript/Ruby is exactly the same thing 
Yeah but what he says is not the same, using Cython is a âlibrary/wrapperâ (I donât know how to really describe it) that would allow Pythonists to gain power. But the problem with Cython is to allow it âat compile timeâ ⌠so I donât know, itâs kind of the same as asking compilation options for compiled languages.
Cython is a good way of giving more power to the user, another would be to also enable libraries like scipy that help a lot for some quick computations ('cause linked to fortran/C libs). The thing I like about enabling scipy is that it would provide alternatives to the C/C++ methods, by giving Pythonists access to very specific routines of scientific computation (fitting methods for instance) that could be really cool for heuristic codes, but not that much for number crunching codes like the ones we do in C++.
Having access to compilation option will be very great for every langages
But well, the âproblemâ (for me, itâs not a problem) is still here. Javascript users are still far away from C++ in performances !