LINUX.ORG.RU

ICFP 2005


0

0

В пятницу, 24-го июня, стартует традиционный турнир ICFP. Это замечательный шанс для всех флеймеров на практике доказать, что именно их любимый язык программирования - лучший.

P.S. Я так понимаю, рассчитывать на появление команды LOR-а нереально. :(

>>> Подробности



Проверено: Demetrio ()

А что, ты хотел бы поучаствовать плечом к плечу с любимыми жабабыдлокодерами? :)

anonymous
()

А причем здесь языки программирования? Похоже, что задача главным образом связана с умением быстро составлять алгоритмы (three days to solve a problem), которые к тому же были бы легко адаптируемыми (one day to adapt the program). Что-то типа усложненной школьной олимпиады по программированию :)

D
()
Ответ на: комментарий от D

Правильный выбор языка в таких задачах особенно важен. Так что этот турнир - традиционная пузомерка для разработчиков языков.

VLugovsky
() автор топика
Ответ на: комментарий от D

там ссылочка Past Contests.

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

dilmah ★★★★★
()
Ответ на: комментарий от Gagarin

Это вообще state machine по условию.

anonymous
()
Ответ на: комментарий от dilmah

Задача на моделирование. После беглого просмотра мне показалось, что она из области близкой к DES (Discrete Event Simulation), для которой есть множество своих узко-специализированных языков.

D
()
Ответ на: комментарий от D

> Очевидно, что эта задача - не для Java. :)

там довольно немало народа просто руками этот конечный автомат писали, правда в топ они не попали.

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

Сложное это дело - ручками писать. По себе знаю... Особенно, когда есть вложенные состояния, и когда язык программирования - C# :)

D
()
Ответ на: комментарий от theserg

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

Lugovsky
()
Ответ на: комментарий от Lugovsky

Прикольное у тебя юзеринфо :)

anonymous
()

У продвинутых колоний муравьев наверняка были спец. арифметические устройства (из 16 муравьев каждое:) для подсчета сравнительного богатства разных источников зерна. Прикиньте если там overflow случится. Жуткое это зрелище тысячи сумасшедших муравьев:)

dilmah ★★★★★
()
Ответ на: комментарий от Bender_Rodriguez

Ну так не одна же Java. Первого места Java таки не получала.

Lugovsky
()

эх... поучаствовать бы хотелось... но не дано: ещё расти и расти :)

Pi ★★★★★
()
Ответ на: комментарий от shch

С муравьями должно быть проще, у них правила навороченнее.

anonymous
()
Ответ на: комментарий от Lugovsky

на одной такой чудо-олимпиаде по программированию моя безобидная программа на c подвешивала ихний сервер:(

с тех пор я совершенно уверен в том, что всякие соревнования по программированию бред и участвовать в них - тупость

... и быдлокодерство...:)

theserg ★★★
()
Ответ на: комментарий от Lugovsky

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

Shaman007 ★★★★★
()
Ответ на: комментарий от Shaman007

Участвуют, как раз, коллективы.

anonymous
()

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

выход для них(чтобы призвать действительно стоящих участников) это либо перестать называть это задачей(problem) и начать называть это заданием(task), либо поместить условие на печатную страницу ..

lg ★★
()
Ответ на: комментарий от Lugovsky

>[...] разных подходов к разработке...

...одной определенной задачи в определенных условиях.

WFrag ★★★★
()
Ответ на: комментарий от lg

>условие не помещается на печатной странице

Это у тебя шрифт большой:-)

DonkeyHot ★★★★★
()

Бух-ха-ха-ха! LOL!

Доказывать, что язык A лучше, чем язык B безотносительно КОНКРЕТНОЙ задачи - просто НЕПРОФЕССИОНАЛЬНО.

Для некоторых задач Haskel и LISP более подходят, чем Java. и, наоборот, для некоторых задач императивные языки более подходящи, чем функциональные. Например, просто НЕТ ФП аналога JAIN SLEE, хотя некоторые модули можно разрабатывать, используя Parlay на ФП, что, опять, зависит от ПОСТАНОВКИ задачи.

Господин Луговский еще раз доказал нам своим топиком, что он не утруждает себя реальным ремеслом программирования, а только так, поболтать, посублимироваться, вышел...

"Жабабыдлокодер"

anonymous
()
Ответ на: комментарий от Shaman007

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

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

anonymous
()
Ответ на: комментарий от anonymous

увы ты прав, если речь о промышленном программировании.

Pi ★★★★★
()
Ответ на: комментарий от anonymous

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

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от anonymous

Блин. Ещё раз. Турнир - командный! Соревнуются КОМАНДЫ! Так что уж по любому его участники как минимум умеют неплохо в команде среднего размера работать (по результатам прошлых лет - в командах от дюжины человек).

anonymous
()
Ответ на: комментарий от Shaman007

Всезнайка Shaman007, как всегда, выдал очередную порцию гениальных поучений, не потрудившись доказать свою имху. Технологии годятся при покраске заборов. Программирование же ещё не стало тупым ремеслом, как бы там Гослинги не пыжились, в нём ещё слишком много (к моему искреннему сожалению!) остаётся от искусства.

anonymous
()
Ответ на: комментарий от anonymous

А гражданин "Жабабыдлокодер" небось думает, что для всех задач жаба подходит лучше?

anonymous
()

> когда есть ограничения по времени...

Тогда это уже спорт, а не программирование.

А сам конкурс - фуфло, независимо от поставленных целей. Есть команда А, они сделали конечный автомат на 20 состояний. Есть команда Б, которая даже не успела переписать черновики с алгоритмами. Команда А победила и её алгоритм работал 1 час. А потом, заливая горе пивом, команда Б нашла в алгоритме команды А ужасающий баг, а ещё после трех литров (и в спокойной обстановке весеннего леса) сделала безупречную программу, которая решает задачу за 2 минуты. Внимание, вопрос: ну и нах... им этот конкурс?

anonymous
()
Ответ на: комментарий от Shaman007

>который пишет что-то маленькое за задонное время

Да причем же здесь коллектив и нудные работы? Ты знаешь что нудные и мудные работы выполняют трудяги, а есть еще такая вещь как алгоритм, красота и ценность которого не зависит от его сложности и величны. Состязаются именно мозгами, на решабельных математических задачах, а не в терпеливом copy-paste.

balbes
()
Ответ на: комментарий от anonymous

>Тогда это уже спорт, а не программирование.

Да ты чувак не знаешь что такое олимпиада получеатся ))) Никто там не считает количество строчек кода, ты долбанись , смысл в быстром оформлении красивого алгоритма.

balbes
()
Ответ на: комментарий от anonymous

Так в реальной жизни у тебя всегда есть дедлайны, некогда всякой тормозной академической суходрочкой заниматься - надо выдать результат в срок, пусть он и будет не самым оптимальным.

anonymous
()
Ответ на: комментарий от anonymous

Вот на то и есть менеджер проекта - что бы с одной стороны не допускать бесконечного улучшения незначительных деталей, а с другой стороны, выбить максимум ресурсов для своей команды и не допускать изменения ТЗ в процессе работы.

Shaman007 ★★★★★
()
Ответ на: комментарий от Shaman007

Ага, не допустит манагер изменения ТЗ в процессе работы, показав заказчику, на изменении настаивающему, большую и жирную фигу. Интересно, через сколько часов он будет уволен с волчьим билетом?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.