Протоколы, сообщения: что дает паттерн-матчинг? - Декларативное программирование

VD>1. Это неверный код. Он пропутит список содержащий более одного элемента.
Точно. Но где проверка на Length в коде на, кажется, Nemerle?

VD>2. За программирование на исключениях надо отдельно морду бить.
Можно ведь и в ответ получить.

А так код, состоящий из большого числа вложенных if-ов, проверяющих, в основном, на null, неплохо ложится на try catch.

VD>Обоенно этот стиль хорош в отладке. Никогда не знаешь глючит программа или исключения летят шатно.
Это затрудняет поиск места ошибки только для минимального catch блока.

catch(Exception e) {log(e);}
...
void log(Exception e)
{
#if DEBUG then
  logger.log(e);
#endif
}

VD>О скорости тут и говорить не приходится.
Сомневаюсь, что выброс NullReferenceException сильно тормозит программу.
Может обращение по нулевому адресу вообще отрабатывается на уровне процессора или операционной системы.

VD>3. Ну, и главное. Все равно получается 7 строк кода вместо двух.
Стилем форматирования, можно смело сократить до 5 строк.

VD>И опять же их прийдется распознавать, а не читать. В этих приведениях типов черт ногу сломит.
А если бы в c# было бы автоматическое приведение

try {
  PExpr.Sequence seq = pBody;
  PExpr.Literal lit = seq.body.Head;
  PExpr expr = MakeStringTemplateExpr(lit.val, lit.Location, ctx);
} catch (NullReferenceException) {}

как в VB?

Я к тому, что тут больше влияет в предпочтении — matching или вывод типов?

Здравствуйте, <Аноним>, Вы писали:

VD>>1. Это неверный код. Он пропутит список содержащий более одного элемента.
А>Точно. Но где проверка на Length в коде на, кажется, Nemerle?

А, приглядись внимательно:

PExpr.Sequence([PExpr.Literal(Literal.String(str)) as lit])

Видишь PExpr.Literal окружен в скобки? Это паттерн списка состоящего из одно элемента. Паттерны соответствуют коду конструирования. Так что если мы можем создать список:

def lst = [1];

то може точно так же его распознать:

| [1] => ...

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

| [var] => // значение элемента доступно через переменную var.

если нам значене не важно, а важен сам факт распознования списка с одим элементом, то мы можем заменить переменную подстановочным знаком (wildcard-ом).
Можно распозновать список с любым количеством значений. Например, с тремя:

| [first, _, end] => first + end

А можно использовать оператор конкатенации списов. Тогда вообще можно распознавать списки которые содержат нечто важное для нас в начеле списка:

| first :: second :: tail => // first и second - это значения первого и второго элемента списка
                             // а tail - это отсаток (хвост) списка.

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

Отличный список примеров паттерн-матчинга списков можно найти в реализации самого списка:
http://nemerle.org/svn/nemerle/trunk/lib/list.n

VD>>2. За программирование на исключениях надо отдельно морду бить.
А>Можно ведь и в ответ получить.

А нам то за что? (с) акнекдот.

А>А так код, состоящий из большого числа вложенных if-ов, проверяющих, в основном, на null, неплохо ложится на try catch.

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

.

А>Это затрудняет поиск места ошибки только для минимального catch блока.

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

VD>>О скорости тут и говорить не приходится.
А>Сомневаюсь, что выброс NullReferenceException сильно тормозит программу.

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

А>Может обращение по нулевому адресу вообще отрабатывается на уровне процессора или операционной системы.

А ты думашь, что в ОС SEH бесплатен? Ты глубого ошибашся.

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

VD>>3. Ну, и главное. Все равно получается 7 строк кода вместо двух.
А>Стилем форматирования, можно смело сократить до 5 строк.

А>А если бы в c# было бы автоматическое приведение

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

А>

А>try {
А>  PExpr.Sequence seq = pBody;
А>  PExpr.Literal lit = seq.body.Head;
А>  PExpr expr = MakeStringTemplateExpr(lit.val, lit.Location, ctx);
А>} catch (NullReferenceException) {}
А>

А>как в VB?

Ну, и гляди на результат. 5 строк вместо одной. И море геморроя при отладке и сопровождении. Ну, и нафига козе боян?

А>Я к тому, что тут больше влияет в предпочтении — matching или вывод типов?

Причем тут вывод типов?

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:
VD>Видишь PExpr.Literal окружен в скобки? Это паттерн списка состоящего из одно элемента. Паттерны соответствуют коду конструирования. Так что если мы можем создать список:
Для Length подошло, а если надо было бы вызвать какой-либо другой метод или свойство?
Типа seq.body.GoodHeadCount == 5? В нижеприведенном примере, seq.body.Length == 1 легко заменяется на такую конструкцию.

VD>Это тихий ужас в больших проектах. Исключения мало чем отличаются от goto. Они точно так е делают программу запутанной и не структурной.
Спорно, что более запутанно, куча вложенных if-ов или обертка в виде try catch над последовательностью предложений.
При этом понятно, что множество if-ов более строго отрабатывают логику.

VD>Как минимум — это превращается в создание нового объекта (и не одного) и раскрутке стка. Если исключений мало, то оверхэд не заметен. Но если лепить на них логику пробграммы, то он неизбежно вылезет.
Достаточно оптимизации компилятора, который при пустом catch блоке не будет разматывать стек, а объект исключения будет "создавать" из пула, или, вообще, не будет создавать.

VD>А ты думашь, что в ОС SEH бесплатен? Ты глубого ошибашся.
SEH не знаю, но NullReferenceException можно (не утверждаю, что сделано) сделать бесплатным.

VD>То его можно было бы отправить в помойку, так как он мало чем бы отличался от любого другого скрипта.
VD>Причем тут вывод типов?
Я тут имел ввиду вывод типа на основе имеющихся данных о типе в правой части выражения.
То есть as не надо использовать, а код оставается типизированным.

VD>Ну, и гляди на результат. 5 строк вместо одной. И море геморроя при отладке и сопровождении. Ну, и нафига козе боян?

Ладно заменим на такой код:

PExpr.Sequence seq = pBody; PExpr.Literal lit = null; Literal.String strLit = null;
if (seq != null && seq.body.Length == 1 && (lit = seq.body.Head) != null && lit != null && (strLit = lit.val) != null)
{    
    PExpr expr = MakeStringTemplateExpr(strLit.val, lit.Location, ctx);
}

Четыре строки вместо двух (причем две это просто фигурные скобки)

Даже если добавить as код не сильно вырастет (и будет работоспособен в С#), к тому же можно использовать alias'ы для внутренних классов.
Идущие на одной строке определения переменных, тоже могут служить сигналом, что последующая переменная определяется из предыдущей.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gajdalager, Вы писали:

G>>А теперь попробуем добавить новое сообщение. В ООП варианте это проще — нужно просто заимплементить интерфейс, в обработчики изменения вносить не нужно. В ПМ-варианте же нужно вносить изменения во все матчеры.

VD>Поясни, плиз, чем отличается добавление реализации метода от добавления case-а?
Количеством файлов, которые нужно править?

VD>И там и там тебе прийдется добавить обработчик. И там, и там компилятор тыкнет тебя носом в место где нужно добавить код. Причем если ты зохочешь, то сможешь сделать обработчик по-умолчанию который будет обрабатывать не обработаные сообщения.
Конечно, но менять нужно все матчеры, которых может быть много и в разных файлах. Если абстрагироваться, то у нас есть 2 варианта групировки реакций конкретных матчеров на конкретные сообщения: по сообщениях и по обработчиках. В одних случаях лучше так, в других по иному. А обработчик по дефолту, это да, жирный плюс.

VD>На мой взгляд ты ошибашся на счет простоты. Код на Яве уже значительно больше, сложнее и непонятнее. Этого уже достаточно чтобы не писать так.
Можно писать так и на Скале, код покороче будет.

VD>Так что единственная предпосылка против паттерн-матчинга — это возможность обработки сообщений во внешних модулях при словии изменения списка сообщений. Вот тут конечно паттерн-матчинг никуда не годен. Он создает жесткую связь с конкретной версией "сервера". При изменении сервера прийдется перекомпилировать и всех клиентов. Вот только решение на Яве тут ничем не отличается.
Думаю, что не единственная, хотя, конечно, могу ошибаться, т.к. не имею достаточного опыта работы с ПМ. Просто не бывает так, чтобы у решения был единственный недостаток или их вовсе не было

<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Чур — Сура

Здравствуйте, VladD2, Вы писали:

VD>А вообще, глупейший разговор. eao197 ищет себе оправдание на тему почему нужно использовать убогие D, C++ и Руби на основнии того, что паттерн-матчинг не панацеия и имеет свои собоеннсоти использования, а все ему в этом помогают.

Я не заметил оправданий насчет D, C++ и Ruby в этом топике

Он задал конкретный вопрос по Скале (и, в общем то, по Н, как языку-двойняшке). Вот он:

Интересны преимущества именно по отношению к гибридным языкам, вроде Scala, где есть "обычное" ООП (поскольку, если я правильно понимаю, в более фунциональных языках, вроде Erlang и Haskell, ситуация будет/может выглядеть иначе).

ЗЫ

У вас, ребята, интереснейшие дискуссии, до тех пор, пока вы не начинаете один на одного бочку катить

<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Чур — Kуяба (Instrumental)

Здравствуйте, Аноним, Вы писали:

Еще меньше

PExpr.Sequence seq = pBody; PExpr.Literal lit = null; Literal.String strLit = null;
if (seq != null && seq.body.Length == 1 && (lit = seq.body.Head) != null && (strLit = lit.val) != null)
{    
    PExpr expr = MakeStringTemplateExpr(strLit.val, lit.Location, ctx);
}

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

PExpr.Sequence seq = pBody; PExpr.Literal lit = null; Literal.String strLit = null;
ifnonull(seq.body.Length == 1 && (strLit = (lit = seq.body.Head).val))
{    
    PExpr expr = MakeStringTemplateExpr(strLit.val, lit.Location, ctx);
}

Здравствуйте, <Аноним>, Вы писали:

А>Ладно заменим на такой код:
А>

А>PExpr.Sequence seq = pBody; PExpr.Literal lit = null; Literal.String strLit = null;
А>if (seq != null && seq.body.Length == 1 && (lit = seq.body.Head) != null && lit != null && (strLit = lit.val) != null)
А>{    
А>    PExpr expr = MakeStringTemplateExpr(strLit.val, lit.Location, ctx);
А>}
А>

А>Четыре строки вместо двух (причем две это просто фигурные скобки)

Лучше на такой и заметь, 1 строка вместо 2

PExpr.Sequence seq = pBody; PExpr.Literal lit = null; Literal.String strLit = null;if (seq != null && seq.body.Length == 1 && (lit = seq.body.Head) != null && lit != null && (strLit = lit.val) != null) PExpr expr = MakeStringTemplateExpr(strLit.val, lit.Location, ctx);

А если серьезно, то неужели ты полагаешь, что код сжатый (не упрощенный, а именно сжатый) до 1-2 строк легче читать, чем тот же код, но записанный в несколько строк

, боюсь, что бить по пальцам за такое будут не только линейкой

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, rameel, Вы писали:

R>Здравствуйте, <Аноним>, Вы писали:

R>Лучше на такой и заметь, 1 строка вместо 2
Чем лучше? Помимо, что 1 строка вместо 2.
А хуже, например, тем что на мой экран строка не влезает, а остальные примеры влезали.

R>

R>PExpr.Sequence seq = pBody; PExpr.Literal lit = null; Literal.String strLit = null;if (seq != null && seq.body.Length == 1 && (lit = seq.body.Head) != null && lit != null && (strLit = lit.val) != null) PExpr expr = MakeStringTemplateExpr(strLit.val, lit.Location, ctx);
R>

В этом коде одна проверка делается два раза, я уже приводил более короткий код.

R>А если серьезно, то неужели ты полагаешь, что код сжатый (не упрощенный, а именно сжатый) до 1-2 строк легче читать, чем тот же код, но записанный в несколько строк

,
Кажется перепутали адресата вопроса, перечитайте ветку.
Но на всякий случай отвечу — у меня не 1-2, строки, а 5.
Одна строка в коде у пользователя rameel, а две у VladD2

R>боюсь, что бить по пальцам за такое будут не только линейкой

Боюсь, можно и в ответ получить и не линейкой и не по пальцам

Здравствуйте, <Аноним>, Вы писали:

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

Успехов в этом нелегком деле.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Gajdalager, Вы писали:

G>Я не заметил оправданий насчет D, C++ и Ruby в этом топике

Это потому, что они в других "топиках". А эта тема специально создана для укрепления его веры.

G> Он задал конкретный вопрос по Скале

Он и конкретный ответ знал.

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

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

В общем, выражаясь просто мужику нужен или холивар, или поддакивания таких же как он Блабов.

G>У вас, ребята, интереснейшие дискуссии, до тех пор, пока вы не начинаете один на одного бочку катить

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Gajdalager, Вы писали:

VD>>Поясни, плиз, чем отличается добавление реализации метода от добавления case-а?
G>Количеством файлов, которые нужно править?

Что количество файлов? Давай, давай. Развей тему. Покажи примеры.

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

Ты еще о сути вопроса не забыл? Эквивалентом нескольким матчам будет несколько лкассов с несколькими реализациями методов-обработчиков событий. Другими словами — один матч == одному классу.

G> Если абстрагироваться, то у нас есть 2 варианта групировки реакций конкретных матчеров на конкретные сообщения: по сообщениях и по обработчиках. В одних случаях лучше так, в других по иному.

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

G>А обработчик по дефолту, это да, жирный плюс.

А вот это как раз не факт. Обрабочик по умолчанию, к сожалению, прерывает помощь со стороны компилятора. По этому я стараюсь делать их только если мне нужно обработать конкреные значения, а на остальные забить. Если же я делаю полную обработку, то стараюсь не вводить обработчиков по умолчанию. Оно дороже в поддержке выйдет.

VD>>На мой взгляд ты ошибашся на счет простоты. Код на Яве уже значительно больше, сложнее и непонятнее. Этого уже достаточно чтобы не писать так.
G>Можно писать так и на Скале, код покороче будет.

Конечно можно. Можно и по другому от темы уходить. Но если вдуматься, то уходить от темы не конструктивно.

VD>>Так что единственная предпосылка против паттерн-матчинга — это возможность обработки сообщений во внешних модулях при словии изменения списка сообщений. Вот тут конечно паттерн-матчинг никуда не годен. Он создает жесткую связь с конкретной версией "сервера". При изменении сервера прийдется перекомпилировать и всех клиентов. Вот только решение на Яве тут ничем не отличается.
G>Думаю, что не единственная, хотя, конечно, могу ошибаться, т.к. не имею достаточного опыта работы с ПМ. Просто не бывает так, чтобы у решения был единственный недостаток или их вовсе не было

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, <Аноним>, Вы писали:

VD>Ладно. Обсуждать твои споры по поводу очевидных вещей мне удовольствия не составляет.
Обсуждать споры? Обычно обсуждаются доводы в споре.
Впрочем, как угодно.
VD>А когда на развернутый ответ несколько страниц текста получаешь вот такие вот отлупы, то сразу становится понятно, что дискуссия не входила в планы

VD>Не хочешь учиться на чужом опыте, набывай шишки сам.
Шишек можно и в ответ понабивать

Здравствуйте, <Аноним>, Вы писали:

А>Шишек можно и в ответ понабивать

Возмездие черенку грабель? (задумчиво) Что-то в этом есть...

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:

VD>Возмездие черенку грабель? (задумчиво) Что-то в этом есть...
Понабивать шишек, пожелавшему понабивать шишек, хе-хе. Через еще неизвестные грабли.

Здравствуйте, palm mute, Вы писали:

PM>В данном случае достаточно sealed abstract class Msg:
PM>http://www.nabble.com/-scala---compiler-verification-of-exhaustive-matching-t3625118.html
PM>Тогда предупреждения будут.

E>>Чесно говоря, я не вижу возможностей для Scala информировать меня о неполных case в match, т.к. новые case-классы могут быть добавлены уже после компиляции объекта Demo, в другом модуле, другим разработчиком.

PM>В случае sealed базового класса — не могут. И согласись, в случае Посетителя новые сообщения в другом модуле другим разработчиком тоже не добавляются.

Сегодня курил эту тему еще. Вспомнилась такая особенность обработки сообщений в прикладных потоколах: иногда обработка протокола определяется конечным автоматом с несколькими состояниями. В каждом из состояний обрабатывается определенное подмножество сообщений. Например, пусть в протоколе есть сообщения: Handshake <-> HandshakeReply (оба используются в первом состоянии установления сессии), IncomingData <-> IncomingDataReply (используются только в read-only сессии), OutgointData <-> OutgoingDataReply (оба используются только в write-only сессии). Так же возможна read-write сессия, в которой участвуют сообщения IncomingData и OutgoingData.

Если вынести обработку различных состояний в разные методы, то получится, что в соответствующих match-ах используется только часть сообщений:

def stateNegotiating( evt: Message ) = evt match {
  case HandshakeReply() => ...
}

def stateReadOnlySession( evt: Message ) = evt match {
  case IncomingData() => ...
}

def stateWriteOnlySession( evt: Message ) = evt match {
  case OutgoingDataReply() => ...
}

Соответственно, если класс Message объявлен как sealed, то компилятор будет выдавать предупреждения на отсутствие в match остальных case-ов. Что в принципе, заставляет разработчика делать перехват остальных вариантов. Например:

def stateWriteOnlySession( evt: Message ) = evt match {
  case OutgoingDataReply() => ...
  case _ => // Порождение какого-то исключения.
}

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

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

Вот в такой ситуации разработчик, на мой взгляд, поставлен перед дилеммой: либо постоянно получать предупреждения от компилятора (как следствие их игнорирование), либо написание перехватчика, чтобы никто не ругался. В любом из этих вариантов компилятор не может помочь разработчику при добавлении в протокол нового сообщения. Например, SetThroughputInfo, которое помогает установить параметры пропускной способности в write-only или read-write сессиях.

Сразу хочу оговориться, что ситуация довольно редкая. Кроме того, в моей практике переход к новой версии протокола, как правило сопровождается code review существующего кода. Поэтому участки кода, нуждающиеся в сопровождении выявляются и без помощи компилятора. Так что это в большей степени теоритизирование. Для полноты картины, так сказать.

Здравствуйте, eao197, Вы писали:

E>Сразу хочу оговориться, что ситуация довольно редкая. Кроме того, в моей практике переход к новой версии протокола, как правило сопровождается code review существующего кода. Поэтому участки кода, нуждающиеся в сопровождении выявляются и без помощи компилятора. Так что это в большей степени теоритизирование. Для полноты картины, так сказать.

Короче каналы из сингулярити рулят...

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, eao197, Вы писали:

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

Например:

variant MsgGroup1
{
    | Type1 { subMsg : MsgType1; }
    | Type2 { subMsg : MsgType2; }
}

variant MsgType1
{
    | MsgA | MsgB | MsgC
}

variant MsgType2
{
    | MsgA | MsgB
}

match (msg)
{
    | MsgGroup1.Type1(subMsg) => Handler1(subMsg)
    | MsgGroup1.Type2(subMsg) => Handler2(subMsg)
}

Handler1(subMsg : MsgType1) : void
{
    | MsgA => ...
    | MsgB => ...
    | MsgC => ...
}

Handler2(subMsg : MsgType1) : void
{
    | MsgA => ...
    | MsgB => ...
}

Ну, или как варинт обработку можно поместить в одно место:

match (msg)
{
    | MsgGroup1.Type1(MsgA) => ...
    | MsgGroup1.Type1(MsgB) => ...
    | MsgGroup1.Type1(MsgC) => ...
    | MsgGroup1.Type2(MsgA) => ...
    | MsgGroup1.Type2(MsgB) => ...
}

Что касается открытых матчей "_ =>", то это перенос проверок в рантайм, что почти всегда хуже чем проверка компилятором. Как показвает практика основные ошибки зачастую сосредотачиваются в эти самых "_ =>".

... << RSDN@Home 1.2.0 alpha rev. 637>>

От:	VladD2	www.nemerle.org
Дата:	08.05.07 17:28
Оценка:

	От:	Аноним
	Дата:	08.05.07 19:42
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	09.05.07 02:17
Оценка:

	От:	Аноним
	Дата:	09.05.07 10:27
	Оценка:

	От:	Gajdalager
	Дата:	09.05.07 10:33
	Оценка:

От:	rameel	https://github.com/rsdn/CodeJam
Дата:	09.05.07 11:01
Оценка:	34 (1)

От:	eao197	http://eao197.blogspot.com
Дата:	09.05.07 17:26
Оценка:

	От:	WolfHound
	Дата:	10.05.07 09:24
	Оценка:

	От:	aka50
	Дата:	13.05.07 22:11
	Оценка: