2008-07-25

О пользе унификации и вреде предубеждений

Написано для: developers.org.ua (изменен код макро gcase)
Время написания: июль 2007


In fact, let’s not even worry about Java. Let’s not complain about Microsoft. Let’s not worry about them because we know how to program computers, too, and in fact we know how to do it in a meta-way. We can set up an alternative point of view, and we’re not the only ones who do this, as you’re well aware.[1]
–Alan Kay
There is a huge difference working with a language where you have to wait a year to get a new loop statement from the language designer and compiler implementer - or - where you do it yourself in twenty minutes.[2]
–Rainer Joswig


1. Принципы хорошего стиля программирования



На Западе широко известна следующая концепция из классического учебника MIT по программированию “Структура и интерпретация компьютерных программ”:
Сперва мы хотим утвердить идею, что компьютерный язык — это не просто способ добиться от компьютера выполнения операций, но, скорее, что это новое средство для формального выражения идей о методологии. Таким образом, программы должны быть написаны для людей, чтобы они их читали, и только между прочим для машин, чтобы они их исполняли.[3]


Есть и другой подход: программа — как набор кубиков лего, которые нужно любой ценой состыковать вместе, а где совсем не сходиться — допилить напильником.

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

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

К сожалению, современные мейнстрим языки жертвуют целью сделать возможным хороший стиль из коньюнктурных соображений реализации. В результате нам приходится использовать корявые языки, что приводит к полной неэффективности на более высоких уровнях абстракции. Мало того, что программист для того, чтобы получить возможность создания серьезных программ, вынужден вкладывать большое количество времени в изучение эзотерических технологий, которые через пару лет устареют (они устаревают как раз из-за своей ограниченности и привязки к конкретным промежуточным архитектурам), таких как: фабрики классов COM или же MFC на пару с Win32 API, AJAX и пр. Применение этих технологий серьезно затрудняет развитие достигнутых результатов другими людьми, которые не имеют времени, желания или возможности изучить их, не говоря уже о внутренних ограничениях самих технологий.

Также и хорошая парадигма, как и любая другая идеология, дает большой выигрыш на начальном этапе, но становится тормозом развития впоследствии, и языки программирования созданные для реализации концепций одной парадигмы становятся ее заложниками. Человек лучше всего думает на естественном языке, и хороший язык программирования должен давать ему возможность наиболее естественно (т.е. близко к их оригинальной форме) выразить свои мысли о структурах данных и алгоритмах, которые составляют по Вирту все, из чего состоят программы, накладывая при этом как можно меньше ограничений. В языке программирования должны быть равные возможности реализации любой прадигмы, любой концепции, способной зародиться в голове программиста, наиболее простым и элегантным путем. Такой подход лежит в основе Lisp’а, “программируемого языка програмиирования”.

2. Ограниченность языков с жестким синтаксисом



Если говорить по существу, то первая проблема большинства языков — жесткий и часто весьма запутанный и не унифицированный синтаксис, который, если немного перефразировать слоган Perl’а, делает некоторые вещи (которые по мнению создателя языка должны быть простыми) простыми, а остальные — как прийдется. А приходится так, что, большинство концепций, которые не были приняты во внимание при создании языка, требуют огромных трудозатрат для реализацию теми, кто в них нуждается. В качестве примера можно привести такую вездесущую потребность, как передача функций в качестве параметров другим функциям (так называемым, higher-order functions), которую не возможно элегантно реализовать в императивных языках (С или Java). Можно обратиться к функциональным языкам, но и здесь мы видим, что в основу языка заложено множество семантически-нагруженных конструкций, об универсальности которых говорить не приходится.

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

Показательным в этом отношении является шаблон with-..., который используется в Lisp’е в таких задачах, как работа с файлами и потоками, интерфейсами и протоколами обмена информацией. Примером может быть запись данных в файл. Это требует выполнения таких операций, как объявления переменной потока вывода, открытие физического файла на запись, при этом проверки на предмет того, возможно ли это, и выполнения соответсвующих операций в случае ошибок. Также не нужно забывать о необходимости закрыть файл после окончания манипуляций с данными. Все эти операции просты и рутинны, а необходимость их повторного написания много раз приводит к бесполезной трате времени, а также к тому, что файл в конце концов забывают закрыть… В Lisp эта констукция реализуется с помощью макро with-open-file в теле которого выполняются манипуляции с данными. Почему такой подход не применяется в других языках — об этом ниже.

3. Синтаксис Lisp’а



Почему-то распространено мнение, что у Lisp’а сложный синтаксис, впрочем обычно подразумевается другое — зачем все эти скобки??! А вот Lisp-программисты считают, что у Lisp’а вообще нет синтаксиса.

На самом деле, как верно подмечено в комментарии Тима Бредшоу у Lisp’а синтаксис минимальных обязательств. Можно сказать, что он выполняет только лишь функцию необходимой регуляризации английского языка для того, чтобы исключить неоднозначность.

Программы Lisp’а — это текст: есть атомы — символьные идентификаторы — это слова, есть список — атомы, разделенные пробелами и взятые в скобки — это предложение. Lisp Reader4 (можно легко представить себя на его месте) читает этот текст и интерпретирует его в качестве так называемых s-выражений, т.е. подходит к нему с таким набором предпосылок:
  • в любом s-выражении первым идет имя операции, а остальные элементы могут быть s-выражениями либо атомами

  • любой атом является либо именем либо означает сам себя

таким образом, s-выражение имеет следующий вид: (имя элемент элемент ...), где элемент — список либо атом.

Так зачем все-таки все эти скобки??! Риску начать издалека. Когда люди впервые занялись символьной математикой, они начали с использования простых операций — = + - * > < — которые имели 2 аргумента, т.е. выражения записывались в виде c = а + b. Им сразу же пришлось столкнуться с проблемой порядка операций (что будет, если записать d = a + b * c, и появились скобки, которые вернули в математику однозначность :). Чуть позднее появилась концепция функции, т.е. обощенной операции, которая имеет аргументы и значения. Поскольку многие функции также могут иметь несколько аргументов и даже несколько значений, их пришлось записывать, например, так: f(x, y, z) := (x, y) + (y, z). Здесь уже теряется единообразие: для базовых операций используется инфиксная нотация (т.е. операция записывается между своими аргументами), а для самой функции — по сути дела префиксная (или польская нотация). Что если попытаться свести все к единой нотации: := f x y z + (x y (y z. Не все понятно и однозначно. Убрать неоднозначность можно, добавив скобок: (define f (x y z) (+ (x y) (y z))). Выглядит не совсем привычно, но и изначальная конструкция тоже не была первым, что мы изучили в школе на математике.

4. Метапрограммирование



Что дает нам префиксная запись операций по сравнению, например, с С-подобным синтаксисом? Думаю, кому-то интересно будет узнать, что во внутренних структурах компилятора программа С выглядит так же. Я, конечно, не имею в виду, что там у них тоже скобки :). Но после прохождения сложного синтаксического разбора С-программа преобразуется компилятором в абстрактное синтаксическое дерево (AST). Код Lisp’а — это и есть AST, подавляющая часть которого скомпрессирована в виде MACRO’в (или, как находчиво придумал Conrad Barski — SPEL’ов), записанный прямо у нас перед глазами. И, поскольку мы избавлены от необходимости трансляции кода программы из ее обычного синтаксиса в AST и обратно, открывается возможность для широкого использования MACRO’в: если мы видим повторяющиеся части в дереве, их легко абстрагировать.

упрощенный вариант преобразования AST, выполняемое с помощью MACRO with-open-file

На это можно посмотреть и с другой стороны:
Lisp — это исполняемый XML с более дружественным синтаксисом.[4]


Ведь XML-файл — это тоже по сути дерево данных и метаданных. Только, чтобы избежать круглых скобок, создатели SGML/HTML/XML придумали использовать угловые и записывать название каждого тэга дважды! HTML элементарно преобразуется в подмножество Lisp’a, как показывают многочисленные реализации Lisp’овых библиотек для HTML-генерации (например, CL-WHO или ParenScript, который также реализует JavaScript и CSS). Интересно то, что в Lisp’е HTML-генерация намного естественней заточенного специально под задачу создания динамических веб-страниц PHP, в котором все в конце концов сводится к банальному вызову функции echo.

За счет использования MACRO’в, Lisp позволяет выражать свои мысли в наиболее лаконичной и адекватной форме, а каждый программист имеет способы самостоятельно сформировать набор примитивных конструкций языка, с которыми он будет работать в рамках конкретной проблемы, программы или платформы. Вы можете сказать, как и в большинстве других языков if ... then ... else ..., но также вы можете сказать when … then …, unless ... then ...; кроме того, вы можете сказать condition 1 -> expression 1; ... condition n -> expression n, case ... variant 1: expression1 ... variant n: expression n. И это далеко не полный список, на самом деле, вы можете легко реализовать любую логическую конструкцию и по возможностям использования в программах она ни чем не будет отличаться от обычного if-then-else.

Конкретный пример: в стандарте Lisp есть 3 вида case конструкций, которые имеют такую обобщенную форму:

case-конструкция тестовый элемент
(значение1 форма1)
...
(значениеN формаN)
[(otherwise формаN+1)]


Они отличаются тем, что обычная case-конструкция имеет default clause, а 2 другие: ecase и ccase, — выдают ошибки в случае ненахождения значения тестового элемента в списке возможных. Ограничением этих конструкций является использование для сравнения функции eql (опять же одной из множетсва операций, которые используются для проверки на равенство). Эта функция не работает для строк, поэтому я решил написать собственный вариант case, который бы давал возможность использовать любую функцию сравнения. Например, эта может быть функция, которая проверяет нахождение числа в рамках заданного интервала. Хочу обратить внимание на то, что конструкция gcase объявлена мной совершенно таким же образом, как и оригинальные case-конструкции — а возможность узнать их реализацию, не залезая глубоко в код или описание стандартных библиотек (доступа к которым может и не быть), как это делается в других языках, можно, как правило, просто запустив macroexpand.

(defmacro gcase ((keyform &key (test #'eql)) &body clauses)
"GENERALIZED-CASE -- the difference from simple CASE is that it can
use any given TEST-function. TYPE-ERRORs signaled by TEST-functions are ignored"
(unless (listp clauses) (error "~a -- bad clause in CASE" clauses))
(let ((t-clause? nil))
(when (eql (caar (last clauses)) 'otherwise)
(setf t-clause? t))
`(let ((it ,keyform))
(cond
,@(mapcar #'(lambda (clause)
(if (and t-clause? (eql (car clause) 'otherwise))
`(t ,@(cdr clause))
(w/uniqs (c)
`((handler-case (funcall ,test it ,(car clause))
(type-error (,c) (warn "The value ~a is not of type ~a"
(type-error-datum ,c)
(type-error-expected-type ,c))))
,@(cdr clause)))))
clauses))))) [5]


То же самое касается любых других абстракций. Людям, привыкшим работать в жестко ограниченных языках, не понятно, зачем иметь столько конструкций для циклов: do, dotimes, dolist, loop, …,— к которым могут быть дописаны еще какие-нибудь dotree, domap и т.п. (Хотя многие, наверно, вспомнят, что были рады увидеть, наконец, в C# конструкцию foreach, которой так не хватало в С++). В действии все тот же принцип хорошего стиля — писать все только один раз: во-первых, не нужно копи-пейстить одни и те же шаблоны снова и снова, во-вторых, сразу понятно, какого типа цикл перед нами (а не так, как в С: for (;;)), в-третьих, легко можно уточнить и расширить эти конструкции с помощью инструментов такого же типа (все эти операции циклов — тоже MACRO)...

Почему макро-систем нет в других языках? На самом деле они были и есть: Dylan — это Lisp с С-синтаксисом, metalua и пр. Очевидно, что для поддержки макров язык должен иметь возможность задействовать позднее связывание, но главная проблема остается в другом: разнородности и запутанности синтаксиса — в трудности учета самим программистом всех возможных побочных эффектов “скрытия” каких-то частей кода. Не то, чтобы такая система была не возможна — она, просто, не так практична, потому что появляется необходимость дополнительной трансляции кода между разными представлениями в воображении. А для полноценного использования макров, как показывает даже простой пример вверху, часто не удается ограничиться только одним уровнем вложения макрокода.

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

5. Обещание Lisp’а



Большинство книг и введений в Lisp обещает, что изучив его, программист станет другим, лучшим. Вряд ли это так, потому что никого нельзя изменить при отсутствии собственного желания измениться (и всегда можно будет найти объяснение отсутствию желания, будь то “наличие/отсутствие скобок, переменных, объектов, …”, отсутствие библиотек, необходимость кормить семью…). На самом деле, главное обещание Lisp’а в другом — в том, что человек сможет выражать свои мысли при программировании свободно, в любой принятой им парадигме или вне парадигм без необходимости руководствоваться искуственными ограничениями. Идея, которая стоит за Lisp’ом сегодня — ясность. Но, как и за все остальное, за нее приходится чем-то расплачиваться. И, как по мне, пусть это что-то будет парой лишних скобок... :-)

Сноски:
[1] На самом деле, давайте не будем беспокоиться о Javе. Давайте не жаловаться на Microsoft. Давайте не беспокоиться о них, потому что мы тоже знаем, как программировать компьютеры, и, на самом деле, мы знаем, как делать это мета путем. Мы можем установить альтернативную точку зрения и мы не единственные, кто делает так, как вы хорошо знаете
[2] Есть большая разница между работой с языком, в котором вы должны ждать год, чтобы получить новое выражение для цикла от дизайнера языка и реализатора компилятора — или, когда вы можете сделать это сами за 20 минут
[3] First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
[4] http://www.defmacro.org/ramblings/lisp.html
[5] В этой реализации, конечно, есть не только скобки, но и специфические функции, а также несколько синтаксических элементов (называемых синтаксическим сахаром): ' ` , #' ,@. На самом деле, это практически исчерпывающий список всех подобных элементов в Common Lisp, более того все они имеют свои аналоги в форме (имя ...), т.е., в конце концов, можно ограничиться только скобками и именами.

Дилема зеків на київських дорогах

Написано для: Украинская правда (не опубликовано)
Время написания: январь 2008


Є такий важливий результат теорії ігор — дилема в'язнів.

Коротко, двоє підозрюваних, А і Б, арештовані. У поліції немає достатніх доказів для звинувачення, і ізолювавши їх один від одного, вони пропонують їм одну і ту ж операцію: якщо один свідчить проти іншого, а той зберігає мовчання, то перший звільняється, а другий одержує 10 років в'язниці. Якщо обидва мовчать, у поліції мало доказів, і вони засуджуються до 6 місяців. Якщо обидва свідчать проти один одного, вони одержують по 2 роки. Кожен ув'язнений вибирає, мовчати або свідчити проти іншого. Проте жоден з них не знає точно, що зробить інший. Що відбудеться?

Математично доведено: якщо кожний зі злодіїв буде діяти виключно у своїх (егоїстичних) інтересах, тобто, виражаючись формальною мовою, раціонально, обидва будуть говорити і тому отримають по 2 роки. Чому? Це легко пояснити. Візьмемо одного зі злодіїв. Якщо другий буде говорити, то і йому вигідно те ж саме, бо він отримає тільки 2 роки, а не 10. Якщо ж другий буде мовчати, то і тут вигідно співпрацювати з поліцією, бо замість півроку у в'язниці наш злодій одразу виходить на свободу.

Як бачимо, діючи скоординовано, ці двоє отримали б менший строк, ніж діючи кожний виключно у своїх інтересах. Це пов'язано з тим. що, виражаючись математичною мовою, ця гра — не з нульовою сумою.

Цікаво... А тепер порівняйте це з ситуацією на київських вулицях, особливо під час пробки. Деякі люди, бачачи пробку, думають: "зараз я швиденько прорвуся по порожній зустрічній смузі", "виїду на червоне світло, бо ці бовдури з перпендикулярної вулиці затримались на перехресті більше належного" і так далі. А виходить, що це тіьки погіршує становище. Мабуть, тому, що на кожного хитрого знайдеться ще хитріший, а на кожного зухвалого — ще зухваліший.

Так що, певне — напрошується питання — у більшості киян зеківське світосприйняття? :)

Добре, окрім жартів, чи є вихід з такої ситуації? Ну, як мінімум є 2 виходи: простий і складний. Складний полягає в тому, щоб всім домовитись між собою про певні "правила гри", усні чи письмові, або навіть прийняти закони і створити систему забезпечення їх дотримання.

Є ще простий вихід, який, мабуть, здасться безглуздим хитрому лису, про якого пише Ніко Ланге у своїй статті "Україна не є правовою державою". Справа в тому, що для людей з релігійною (або навіть просто моральною) свідомістю дилеми в'язнів взагалі не існує, бо кожна релігія вчить поводитись по відношенню до оточуючих так, як ви хочете, щоб поводились по відношенню до вас. Це значить, наприклад, пропустити іншого попереду, бо ти хочеш, щоб і тебе пропустили , коли ти поспішаєш; не лізти поперед іншими, бо і тобі не подобається, коли перед тобою влізають... Виявляється, навіть математика говорить, що це, може, й не такий поганий варіант.

2008-07-16

Мысли по поводу ICFPС '08

1. Забавные факты о нашей команде


Изначально наша команда состояла из 4-х человек:
- двоих из Питера: того, кто нас собрал -- Якова Зайцева (lj:iakovz), -- выбравшего Erlang, и его друга с C++
- питонщика из Омска
- меня с Common Lisp
(Более распределенной и полиглотной, наверно, трудно представить. Впрочем, мы считали, что наш основной язык -- Lisp).

В этом составе мы провели тренировку...

Когда началось соревнование, нас было (потенциально) 6: к нам присоединился друг нашего Омского товарища и Эндрю Бейн -- программист на Lisp'е, который искал Lisp'овую команду в списке рассылке.

...А когда мы отправляли, наша готовая программа состояла из 2=х модулей: низкоуровневого на Erlang'е, отвечавшего за маневрирование, написанного Яковом, и моего высокоуровневого для выбора направления. Кроме того, в СКВ была куча C++ кода (не интегрированного с нашим), написанного парнем из Омска, который присоединился последним, в день соревнования. Я не отправлял ее, поскольку мы не знали, что там к чему...

2. Коммуникация


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

Но, что касается нашей пары, с ней тоже произошла забавная история с коммуникацией: в последний вечер мы отлаживали часть Якова во в некотором роде "распределенной" манере: он делал исправление, заводил его в SVN, я забирал его, отправлял через scp на машину с LiveCD, запускал, отлавливал в консоли ошибки, сохранял в текстовый файл, scp назад на свой ноутбук и отправлял Якову по Skype. Она продолжалась, мне кажется, часа 3 и, что интересно, в конце я смог отправить почти работающую программу. :) Это произогло из-за того, что у Якова на работе были какие-то неполадки с интернетом, поэтому он не мог загрузить liveCD, а я оказался настолько тупым, что не подумал запускать клиента по сети...

Но, с точки зрения технической, Skype -- это, реально, практически совершенное решение для коммуникации в распределенных группах.

3. Минимальный набор инструментария


который бы понадобился вам в этом году для участия в составе гео-распределенной команды:
* groupchat
* SCM в сети -- GoogleCode доя нас сработал отлично
* отдельный комп для запуска liveCD

4. Задание


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

5. Чего мне не хватало


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

Вывод:


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

P.S. Наш сабмишн.

2008-07-15

ICFPC '08 Thoughts

1. Funny things about our team


Our team consisted initially of 4 people:
- 2 guys in St.Petersburg: the guy, who've brought us together -- Yakov Zaytsev (lj:iakovz) -- choosing Erlang, and his friend with C++
- a pythonista in Omsk (Siberia, Russia)
- me with Common Lisp
(As distributed and polyglot, as you can get. Though, we consider Lisp to be our main language).

We had a training session with this roster...

When the contest began, there were (potentially) 6 of us: we were joined a friend of our Omsk teammate and Andrew Baine -- a Common Lisp hacker, who asked in the mailing list to join a Common Lisp team.

...And when we submitted, our final program consisted of 2 modules: a low-level Erlang one for maneuvering by Yakov and my high-level part for direction setting. Besides in the SCM there was a heap of C++ code (not integrated with ours), written by the Omsk guy, who appeared last. (I hadn't submit it for we didn't know, what was it all about)...

2. Communication


As for me, our main problem was communication (and, to some extend, leadership -- there was no outstanding authority among us to resolve all the disagreements): we couldn't agree on the division of tasks, so everyone virtually did, what he wanted, except for us with Yakov. Andrew tried to participate, but didn't succeed because of poor communication and big time difference, I think. We were Russian-speaking and prepared together and, moreover, he joined, when we've being already far in the discussion late at night. So, we didn't have enough time, to get him involved in the beginning, and on the next day it was even harder to start for him.

But with our pair it was also a funny story with communication: on the final evening we debugged Yakov's part in a somewhat "distributed" manner: he made a correction to his module, committed it to SVN, I checked it out, scp'ed to the machine with LiveCD, ran, caught errors popping in the console, wrote them to text file, scp'ed back to my notebook and sent to Yakov over Skype. This debugging session lasted for some 3 hours I think, and actually, I was able to submit some half-working code in the end. :) Such situation was caused by Yakov being at work with poor Internet connection, so he couldn't get hold of liveCD, and me being stupid enough not to think of running the client over the net...

But, from the technical viewpoint, Skype, actually, is as close to perfect as you can get for communication in such distributed groups.

3. Minimum set of tools


you would have needed for participating this year with a geo-distributed team:
* groupchat
* SCM on the net -- GoogleCode worked perfectly for us
* a separate PC to run liveCD

4. Task


This year's task is just a kind of a task to give students for their term paper in the course, that teaches basic programming and algorithms. From one perspective, it would teach you most of the things you need to know to start working in a professional group of programmers, and from the other it's sufficiently advanced to really learn something about algorithms. We've also tried the 2004's task -- Ants -- it's also similar in this sense, but is more suited for the Compiler course. Generally speaking, if I was a programming professor, I would have definitely used the materials from all the ICFP contests as such kinds of tasks.

5. What I lacked


I think, for me the best case would have been to have a team of 4-5 people, situated in at most 2 places (and big time difference between them would've been really helpful), and programming in at most 2 different langs, so that everyone had a supporting person to work on the code together. And, it would've been great if everyone knew both languages.

Conclusion:


It was really a great experience, which I'd recommend to try at least once to anyone, who is fond of programming.
...And it's best, when you are in a well-prepared team :)

P.S. Our submission.