Competitive Programming with AlphaCode

Post by machiaweliczny » Wed, Feb 02, 2022, 7:15 PM UTC

jakub_g wrote: post #109

FemmeAndroid wrote: post #103

This is extremely impressive, but I do think it’s worth noting that these two things were provided: - a very well defined problem. (One of the things I like about competitive programming and the like is just getting to implement a clearly articulated problem, not something I experience on most days.) - existing test data. This is definitely a great accomplishment, but I think those two features of competitive program…

100% agree. Someone (who?) had to take time and write the detailed requirements. In real jobs you rarely get good tickets with well defined expectations; it's one of most important developer's jobs to transform fuzzy requirement into a good ticket. (Side note: I find that many people skip this step, and go straight from fuzzy-requirement-only-discussed-on-zoom-with-Bob to code; open a pull request without much contex…

Post by RangerScience » Wed, Feb 02, 2022, 7:18 PM UTC

xmprt wrote: post #66

chongli wrote: post #62

Earlier quoted context omitted.

repetitive code like this.foo = foo; this.bar = bar etc... This sort of boilerplate code is best solved by the programming language. Either via better built-in syntax or macros. Using an advanced machine learning model to generate this code is both error-prone and a big source of noise and code bloat. This is not an issue that will go away with better tooling; it will only get worse.

I don't think I agree. Most people spend more time reading than writing code so programming languages should be optimized to be easier to read whereas tooling should be made to simplify writing code. New syntax or macros sounds like it would make the language harder to read. I agree that an advanced machine learning model for generating boilerplate code isn't the right approach but I also don't think we should extend…

Post by RangerScience » Wed, Feb 02, 2022, 7:21 PM UTC

nsxwolf wrote: post #74

jxcole wrote: post #41

Earlier quoted context omitted.

I feel like you are very defensive here and I want to be sure we take time to recognize this as a real accomplishment. Seriously though, I do doubt I can be fully replaced by a robot any time soon, it may be the case that soon enough I can make high-level written descriptions of programs and hand them off to an AI to do most of the work. This wouldn't completely replace me, but it could make developers 50x productive…

Yesterday, I spent several hours figuring out if the business requirement for "within the next 3 days" meant 3 calendar days or 72 hours from now. Then about 10 minutes actually writing the code. Everyone thought my efforts were very valuable.

Post by rfoo » Wed, Feb 02, 2022, 7:23 PM UTC

gfd wrote: post #95

baobabKoodaa wrote: post #76

Earlier quoted context omitted.

The median rating is not descriptive of median ability, because a large number of Codeforces competitors only do one or a few competitions. A very small number of competitors hone their skills over multiple competitions. If we were to restrict our sample to competitors with more than 20 competitions, the median rating would be much higher than 1300. It's amazing that Alphacode achieved a 1300 rating, but compared to…

You can find the rating distribution filtered for >5 contests here: https://codeforces.com/blog/entry/71260 I am rated at 2100+ so I do agree that 1300 rating is low. But at the same time it solved https://codeforces.com/contest/1553/problem/D which is rated at 1500 which was actually non-trivial for me already. I had one wrong submit before getting that problem correct and I do estimate that 50% of the regular compe…

Post by bcrosby95 » Wed, Feb 02, 2022, 7:27 PM UTC

andy_ppp wrote: post #105

udev wrote: post #101

Earlier quoted context omitted.

Yes, for very precise, comprehensive text descriptions of problems. It will take a far-far more advanced AI to write such descriptions for real-world problems. Writing requirements for a project is difficult work, and not for technical reasons, but for human reasons (people don't know what they want exactly, people have trouble imagining things they haven't seen yet, people are irrational, people might want something…

I would actually argue the programmers job has never been 100% writing the code, it’s always been interpreting, fixing and decoding the ideas of others.