Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 1252 Удалено модератором | |
№ 1251 Удалено модератором | |
№ 1250 18-09-2006 16:28 | |
Ответ на »сообщение 1249« (Jack Of Shadows)
___________________________
Вагиф, в начале этой ветки вы пели дифирамбы Лиспу, говорили, что это идеальный язык, а теперь сфокусировались на Хаскеле. Что, приятнее все-таки работать с более человеческим по синтаксису языком? Или вам еще обилие глупых скобок не надоело? :)
№ 1249 18-09-2006 15:17 | |
Ответ на »сообщение 1248« (bb)
___________________________
Нет языка программирования в котором не было бы возможности менять состояние (императивная составляющая)
В это плане чистые ФЯ не отличаются от любых других.
Императивная составляющая существует везде и является неотемлимой частью программирования.
Но вот гарантия того что некая часть программы (Не вся программа а лишь НЕКОТОРАЯ ЕЕ ЧАСТЬ), некие ее модули, некие функции - чистые, без побочных эффектов. Такая гарантия и делает язык чистым ФЯ.
Наскель эту гарантию дает тем что вы не можете смешивать чистый и императивный код.
Функции, меняющие состояние системы (Out), или чей результат зависит от состояния системы (In) помечаются как тип IO.
Если вы попробуете использовать такую функцию в чистой функции то получите ошибку компилятора.
Вам придется явно менять тип возвращаемого значение этой функции и указывать IO.
Вы не сможете использовать эту функцию нигде в коде в правой части выражения (x = myFunction y)
Вам придется все применения этой функции обертывать в монад do
Что влечет за собой дальнейшее "отравление" кода типом IO.
Короче говоря после получасового мудохания, вы проклянете процедурный стиль, и сами просто начнете собирать часть системы, изменяюшую состояние, в отдельные "императивные" островки, пытаясь оставить как можно большую часть кода чистой. Просто потому что с размазанным по коду состоянием работать в хаскле неимоверно трудно.
Настолько трудно, что приходится это дело бросать не закончив.
Вот вам и гарантия того что в хаскеле вам не попадется длиннющая процедура делающая сто разных действий, включая и заваривание кофе :))
То есть императивный код никуда не исчезает. Просто он не размазан по всему коду а собран в компактные отдельные островки.
Вот вам и гарантия того что функция НЕ ПОМЕЧЕННАЯ как IO будет возвращать всегда ОДИН И ТОТ ЖЕ результат на одни и те же параметры, и вас не ждет скрытая подстава.
Попробуйте сами. Есть великолепные книги по хаскелю. Порешайте задачи. Время проведете с удовольствием.
Заодно и на своем опыте убедитесь как просто невозможно переть против насаждаемой хаскелем дисциплины программирования.
№ 1248 18-09-2006 14:57 | |
Ответ на »сообщение 1245« (Jack Of Shadows)
___________________________
Почему именно пять ? Три не устроит ? Haskell, Erlang, Clean
Значит, Haskell - это чистый ФЯ (в понимании purely functional language), т.е. язык, чистота которого заключается в обязательной поддержке функционального программирования и гарантии отсутствия у функций побочных эффектов (side-effect)?
Как Вы прокомментируете тогда следующее высказывание, принадлежащее Jan-Willem Maessen из MIT Laboratory for Computer Science? http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04244.html
В частности, фразу применительно к Haskell You have a choice: write
programs in the beautiful, purely-functional part of the language (in
which case you have to use unstable but widely-known hacks to hide
certain sorts of side effects), or write programs in the much clunkier
monadic sublanguage, where you need to name all your subexpressions,
the order of evaluation is fixed, and you can use as many side effects
as you like.
№ 1247 18-09-2006 14:56 | |
Ответ на »сообщение 1246« (bb)
___________________________
Ссылка не битая. Просто wikipedia лежит :)) Попробуйте через некоторое время.
Не поленюсь повторить вопрос, оставшийся без ответа.
Не поленюсь указать вам еще раз на то что все это уже обсуждалось.
И как рещается взаимодействие чистых ФЯ с внешней средой, и изменение состояния (монады в хаскеле, uniqueness types в Clean)
Повторяться мне не интересно.
А вот дать что то новенькое - это можно.
К вопросу о смешивании парадигм а также о том как на ФЯ выражать то что на ФЯ "не выражается" :))
http://web.engr.oregonstate.edu/~erwig/papers/Zurg_JFP04.pdf
Интересная статья о том как на хаскеле эмулируется логическое программирование.
Дана чисто логическая задача (search problem? домейн являющийся родным для Пролога).
Реализованная на Прологе (исходный код приведен)
А затем дано решение этой же задачи на хаскеле.
Как я уже говорил, я сейчас штудирую книжку по хаскелю. С огромным удовольствием. В сто раз приятнее чем гонять NeverWinter Nights :))
Так вот разобрал пример приведенный в статье, получил массу положительных эмоций. :))
Сейчас я как раз на type classes. Поразительно мощная вешь.
Позволяет полностью эмулировать как ОО так и ЛП
№ 1246 18-09-2006 14:30 | |
Ответ на »сообщение 1245« (Jack Of Shadows)
___________________________
Ну а пока: http://en.wikipedia.org/wiki/Pure_functional_language
Ссылка битая.
Не поленюсь повторить вопрос, оставшийся без ответа.
Есть ли в чистых ФЯ вещи, не выражаемые на самом ФЯ (встроенные, предопределенные средства)? Если имеются, то на чем они реализуются и как это сообразуется с чистотой ФЯ?
№ 1245 18-09-2006 14:14 | |
Ответ на »сообщение 1244« (bb)
___________________________
При этом сколько вы там насчитаете парадигм и как вы их назовете - меня совершенно не волнует.
Тоже подход. Технологическим нигилизмом называется.
Почему нигилизм ? Нигилизм это отрицание. Я же ничего не отрицаю. Меня просто это не интересует.
Найдите того кого интересует классификация и обсуждайте с ним.
Если нетрудно - приведите список из пяти "чистых" ФЯ.
Почему "Ы" ? : ))
Почему именно пять ? Три не устроит ? Haskell, Erlang, Clean
И поясните, что Вы понимаете под чистотой ФЯ (т.е. какие языки и диалекты, причисляемые к ФП относятся по Вашей классификации к "нечистым").
Обсуждалось уже много кратно. Опоздали к банкету - придется вам отматывать тему назад.
Ну а пока: http://en.wikipedia.org/wiki/Pure_functional_language
Кстати я собираюсь поднять еще один интересный вопрос bottom-top approach (FP) vs top-bottom approach (OOP)
Но это когда у меня время появится написать. Там поболее материала будет чем в статье про дисциплину программирования :))
№ 1244 18-09-2006 13:48 | |
Ответ на »сообщение 1243« (Jack Of Shadows)
___________________________
При этом сколько вы там насчитаете парадигм и как вы их назовете - меня совершенно не волнует.
Тоже подход. Технологическим нигилизмом называется.
Меня интересует вот эта вот гарантия, что мне не придется в очередной раз разбирать гордиев узел тысяч переменных, процедур, циклов, в тщетной попытке понять и исправить.
Т.е. меняем шило на мыло: вместо признания возможности (и целесообразности) использования в одном проекте (не говоря уже о языке) разных парадигм говорим о чистом ФЯ, подразумевая, что все рамками этой чистоты есть грязь.
Если нетрудно - приведите список из пяти "чистых" ФЯ. И поясните, что Вы понимаете под чистотой ФЯ (т.е. какие языки и диалекты, причисляемые к ФП относятся по Вашей классификации к "нечистым").
Есть ли в чистых ФЯ вещи, не выражаемые на самом ФЯ (встроенные, предопределенные средства)? Если имеются, то на чем они реализуются и как это сообразуется с чистотой ФЯ?
№ 1243 18-09-2006 13:24 | |
Ответ на »сообщение 1241« (bb)
___________________________
Как вы это собираетесь обеспечивать ?
Задавая этот вопрос я имел в виду конечно взаимодействие разных программистов (в команде или просто используя разные библиотеки от других программистов)
Ваш экскурс в классификацию разных парадигм и возможность их смешивания или сосуществования меня не интересует. Вполне может быть интересная тема, но во первых офтопик здесь, и во вторых никакого практического интереса для меня не представляет.
Я обсуждаю вопрос дисциплины программирования только лишь как одно из достоинств чистого функционального подхода.
В императивных ОО языках нет никакого ограничителя, который не пускал бы программиста писать длиннющие процедуры в несколько тысяч строк с тысячами переплевшихся друг другом локальных и глобальных переменных, с десятками циклов, как вложенных так и идущих один за другим.
Такой код быстро превращается в непроходимые джунгли. Любая попытка чего то там изменить или добавить приводит к размножению ошибок.
При этом время, требуемое для того чтобы прочитать этот код и понять че он там делает - превышает все мыслимые пределы.
В отличие от ОО языков - чистый ФЯ не дает такой возможности.
Нет оператора присваивания. Это значит невозможно повторно использовать локальные переменные.
Нет цикла. Это означает что любую циклическую обработку данных приходится оформлять в виде отдельной рекурсивной функции.
Поскольку функции рекурсивые, чистые, и не могут изменять значения локальных переменных, это значит любое взаимодействие между ними должно происходить ТОЛЬКО путем передачи параметров и возвращения результата.
То есть ГАРАНТИРУЕТСЯ соблюдение контракта, соблюдение интерфейса.
То что в мире ОО держится только на честном пионэрском слове программиста.
Гарантируется упрятывание локальных, промежуточных результатов на соответствующем им уровне абстакции, вместо того чтобы захламлять код программы повсеместно. То есть гарантируется инкапсуляция.
При этом сколько вы там насчитаете парадигм и как вы их назовете - меня совершенно не волнует.
Меня интересует вот эта вот гарантия, что мне не придется в очередной раз разбирать гордиев узел тысяч переменных, процедур, циклов, в тщетной попытке понять и исправить.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|