Hi, We understand that, whatever change we make, some people will be happy and some others will be unhappy about it. Some of your concerns are true, but I think I can argue why the new system is better. However, in most cases, it's a matter of personal preference, and I hope you can find Code Jam enjoyable even though you prefer some things would be different.
On Wed, Mar 14, 2018 at 6:18 AM, meir <[email protected]> wrote: > I thought working with the code locally and being language agnostic was > one of the best features of code jam. > We agree. We are hoping to scale to support a lot more than 10 languages in the future, so bear with us. We'll add them in approximate order of popularity. > Not only do I write most of my code in Scala, I like to develop and debug > using my own IDE. > You are more than welcome to use your own IDE to write the entire code, test it, and debug it, and just copy/paste your code into the code box in our site only when you are ready to submit. That part should be no different than before if you don't want it to be, except instead of download / run / upload you would do copy / paste / submit. We think this part is a plus for most people, as it requires less time, it's less error prone, and it takes time (almost) independent of your internet connection speed. > I often also used the test files for debugging, especially moving from > small input to large. Not having access to input data makes debugging a very different beast. You were smart to do that, as Code Jam is a contest and you should do everything within the rules to do better! And the possibility is indeed taken away with the new system. However, we think this actually makes the contest better for the most part. Debugging with the actual input is a luxury that doesn't happen often in real life. Most of the time you make your own input, or use past data to test your changes to your code, but unknown inputs (i.e., new users, be that end-users or other code that you have no control over) will happen after you deploy your code. Of course a programming contest environment is restricted and doesn't reflect accurately (or at all) a lot of aspects of real-life coding, but we believe the ability to have a fully correct program without knowing what its input will be (within the specification, of course) it's an important one. > I would not have the small file with all the edge cases mapped out for me. > > This has a similar answer as the previous point, plus, it also checks your testing ability. In our jobs, we write most of our test data, and we expect most jobs are like that, so again, favoring people's ability to test their own code is a plus of the new system. Even if someone's performance takes a hit at the beginning, we believe training to make testing your code better part of the problem solving will make you a better programmer down the line. > I don't like this change, I also didn't realize this was it when I read > the announcement at first, I understood submitting code as an option not as > mandatory. > > > I don't see how the change levels the playing field, unless you go with > much larger inputs, the language differences are still very significant, > trumping hardware variability. > > This is actually not true. If you believe Moore's Law of computer power doubling every two years (not claiming but this is true, but it's ok for a handwave analysis in an email), a 10-year old computer is 32 times slower than a modern one. Most programs significantly less than 32x appart in speed depending on the language you use. That being said, access to multiple modern computers to parallelize can make hardware differences even more significant. Additionally, speed connection can make a difference: if it takes a full minute to download the input and another minute to upload the output, you just have half the time to solve the problem (and a simple 2G connection, which is still in use, and can even be not the oldest in use) will take about a minute to transfer a 250K file). Unfortunately, there are people who have to make due with 10-year old hardware and, and possibly even older than that. Notice, however, that all this specifics can be wrong and it is still not the point (although still fun to think and write about), because of the following: Both access to more and more modern hardware and to better internet speed are mediated heavily by wealth, so making those differences less important levels the playing field in arguably the most important way. Access to programming languages knowledge among people who know at least one, on the other hand, is not as heavily mediated by wealth: if you know Python, you can probably learn C++ quickly, at least to the extent you need to solve programming contest problems (i.e., no specifics of memory management). Choosing your programming language by weighing their pros and cons (including your own comfort and proficiency) is also an important ability, and one that comes up in real-life. As a specific example, we are currently using at least 5 programming languages from the 10 Code Jam currently allows in different parts of the new Code Jam system, and a bunch of other pseudo-languages that write configuration files. You are welcome to try to guess which languages we are using and for what, and possibly discover at least one, but we are not telling :). Best, Pablo -- You received this message because you are subscribed to the Google Groups "Google Code Jam" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-code/CANa5jcDmF6TTazL5WoaJXoe-f0d3mBTDtDWP%2BO5-GjuPeSqJzg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
