Ответ на »сообщение 2229« (Илья Ермаков)
___________________________
Когда мы не может сразу выразить вычисления в виде одного выражения, почему бы не расписать их пошагово? 
Действительно почему бы ?
Где вы видели функциональныя код в одну длинную строчку ?
Мы тоже разбиваем сложные выражения на более простые, написанные на отдельных строчках.
Только если вы для этого используете опреатор присваивания, мы используем декоарацию выражений.
Но и в том и в другом случае это таже самая декомпозиция выражений на более простые и понятные для чтения.
И присваивания для этого не обязательны.


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

Не надо делать над собой никаких усилий. Раскручивайте подробности на бумаге.
Никто не застваляет вас писать

qsort (x:xs) = (qsort (filter (<x) xs)) ++ [x] ++ (qsort (filter (>x) xs))

Пишите

qsort (x:xs) = lesser ++ middle ++ greater
  where lesser = qsort (filter (<x) xs)
        greater = qsort (filter (<x) xs)
        middle = (filter (==x) xs)

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

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

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

пожалуйста иллюстрируйте иначе это читается как hype и ничего больше.

См. Блэкбокс.


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

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

пожалуйста иллюстрируйте иначе это читается как hype и ничего больше.

См. Блэкбокс.

точно так же, как если я скажу что хаскелл - сверх-высокоуровневый язык и не покажу никаких примеров. вы поверите? ;)

Я-то не поверю... 8)))
Потому как и математику знаю, и как работается на ФЯ -- тоже...

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

Ответ на »сообщение 2224« (Илья Ермаков)
___________________________
Это не "мусор", это избыточность, требующаяся для читабельности и большей надежности. В технике избыточность, дублирование является одним из средств повышения надежности.
Это дейстительно избыточность. Однако к читабельности, и уж тем более к большее надежности (чаго ?!!!) она вообще никакого отношения не имеет.
Эта избыточность требовалась 30-40 лет назад, для обеспечения экономии жутко дорогих железных ресурсов.

Всё это многократные повторения одного и того же...
Info21 вставил не так давно верное замечание о мифе относительно большей абстрактности и математичности ФП и задал риторический вопрос "Почему нужно считать функцию более математической концепцией, нежели концепцию оператора, если имеются матетические формализмы Дейскстры для операторной нотации".
А по поводу "избыточности"... При чем тут, в конечном счете, экономия ресурсов?
Лично для меня это один из видов декомпозиции задачи. Когда мы не можем что-то сделать в уме, мы явно выписываем промежуточные результаты на листке бумаги, разве не так?
Когда мы не может сразу выразить вычисления в виде одного выражения, почему бы не расписать их пошагово? Любая математическая теорема представляет собой такое же пошаговое преобразование, с запоминанием промежуточных результатов, с выполнением действий по преобразованию. Можно, конечно, отказаться от этой пошаговости - и записать все преобразования в одну строку, но для чего?
У меня, например, не математический склад ума, мне сложно воспринимать математический вывод, громоздкие формулы - приходится делать над собой усилие, раскручивать с подробностями на бумажке и т.п.
И точно так же мне сложно воспринимать функциональную программу. Да, это очень изящно и красиво! Но я не представляю, как можно заворачивать единые выражения большой сложности и вложенности без предварительного их вывода по кусочкам "на бумажке". И зачем мне это надо? Выкинуть бумажку, записать красивый и лаконичный результат, а через полгода вспоминать, как он был получен? Я лучше проделаю ту же декомпозицию явно в программе.

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

Ответ на »сообщение 2224« (Илья Ермаков)
Вот современные императивные программисты и напоминают таких вот обезьян, которые уже давно не испытывают никаких недостатков в компьютерных рессурсах, но по прежнему рьяно эти рессурсы берегут.
При этом даже изначальную причину позабыли и заменили ее на новую молитву, про читабельность и большую (хаха) надежность.

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

А вот в системном ПО это далеко не все равно. Вам ведь не все равно, сожрет ОС у вас 64-128 мб памяти или все 512? Системное ПО - это не раз, не на один запуск, не на один расчет... Это то, что работает все время резидентно, и от того, насколько быстро оно работает, зависит, сколько процентов системных ресурсов достанется вашему интерпретатору Хаскелла для обсчета прикладной задачи.
Не говоря о встроенных системах, где есть большая разница - поставить один процессор, или десять... А если оборонка, то есть еще разница - поставить свой процессор, который на порядок помедленней ,и выиграть на быстром и компактном софте, или ставить забугорный с закладками :-)

Ответ на »сообщение 2224« (Илья Ермаков)
___________________________
Это не "мусор", это избыточность, требующаяся для читабельности и большей надежности. В технике избыточность, дублирование является одним из средств повышения надежности.
Это дейстительно избыточность. Однако к читабельности, и уж тем более к большее надежности (чаго ?!!!) она вообще никакого отношения не имеет.
Эта избыточность требовалась 30-40 лет назад, для обеспечения экономии жутко дорогих железных ресурсов.
Сегодня такой необходимости нет. Но жертвопрношения мертвому богу по прежнему приносятся.

Мне это напоминает эксперимент с обезьянами.
В клетке 5 обезьян. Опускают банан. Как только кто нибудь из обезьян пытается схватить банан - всех бьет током. В результате очень скоро они смирненько сидят и банан не трогают.
Затем одну из обезьян меняют на новенькую. А как только опускают в клетку банан она конечно пытается схватить, и тут же остальные 4 обезьяны накидываются на нее и начинают бить.
Естественно новая обезьяна тоже теперь "научена".
Постепенно заменяют всех обезьян и отключают ток.

Ни одна из новых обезьян НИКОГДА не испытывала электрического шока. Ни одна не знает, почему нельзя трогать банан. Но все исправно бьют любого кто попытается к банану притронуться.

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

Ответ на »сообщение 2216« (AVC)
___________________________
Deep-версии популярных шахматных программ давали на 2-ядерном процессоре прирост быстродействия 80%.

Ну это смотря в какую сторону роценты считать. :)) .Я посчитал не убыстрение а уменьшение времени исполнения.
То есть заявленные 40% уменьшения времени выполнения это и есть 80% убыстрения. Все сходится.

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

Ни фига се!! У вас еще наглости хватает сравнивать переделку кода с заменой модулей ? :))
К вашему сведению более 90% императивных программистов подобная переделка (без ошибок) не под силам.
Так что как ни старайтесь принижать а выигрыш в облегчении распараллеливания все таки колоссальный.
Выигрыш именно для масс программистов, а не для конкретных личностей которым видите ли раз плюнуть "шедулер написать" :))

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

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

во-первых, синт. мусор и объявление типов - разные вещи :) в данном случае мусор - это procedure, begin, end, if, then, else. запись без них гораздо лаконичней и что главное - поощряет разбиение алгоритма программы на крошечные, в несколько строчек процедуры, делая её логику более очевидной

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

вывод типов - свойство всех языков-наследников ML (т.е. практически всех используемых нынче ФП языков со статистической типизацией - sml,ocaml,f#,haskell,clean,mercury) и в последнее время он стал заимствоваться императивными языками - C# 3.0 поддерживает его на локальном уровне. вывод типов однако несовместим (или плохо совместим) с наследованием в стиле ООП, неограниченной перегрузкой имён, автоматическими преобразованиями типов - вместо них в хаскеле используются type classes, а все преобразования типов (скажем, Int->Double) делаются только вручную: нельзя написать i+d, только (fromIntegral i)+d

ml-derived языки поддерживают объявления типов - можно описать тип функции, можно вообще "заказать" тип любого выражения :)  при отсутствии же этих объявлений будет выведен наиболее общий тип, соответсвующий использованным операциям. к примеру, мы можем определить тип fac явно:

fac :: Integer -> Integer

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

double (x::Int) = 2*x

компилятор сообразит, что тип результата тоже x, и выведет объявление double как

double :: Int -> Int

если же типов не задавать, то в обоих случаях компилятор автоматом определит, что тип результата совпадае с типом аргумента, и что аргумент должен принадлежать классу чисел Num (то есть быть Int, Integer, Double, Int64 или что-то ещё из этой серии). если автоматом выведенный тип записать явно, то он будет выглядеть как

fac :: Num a =>  a -> a

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

qsort :: Ord a =>  [a] -> [a]
qsort [] = []
qsort (x:xs) = qsort lesser ++ [x] ++ qsort greater
  where (lesser, greater) = partition (<x) xs

типы внутренних величин lesser, greater и анонимной функции (<x) при этом не указываются. опять же подчеркну, что этот явно запсианный тип в точности соответсвует тому, что был бы выведен автоматически. хотя при желании можно сделать фукнцию менее generic, задав явный тип элментов списка:

qsort :: [String] -> [String]



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

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

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


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

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

Ответ на »сообщение 2206« (AVC)
___________________________
думаю, здесь хорошо видно, за счёт чего получается экономия - нет синтакс. мусора, типы выводятся автоматически. по сути дела, никаких особенностей именно *функционального* программирования и не используется

Это не "мусор", это избыточность, требующаяся для читабельности и большей надежности. В технике избыточность, дублирование является одним из средств повышения надежности.
Да, язык должен заставлять программиста явно дублировать информацию, например, о типе, т.к. это оберегает во многих случаях от трудноуловимых ошибок. Про нестрогую типизацию с неявными преобразованиями вообще молчу, но даже автовывод типов - не особо нужное, но опасное "умничанье" компилятора. Автоконтроль лучше автовывода...
И еще - большую часть времени программист "серьезных" областей проводит за чтением кода - своего и чужого (в отличие от массового программиста, который, перефразируя студенческую присказку, на "три З": "з"делал,"з"дал",забыл), поэтому избыточность просто необходима.
Она, межлду прочим, именно что позволяет не комментировать каждую строку кода.
Мне пришлось и приходится очень много копаться в чужом коде на Обероне ("нутро" Блэкбокса) - швейцарцы комментировали код очень-очень скупо. Однако при этом, из-за однозначности и простоты языка и наглядности синтаксиса, я ни на каком другом языке не читал код так легко..
Даже на других паскалеподобных. В той же Дельфе язык более "размазанный" и нет единого стандарта на запись/оформление кода. В Обероне код оформляется унифицированно, т.е. индивидуальным "закидонам" программиста там просто негде развернуться, индивидуальный стиль оформления практически отсутствует как явление...

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

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

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

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

пожалуйста иллюстрируйте, иначе это читается как hype и ничего больше. точно так же, как если я скажу что хаскелл - сверх-высокоуровневый язык и не покажу никаких примеров. вы поверите? ;)