Ответ на »сообщение 2200« (Сергей Перовский)
___________________________

Для меня все это именно фокусы: вполне симпатичные но совершенно не обязательные возможности. ... приятные мелочи.

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

Ответ на »сообщение 2217« (Булат Зиганшин)
___________________________

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

... нет синтакс. мусора, типы выводятся автоматически.

А если при выводе типа программист -- а вслед за ним компилятор -- ошибется дважды?
Мало не покажется.

Синтаксический "мусор" -- нужный, в т.ч. для явных объявлений типов -- средство экспликации.

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

Точно такого же? Сильно сомневаюсь. Точнее, знаю наверняка, что гораздо меньшего.

И проблема согласованности комментариев и текста тоже никуда не уходит. А это -- реальная промблема.

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

поэмы красивее тяжеловесных романов.

Отнюдь не факт ... depends.
Не все романы тяжеловесны, даже толстые.

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

Т.е. по всей программе "разгуливает" структура неизвестного размера

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

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

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

compressData = do createArchive
                  addData
                  closeArchive

и compressData вызывается с использованием монад UI и Error, то этот код на внутреннем языке компилятора будет выглядеть как

compressData UI Error = do createArchive UI Error
                          addData UI Error
                          closeArchive UI Error

и такая же трансляция будет предпринята для всех монадических операций (процедур), вызхываемых внутри этих createArchive/... подчеркну - это очень поверхностное описание, гораздо лучше это описано в http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html

сам компилятор ghc написан именно таким образом. как результат - его удалось легко распараллелить (насколько я в курсе, для gcc о подобном и не помышляют :) правда при этом выигрыш afair составил всего 15%

в ghc есть, например, монады, генерящие уникальные имена, запоминающие генерируемый код (это когда в процессе генерации тела одной процедуры вдруг решили создать ещё одну, вспомогательную) и многие другие

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

Ответ на »сообщение 2202« (Булат Зиганшин)
___________________________

>>>я ниже писал - передавать целиком состояние мира в виде структуры.

Очень интересно.
Т.е. по всей программе "разгуливает" структура неизвестного размера (да и неясного содержания), а учитывая строгости ФП -- скорее всего, несколько ее копий.
Если это то, что я подумал (я мог понять неверно), то у нас с Вами разные представления о модульности (в данном контексте -- разбиении программы на части с минимизацией связей (coupling) между частями).

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

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

вообще, мне кажется, вы судите о порблемах ФП, примеривая его на выразительные средства Оберона, а они по своременным меркам весьма узки. нет polymorphic programming, type constructors, type inheritance. к примеру, заголовк процедуры, читающей оглавление архива, у меня выглядит так:

-- |Прочитать каталог, записанный функцией `archiveWriteDir`
archiveReadDir arc_basedir  -- базовый каталог в архиве
              disk_basedir  -- базовый каталог на диске
              archive      -- файл архива
              arcpos        -- позиция в архиве, где начинается этот каталог
              filter_f      -- предикат фильтрации файлов
              receiveBuf    -- "(buf,size) <- receiveBuf" получает для работы очередной буфер размером `size`

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

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

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


а как ты надеялся прочитать программу на незнакомом языке, да ещё и с незнакомой паралигмой программирования? :)

давай сравним элементарный код:

function fac (n:integer) : integer;
begin
  if n=0
    then Result:=1
    else Result:=n*fac(n-1)
end

и

fac n = if n==0
          then 1
          else n*fac(n-1)

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


вот другой пример - поиск в строке последнего пробела до 80-й позиции:
last_space = last . findIndices (==' ') . take 80

вот она уже существенно использует ФП стиль.

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

-- Подготовить список замен к использованию в lookup
prepareSubsts x = x
    -- Удалить пустые строки, пробелы и комментарии
    .$ map (filter (not.isSpace) . fst . split2 ';') .$ filter (not.null)
    -- Заменить каждую строку с символом # на 9 строк, где # пробегает значения от 1 до 9
    .$ concatMap (\s -> map (\d->replace '#' d s) ['1'..'9'])
    -- Преобразовать список строк вида "a=b" в список для lookup
    .$ map (split2 '=')

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

Ответ на »сообщение 2215« (Jack Of Shadows)
___________________________

>>>А вот и первые ласточки преимущества ФЯ в автоматическом распараллеливании:

Цифры (пока!) не очень впечатляют.
Насколько я помню (и если реклама не врет :) ), Deep-версии популярных шахматных программ давали на 2-ядерном процессоре прирост быстродействия 80%. Очень сомневаюсь, что они пишутся на ФЯ.
Но все равно очень интересно. Спасибо!

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

А вот и первые ласточки преимущества ФЯ в автоматическом распараллеливании:
http://cs.hubfs.net/blogs/tomasp/archive/2007/03/25/fsharp_parallel_ops.aspx
F# библиотека для распараллеливания работы со списками.
Пока в ней только 2 функции filter и map. 
Убыстрение на 2-ядерном процессоре функции нахождения prime numbers, гле то в 40%
Причем разница в коде только в импортируемом модуле. Вместо модуля List импортируется модуль ParallelList.
Сравните это с изменениями которые придется делать в императивной программе для распараллеливания.
Кстати по оценкам экспертов, через 4-5 лет большщинство продаваемых компьютеров будет иметь 16 и больше ядер.
Так что подобные функциональные библиотеки придутся как нельзя кстати.

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

Прошу прощения за отсутствие разделения между цитатой и собственным текстом. :(
Мой ответ начинается со слова "спасибо". :)

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

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


Кстати, о криптограммах. :о))
Почитайте, если найдёте время, мою статью с расписанной по пунктам программой - решением задачки с ACM ICPC 2007.
Не знаю, почему Вы так не любите Хаскелл, но надеюсь, что Ваше мнение о нём изменится...

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

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

По поводу же преимуществ Оберона/КП, они, IMHO, в основном все-таки лежат в системной сфере; не обязательно системного ПО, а программ, функционирующих как системы, с изменением состояний (так в жизни!), накоплением информации, изменением и расширением модульного состава "на лету".