Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 3252 06-10-2007 03:46 | |
Ответ на »сообщение 3239« (Geniepro)
___________________________
>Асинхронное ООП в моем понимании не сильно отличается от декларатива (то бишь вообще не отличается).
Это вообще поразительное утверждение. Этак можно договориться, что Смоллток - диалект Пролога... :о))
Утверждение про асинхронное ООП следует из »сообщение 3142«.
№ 3251 06-10-2007 03:41 | |
Ответ на »сообщение 3249« (Geniepro)
___________________________
Евгений, спасибо. Очень интересная информация для размышлений.
№ 3250 06-10-2007 03:38 | |
Ответ на »сообщение 3246« (Jack Of Shadows)
___________________________
Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?
Это я увидел? Может быть, все же Евгений? :)
См. »сообщение 3159«:
>Как только вы пришпиливаете функции к данным, вы становитесь заложником этой связки. Если же данные и функции отдельно, то очень легко создавать новые типы данных, и новые функции работы с ними. Не нужно ничего ни к чему привязывать.
А Вы не задумывались над тем, что можно иметь и то, и другое? Отдельно -- пришпиливание процедур (методов) к типам и отдельно -- функции?
Реакция на него Евгения. См. »сообщение 3241«:
Ну так это так и сделано в Хаскелле - классы типов, содержащие в себе методы работы со значениями разных логически схожих типов, и просто функции...
Моя реакция. См. »сообщение 3242«:
Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)? См. »сообщение 3154« и »сообщение 3135«.
Реплика Евгения. См. »сообщение 3243«:
У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...
Ваша реплика. См. »сообщение 3246«:
Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?
Мой вывод: как выясняется, есть пришпиливание и пришпиливание. Одно чистое, другое -- грязное. Но я собственно о чистоте в своей реплике и не заикался... :)
№ 3249 06-10-2007 03:31 | |
Ответ на »сообщение 3244« (Руслан Богатырев)
___________________________
Я имел в виду O'Haskell, OOHaskell. Если делают -- значит, видимо, не хватает.
Делают, как я уже сказал, для забавы, для получения острых ощущений, для проверки на прочность системы типов Хаскелла, да просто что бы получить больший опыт в Хаскелле. Сделали, посмеялись и забыли, ох уж эта академическая элита.... Этими диалектами никто не пользуется...
Не предлагаю убрать монады, просто хочу понять, зачем дублировать императив внутри Хаскеля в том случае, если у Хаскеля появится искусственный ИП-спутник.
Давайте представим, что получится, если убрать имитацию императива из Хаскелла - это do-нотация, в основном. Так как на do-нотации также основан очень популярный и удобный механизм list comprehensions, позволяющий декларативно описывать содержимое списков (которые в Хаскелле являются разновидностью монад), то убирание этого сахара (do-нотации и list comprehensions) чуть-чуть упростит компилятор и заметно понизит удобство использования Хаскелла - придётся вручую писать очень много ненаглядного (э.. в смысле, не имеющего наглядности :о) ) кода. В результате, кто-нибудь просто напишет простейший препроцессор, который реализует и do-нотацию, и list comprehensions. Сейчас этот несложный препроцессор встроен в трансляторы Хаскелла.
Что бы избавиться раз и навсегда от квазиимператива Хаскелла, нужно убрать сами монады. Так как монады в Хаскелле - это просто два класса типов Monad и MonadPlus, то если просто убрать эти два класса, их тут же реализует вручную любой достаточно опытный функциональщик, вместе с тем же препроцессором do-нотации...
Что бы сделать воссоздание монад таким же трудным, неудобным и корявым, как их имитируют в С#, Java и прочих языках, нужно будет избавиться от классов типов, что будет огромнейшим щагом назад, к языкам типа Миранды и ML/O'Caml. Это решение возродит давно забытые (20 лет назад) проблемы с перегрузочным полиморфизмом и статической типизацией с автовыводом типов по алгоритму Хиндли-Милнера. Почитайте статью Корделии Холл и пр. "Type Classes in Haskell" , там описаны те проблемы, которые были просто, элегантно и эффективно решены благодаря классам типов:
- перегрузка операций сравнения на равенство и неравенство;
- перегрузка арифметических операций + - * / и т.д.;
- преобразование значений разных типов в строковое представление.
Этой проблемы нет в динамически типизируемых языках, в императивных языках это реализуется просто, так как там нет автовывода типов по Хиндли-Милнеру, в ООП своя система перегрузочного полиморфизма, которую к ФП не пришлёпаешь. Так что до классов типов в языках вроде Миранды и ML приходилось иметь на каждый числовой тип свои собственные обозначения арифметических операций (ML) или просто ограничившись одним-единственным числовым типом (Миранда)... Короче, классы типов позволили просто и ясно решить эту проблему.
Так и что же получается? Стоит ли ради сомнительного удовольствия ограничить Хаскелл чисто функционально-декларативными возможностями убирать такую фундаментальную для Хаскелла вещь, как его систему типов, введя в него старые нелогичные попытки вроде ML-ных? Не знаю, что за мёртворождённый кадаврик это получится, но уж точно это не будет Хаскеллом, лабораторией типов...
№ 3248 06-10-2007 03:03 | |
Ответ на »сообщение 3236« (Илья Ермаков)
___________________________
Т.е. циклом while вы пользоваться не умеете. Только рассуждаете о том, какой он правильный. Так и запишем.
№ 3247 06-10-2007 02:30 | |
Ответ на »сообщение 3238« (Geniepro)
___________________________
Евгений, спасибо за комментарий и ссылки. Сделал себе несколько закладок в браузере. :)
№ 3246 05-10-2007 16:17 | |
Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?
Функции описанные в type classes все также принимают значения через параметры и все также возвращают новое значение, ничего ни в каком контейнере не меняя.
писывая тип как принадлежащий к каому то классу, вы всего лишь даете знать что функции в этом классе будут принимать параметры этого типа. Естественно для вашего нового типа эти функции придется переопределить, когда вы описываете свой новый тип как instance какого то класса типов.
Ближайшим аналогом type classes в ОО наверное будут интерфейсы.
Таким образом описание типа данных и соответствующих ему функций преобразования совершенно не обязательно сопровождается запихиванием всего этого в контейнер, в котором также и состояние хранится.
Состояние отдельно - типы данных и их функции, отдельно.
№ 3245 05-10-2007 15:57 | |
Ответ на »сообщение 3240« (Geniepro)
___________________________
Ответ на »сообщение 3153« (Евгений Непомнящий)
___________________________
Пролог, кстати, не имеет отношения к ФП - это язык логического программирования, которое вместе с функциональным составляет ветку декларативного программирования, противостоящую ветке императивного программирования, в которую входят процедурное и ООП...
В императив ещё стоит, видимо, добавить автоматное.
А в декларатив - марковское.
№ 3244 05-10-2007 15:56 | |
Ответ на »сообщение 3243« (Geniepro)
___________________________
>Аналогично: может ли он обойтись без ООП, если за это отвечает свой язык?
В стандартном Хаскелле-98 нет и намёков на ООП, тем не менее хаскеллеры прекрасно пользуются Хаскеллом, иногда, правда, ради забавы придумывая разные диалекты для разных целей, в частности вводя расширяемые записи аля Оберон...
Я имел в виду O'Haskell, OOHaskell. Если делают -- значит, видимо, не хватает.
>Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)?
У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...
Раз сомнения -- подождем, как прокомментирует сам Вагиф, как сообразуются Ваши высказывания с его.
>Может ли Haskell обойтись без работы с миром императива через монады? Если будет для этого специальный язык (вне Haskell'я)?
Вопрос непонятен. Вы хотите убрать монады и упростить Хаскелл на один процент, но при этом потерять треть его возможностей? Смысл?
Императивная работа с вводом/выводом - это лишь маленький побочный эффект введения монад в Хаскелл...
Не предлагаю убрать монады, просто хочу понять, зачем дублировать императив внутри Хаскеля в том случае, если у Хаскеля появится искусственный ИП-спутник.
№ 3243 05-10-2007 15:41 | |
Ответ на »сообщение 3242« (Руслан Богатырев)
___________________________
Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)?
У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...
Может ли Haskell обойтись без работы с миром императива через монады? Если будет для этого специальный язык (вне Haskell'я)?
Вопрос непонятен. Вы хотите убрать монады и упростить Хаскелл на один процент, но при этом потерять треть его возможностей? Смысл?
Императивная работа с вводом/выводом - это лишь маленький побочный эффект введения монад в Хаскелл...
Аналогично: может ли он обойтись без ООП, если за это отвечает свой язык?
В стандартном Хаскелле-98 нет и намёков на ООП, тем не менее хаскеллеры прекрасно пользуются Хаскеллом, иногда, правда, ради забавы придумывая разные диалекты для разных целей, в частности вводя расширяемые записи аля Оберон...
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|