Ответ на »сообщение 3275« (Geniepro)
___________________________
Я думаю, что на всех "соревновательных" задачах ФП должно показать себя наилучшим образом, поскольку предполагается пакетный режим работы. По сути все задачи сводятся к написанию функции, преобразующей входной поток данных в выходной. Так устроена инфраструктура проверки.
Проблемы у ФП возникают только на существенно интерактивных задачах. На чемпионатах таких не бывает.

Ответ на »сообщение 3270« (Илья Ермаков)
___________________________

Про краткость кода - а где гарантия, что "мэтры" через год разберутся в своем собственном коде? :-) И какую общественную ценность он будет иметь, если никому кроме "мэтров" не доступен?

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

Но ничего - согласно индексу Tiobe, приведённому Русланом, всего через каких-то пятьсот лет программы будут писаться только на функциональных языках. Это если рост доли ФП сохранится на уровне 0.2 % в год.
С другой сторону, если сохранится другой рост - с 0.6% до 0.8%, то есть на треть каждый год, то получится... То получится, что всего через каких-то 17 лет мы все перейдём на ФП!!! :о))) Попомните моё слово! ;о)


Оберон хорош тем, что на нем так написать НЕЛЬЗЯ. Написать глупо, неверно и т.п. - можно. Написать непонятно - нельзя :-)

Ох не уверен! Для меня Ваша программа отнюдь не очевидна. Что бы разобраться в ней - по-любому думать придётся... :о))


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

Ну как сказать? Что значит - заработало?

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

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

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

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

Ответ на »сообщение 3272« (Geniepro)
___________________________

То, что в ФП нет (изменяемого) состояния - это непонятно откуда появившийся миф.
В ФП, даже чистом, состояние (изменяемое), конечно же, есть! Только оно строго локализуется в параметрах функций (монады по сути - игра с параметрами функций, выглядящая как императивное изменение состояний из-за "синтаксического сахара" Хаскелла) и, соответственно, очень жёстко контролируется.
closures, кстати, тоже вполне чистый функциональный подход.

Можно ли это понимать так, что в ФП состояние имеет тенденцию всплывать на глобальный уровень?
Ведь "изменяемые" параметры функций откуда-то же приходят...

Я не вполне понял мысль о closures.
Насколько я понимаю, если у нас есть closures с присваиваниями, то это вряд ли (чистое) ФП.
Кроме того, ряд императивных языков имел closure-подобные конструкции.
Например, в некоторых вариантах Паскаля можно было вложить одну процедуру в другую и передать ее в качестве параметра в третью, откуда она вызывалась, "помня" о своем лексическом окружении.

Ответ на »сообщение 3270« (Илья Ермаков)
___________________________
>>>Написать непонятно - нельзя :-)
А что такого непонятного?
Как сторонний наблюдатель могу сказать, что читаются оба текста достаточно легко.
Может быть потому, что  Geniepro больше уделил внимания комментариям, но это тоже может характеризовать не только программиста, но и выбранный язык.

Ответ на »сообщение 3266« (Илья Ермаков)
___________________________

И вот - внимание - мне очень-очень интересно, как из такой ситуации будут выкручиваться хацкелисты... Состояний нет, запомнить заранее ответы нельзя, разве что написать программу-генератор константной таблицы, которую потом засунуть в исходник? Или придется функциональщикам применять closures - без состояний никуда :-)

То, что в ФП нет (изменяемого) состояния - это непонятно откуда появившийся миф.
В ФП, даже чистом, состояние (изменяемое), конечно же, есть! Только оно строго локализуется в параметрах функций (монады по сути - игра с параметрами функций, выглядящая как императивное изменение состояний из-за "синтаксического сахара" Хаскелла) и, соответственно, очень жёстко контролируется.
closures, кстати, тоже вполне чистый функциональный подход.

Применительно к Вашему вопросу - думаю, проблем тут особых быть не должно.
Пример - компилятор GHC. Он практически весь написан на Хаскелле, который является чистым ФЯ. Ну, может быть, он компилирует программы не так быстро, как компилятор КП в БлекБоксе, но это больше связано с тем, что в Хаскелле при компиляции приходится очень много времени тратить на вывод типов функций/переменных и на оптимизацию полученного кода (анализ строгости и т.п.)...
Если бы кто-то нашёл желание и время сделать на Хаскелле компилятор Оберона/КП, я думаю, большого проигрыша в скорости не было бы...

Ответ на »сообщение 3269« (Geniepro)
___________________________

Я тут удалил все пустые строки и комментарии к обеим программам и с удовлетворение отметил, что в то время, как моя прога на Хаскелле занимает 102 строки чистого кода, аналогичная программа на КП - 230 строк!

Я бы предложил делать не количественные сравнения, а качественные. Если нужно количество строк, то в КП все может быть в одной строке :) Кроме того, для вещей, заточенных под ФП (та же обработка строк), компактность в Haskell априори должна быть.

Под качественным сравнением мне видится следующее:
1. Выделить алгоритмическую часть кода, отвечающего за функционал решения (без UI-ввода-вывода и инфраструктурной обвязки)
2. Выделить UI (ввод-вывод)
3. Выделить инфраструктурную обвязку (если есть, как-то: спецификации модуля, экспорт-импорт и т.д. и т.п., что поддерживает существование алгоритма в пространстве ОС).

Сопоставить эти части, выделив в алгоритмической части функциональную декомпозицию (процедуры в КП).

Затем коротенько изложить решение на псевдокоде (удобном автору) с указанием каркаса решения и показать, как оно отображается на текст на конкректном языке.

Теперь, что мы хотим в итоге выяснить, кроме получения экспозиции с двумя "экспонатами". Видимо интерес представляют процессы синтеза и анализа:
1. Синтез. Насколько легко можно было прийти к каркасу решения и затем к построению его отображения на язык реализации.
2. Анализ. Сколь легко анализировать текст на языке реализации с точки зрения обратной задачи (реинжиниринга), то бишь построения каркаса решения по тексту на языке.

Эффективность выполнения нас, думаю, интересовать не будет. Для подобных задач это неважно. Это интересно и для одной задачи, но если есть возможность, было бы здорово увидеть аналогичное для других видов задач из ACM-набора. Думаю, что существенной разницы между Delphi и КП на этом программировании-в-малом не будет, поэтому помощь Delphi'стов была бы кстати.

Ответ на »сообщение 3269« (Geniepro)
___________________________
Про краткость кода - а где гарантия, что "мэтры" через год разберутся в своем собственном коде? :-) И какую общественную ценность он будет иметь, если никому кроме "мэтров" не доступен?

Оберон хорош тем, что на нем так написать НЕЛЬЗЯ. Написать глупо, неверно и т.п. - можно. Написать непонятно - нельзя :-)

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

Ответ на »сообщение 3266« (Илья Ермаков)
___________________________

Какое решение понятнее проще - судить сторонним наблюдателям.
На мой взгляд, решение на Хацкеле без поллитра не прочитать :-)

Я тут удалил все пустые строки и комментарии к обеим программам и с удовлетворение отметил, что в то время, как моя прога на Хаскелле занимает 102 строки чистого кода, аналогичная программа на КП - 230 строк!
При этом должен сказать, что если бы за дело взялись настоящие кул-хаскеллеры (ну или хотя бы Вашего уровня), то программа на Хаскелле наверняка уместилась бы в районе 30-40 строк, вот только я бы её точно не понял! :о))

В моей программе я сейчас вижу кучу мест, которые можно было бы упростить/сократить. Одно только дублирование стандартной функции nub самоделкой sieve чего стоит! Да и считывание файла в виде одной строки с последующим разбиением её на список строк по символу CR\LF - тоже оверхед немалый...
Короче, одним словом, в Хаскелле я пока ещё нуб... :о( Потому и учусь, учусь и учусь...

ЗЫ. Я попытался скомпилировать Вашу программу, но у меня не установлены модули Info21olimpIn и Info21olimpOut.
В связи с этим предлагаю пользоваться только стандартными модулями БлекБокса. А то ежели подключить к делу комбинаторы парсеров на Хаскелле (которые хоть и стандартны для GHC и HUGS, но не входят в стандарт Haskell 98), то код на Хаскелле будет ещё компактнее, и нехаскеллерам понять его будет ещё труднее...

Ответ на »сообщение 3266« (Илья Ермаков)
___________________________
Хотя сравнение двух решений показывает и другое - со строками на ФЯ работать легче. Это, конечно, факт.

Ответ на »сообщение 3263« (Руслан Богатырев)
___________________________

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

Приведу ссылку на прогноз экспертов Horasis, который в одной из своих работ упоминал Бертран Мейер, озабоченный местом европейцев в дележе капитала новой сферы производства подобно тому, как мы озабочены нашим местом -- http://www.horasis.com/press_releases_all_4.php

Как видно, к 2015 г. нынешняя тройка лидеров (Индия, Китай, Коста-Рика), махнется местами и вместит Америку (Китай, Индия, США). Россия, Украина и Беларусь будут в 10-ке лучших.

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

Стоит вспомнить про статью Ивана Ильина, написанную почти 80 лет назад: http://www.deming.ru/Statyi/SpasVKach.htm


Верим и знаем: придет час, и Россия восстанет из распада и унижения и начнет эпоху нового расцвета и нового величия. Но возродится она и расцветет лишь после того, как русские люди поймут, что спасение надо искать в качестве!.. Всмотритесь в пути и судьбы России, вдумайтесь в ее крушение и унижение... И вы увидите, что все основные затруднения ее были от объёма и количества.