Rambler's Top100 Service калинин.ru / программирование / соревнования /  << 28.09.00 >>

Критика правил олимпиад ACM

Вы знаете, самое смешное заключается в том, что я уверен в полной практической бесполезности навыков, которые были мной получены на олимпиадах. Понятно, что особенно похвастаться мне не чем: команда, в которой я выступал никогда не была самой первой... один раз она была второй, это оказалось пределом для нас (хотя тогда казалось, что нет).

Так вот: на практике все эти "соревновательные" рефлексы просто не к чему, а иногда просто мешают...

Но хочется рассказать о том, как сейчас проводятся соревнования по программированию среди студентов. Состязания командные: команда состоит из трех человек и на каждую команду выделяется один компьютер. Обычно соревнование длится 5-6 часов, за которые надо решить как можно больше задач из предложенного набора (количеством от 5 до 7).

Участники могут сколько угодно раз посылать программы-решения на проверку и видеть текущее состояние турнирной таблицы, на которой показано положение всех команд, рассчитываемое исходя из количества решенных задач и полученных штрафных очков. За час до конца состязаний турнирная таблица "замораживается", т.е. перестает показывать актуальное состояние. Это позволяет сохранить интерес участников к результатам олимпиады. Кроме того, за пять минут до конца перестают приходить результаты тестирования решений: при помощи этого организаторы борятся со шквалом решений, поступающих от участников в последние минуты матча (сдают все, что только можно: вдруг пройдет?) и еще более драматизируют развязку.

Кроме того, программа-решение считается правильной, если ее вывод признан правильным на наборе тестов жюри, при этом исходный текст никак не анализируется (кроме проверки выполнения запрещенных действий) и решение засчитывается только "целиком", без всяких "идея верна, но где-то ошибка в реализации".

Все это, а в особенности существование доступной участникам турнирной таблицы, делает соревнования очень похожими на спортивные. Страсти иногда накаляются до такой степени, что болельщики становятся похожими на футбольных фанатов.

Раньше в СССР проводились свои олимпиады по программированию, которые были устроены немного по-другому. Во-первых, каждый участник имел свой собственный компьютер и командная оценка выставлялась как сумма оценок всех участников. Во-вторых, не была доступна турнирная таблица. В-третьих, тщательно выверялся исходный текст решений с целью поиска в них правильных идей. В-четвертых, никто не требовал от команд сдачи решений в как можно сжатые сроки (в современных олимпиадах на команду начисляется тем больше штрафных очков, чем дольше времени прошло в момент подачи решения от начала состязаний) и все решения анализировались после истечения времени олимпиады.

На мой взгляд, "старый" подход значительно объективнее "нового", который позаимствован из олимпиад ACM (Association for Computer Machinery). Прежде всего, весь этот накал страстей среди участников не способствует их собранности и, поэтому, внутреннее психологическое состояние человека очень шатко. Любая неудача может вывести его из себя до конца соревнований так, что он больше ничего сделать не сможет. Таким образом, выиграет команда, которая является более психологически собранной в данный момент, даже если ее участники относительно слабые. А это достаточно странно: потому что оцениваются "программистские" качества людей, а не их устойчивость к внешним раздражителям. Фактически на командах сказывается практически все, что происходило с ними в последние дни: переезд в другой город, гостиница, новое место, бессоница, легкая простуда и т.д.

Кроме того, получается так, что людей заставляют решать задачи на скорость. А это совсем оторвано от реальности, потому что программист должен писать программы прежде всего качественно и в расчете на последующие изменения, а не на использование в ближайшие пять минут. Программист --- не курьерский поезд.

Все задачи оцениваются одинаково. Фактически это означает, что если в блоке задач была одна нерешаемая и несколько простых, то команда, решившая простые, займет более высокое положение, чем команда, которая решила "нерешаемую" задачу (одну). Это уж совсем неправильно, потому что реальной заслугой является именно решение сложных задач, а не простых. Организаторы утверждают, что таким образом они заставляют команды (и участников) оценивать задачи самостоятельно. Это сомнительно, потому что решение сложной задачи (пусть и с заранее известной оценкой) опять же много более ценно, чем умение выдлять простые.

Решения оцениваются по работе программ, их представляющих. Это значит, что программа пропускается сквозь набор тестов и ответы сверяются с заранее подготовленными. Это неправильно в принципе: еще Дейкстра писал о том, что тестирование не может доказать корректность работы программы, оно может лишь опровергнуть это утверждение. Таким образом, отказ от анализа решения приводит к тому, что участники стараются сделать программу, дающую ответы "как у жюри" на предложенные тесты (они неизвестны, но о них можно догадаться), а не решить задачу. Надеюсь, разница ясна?

Кроме того, мне совершенно неясно, почему на олимпиаде по программированию (!!!) не учитывается исходный текст программы. Это просто жутко, если вдуматься: в реальной жизни человек может решать любые задачи, но ему будет грош цена, если у него будет непонятный исходный текст. Программа никогда не становится законченной вещью, всегда через некоторое время в нее придется добавить новую функциональность. И что хорошего, если для этого все придется переписывать заново?

Остальные замечания относятся к выбору задач на олимпиадах. На самом деле, очень сложно отделить программирование от конкретных приложений. Все дело в том, что программирование само по себе никогда не существует, оно всегда применятся для решения возникающих проблем из самых разных областей человеческого знания. Тем не менее, программирование представляет из себя отдельную науку, которая требует тщательнейшего изучения и своей собственной методики оценок. К сожалению, это до сих пор не сделано, и задач именно по программированию, фактически, не существует. Есть задачи на приложение программирования к, например, решению математических проблем. Существуют множество задач на знание основных алгоритмов обработки данных... задачи на теорию расписаний... на комбинаторику... в общем, на все что угодно. Обычно выбор темы остается на совести автора задачи, который сам по себе является специалистом в какой-то области математики или просто вспомнил какую-то теорему, когда придумывал задачу. Это не является задачами на программирование! Понятно, что программист должен знать комбинаторику, владеть элементами математического анализа, но это не значит, что его "качество" как программиста можно оценить по знаниям этих предметов. На всякий случай повторю: нельзя в олимпиаде по программированию оценивать решение без учета организации исходного текста. Это просто абсурд.

Все эти недостатки приводят к тому, что лучшими на подобных соревнованиях, скорее всего, будут не самые сильные и опытные программисты. Мало того, программисты "практикующие", т.е. реально работающие, будут на таких олимпиадах проигрывать, просто потому что никогда не пишут программы на скорость; не привыкли нервничать при работе; решают задачи в удобном порядке, а не в нужном.

Организаторы состязаний утверждают, что "упаковка" участников в команды дает им опыт работы в группе разработчиков. Смею вас заверить, это бред чистейшей воды. "Команда" придает лишнюю нервозность: один человек находится за компьютером и, если у него что-то не получается, то он будет "тормозить" весь коллектив, от чего сразу же становится не по себе всем участникам команды. А работа группы разработчиков подчиняется другим правилам и, вообще, управление группой в реальной жизни совсем не похоже на игру команды. Кроме того, группа разработчиков никогда не решает задачи, которые может сделать один человек. Группа набирается только для работы над большими программными системами, где основные проблемы уже не алгоритмические, а проектные. Точнее, нельзя сказать, что какая-то из этих проблем доминирующая: они вообще "ортогональны" друг другу. Проектирование же является задачей ничуть не менее сложной, чем алгоритмические проблемы. Таким образом, командная игра в смысле ACM ничего не дает участникам как будущим программистам.

Так вот: "старые" олимпиады были значительно честнее. Потому что оценивали программистов и не устраивали шоу.

Хотя, как шоу олимпиада по этим правилам очень здорово смотрится. Честно. И участие в них... в общем, это что-то сложно описуемое (в смысле, не в этой заметке). За это можно многое простить. Но я никогда не считал полученную турнирную таблицу объективной. Во всяком случае, полностью объективной --- команда, которая занимает первое место обычно вполне достойна этого (как, впрочем, и многие другие).

Резюме

В олимпиадах очень интересно участвовать; кроме того, интересно их проводить. Но результаты соревнований никогда не бывают полностью объективными: в отличие от спорта, программирование имеет конкретное приложение и профессиональный программист не нуждается в каких-либо оценках "со стороны".

PS

Со 2 по 4 октября состоятся четвертьфинальные соревнования чемпионата мира по программированию. Пройдут они, опять, в Рыбинске... соответственно, я везу туда две команды от МАИ, потому и мысли мои обращены в последнее время к предстоящим соревнованиям.


Версия для печати


  Ссылки по теме:
http://www.acm.org/contest
   Домашняя страница олимпиад ACM.
http://www.ifmo.ru/neerc
   Официальная страница полуфинала чемпионата мира по программированию на сервере Института Точной Механики и Оптики в Санкт-Петербурге.
  Рядом в разделе:
III Московская командная олимпиада по программированию (22.10.00)
   Вот уже в третий раз МГУ проводит Московскую командную олимпиаду по программированию по правилам, аналогичным правилам ACM. Можно о корректности этих...   >>>>
  Рядом по дате:
Язык UML, рукводство пользователя (29.09.00)
   UML (Unified Modeling Language, унифицированный язык моделирования) является еще одной популярной аббревиатурой, которой очень часто пользуются, не понимая того, что за...   >>>>
Средства для разбора XML-файлов (27.09.00)
   С момента последнего обновления в этом разделе прошло уже больше месяца... но ведь никто же никому ничего не обещал? ;) Тем...   >>>>
  Содержание:
Заглавная страница
Мой блог
Мое резюме
Дайджест
Программирование
   C&C++
Сети
Unix
Алгоритмы
Оптимизация
Соревнования
Отвлеченно
XML
TeX
Просто так
Студенческое
Туризм
  Байки
Фотографии
Комментарии
   Книги
Web-ресурсы
Фильмы
Интернет
Программное обеспечение
Жизнь
Благодарности
Форум
Хронология
 
  В этом разделе:
III Московская командная олимпиада по программированию (22.10.00)
   Вот уже в третий раз МГУ проводит Московскую командную олимпиаду по программированию по правилам, аналогичным правилам ACM. Можно о корректности этих...   >>>>
Критика правил олимпиад ACM (28.09.00)
   Вы знаете, самое смешное заключается в том, что я уверен в полной практической бесполезности навыков, которые были мной получены на олимпиадах....   >>>>
Содержание раздела полностью...
   Примерно в тоже время
Язык UML, рукводство пользователя (29.09.00)
   UML (Unified Modeling Language, унифицированный язык моделирования) является еще одной популярной аббревиатурой, которой очень часто пользуются, не понимая того, что за...   >>>>
Средства для разбора XML-файлов (27.09.00)
   С момента последнего обновления в этом разделе прошло уже больше месяца... но ведь никто же никому ничего не обещал? ;) Тем...   >>>>
Хронология полностью...
   Содержание
Заглавная страница
Мой блог
Мое резюме
Дайджест
Программирование
  C&C++
Сети
Unix
Алгоритмы
Оптимизация
Соревнования
Отвлеченно
XML
TeX
Туризм
  Байки
Фотографии
Комментарии
  Книги
Web-ресурсы
Фильмы
Интернет
Программное обеспечение
Жизнь
Студенческое
Просто так
Благодарности
Форум
Хронология
© 2000-2008, Andrey L. Kalinin
mailto:andrey@kalinin.ru
Rambler's Top100