Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2742 06-04-2007 12:03 | |
Ответ на »сообщение 2740« (Руслан Богатырев)
___________________________
В таких принципиаьно разных языках как оберон и хаскель, конечно совнершенно разные механизмы.
В обероне нет много чего что есть в хаскеле. Однако несмотря на это, я думаю глупо требовать от оберонщиков отказываться от оператора присваивания.
В ветке по оберону кто то завел очередную волынку про включение некоторых функциональных механизмов в оберон.
Так я был первый кто сказал что это глупо. Что вы поломаете оберон но так и не получите что то лучшее.
Что нужно прежде всего выбирать парадигму в которую вписываются те приемы которые вам нужны и удобны, и соответственно выбирать построенный по этой парадигме инструмент, а не пытаться тащить отовсюду все что вам приглянулось в одну кучу. Достаточно народу до вас это пыталось сделать. И мы имеем уже достаточное количество провалившихся экспериментов, чтобы понять что конкретные элементы и механизмы ЯП становятся полезными и удобными лишь работая в связке друг с другом, а не потому что эта полезность и нужность в них заложена.
Я уже говорил что не сомневаюсь что обязательный квалифицирубщий импорт полезен в обероне, с его модулями, хранящими состояние.
Но в хаскеле нет таких модулей. Для хаскеля модуль, хранящий состояние - это нонсенс.
И заставляяя всех программистов писать длиннющие идентификаторы вы практически никакой пользы и удобства не получите (особенно учитывая то что квалифицирующий импорт в хаскеле есть), зато нервы всем попортите изрядно.
Пора бы уже понять и признать. Что без определенной среды, без определенных, работающих совместно механизмов языка, вырванный из контекста ОБЯЗАТЕЛЬНЫЙ квалифицирующий импорт далеко не такая полезная и нужная штука как вам кажется.
Так же как и я понимаю и признаю, что map fold и filter, вырванные из контекста ФП, и засунутые в оберон, где даже нет нормального встроенного типа списка, где есть разделение на выражения и операторы, где все настроено на работу с целой пачкой разных циклических операторов (опять операторов а не выражений, возвращяющих значение), будут просто как у собаки боковой карман, на черта не нужны, мешаться под ногами, быть обузой а не удобством.
Потому мы к вам и не дезем со своими бирюльками. Но и вы господа сови ОЧЕНЬ ПОЛЕЗЫНЕ бирюльки держите при себе. Нам они на черта не сдались.
№ 2741 06-04-2007 09:13 | |
Ответ на »сообщение 2739« (Geniepro)
___________________________
Окей, Руслан, Вы меня убедили - в отчуждаемых программах лучше квалифицировать импорт, особенно если это не приводит к серьёзному распуханию кода. :о)
Я обновил ту программку на ЖЖ...
Отлично. Я рад, что мы нашли понимание. Можно будет дальше двигаться в русле конструктива. Делить-то нам собственно нечего, только обогащаться -- смотреть что ценное у кого можно стырить :)
№ 2740 06-04-2007 09:10 | |
Ответ на »сообщение 2734« (panda)
___________________________
Оберонщики превозносят Оберон, отрицая ФП в принципе, функциональщики - наоборот. Грустно все это.
Вы излишне упрощаете картину, если не сказать -- утрируете. Предложение разобраться в границах применимости ФП исходило от оберонщиков. Да и сами функциональщики немало сделали для того, чтобы тоже помочь в этом разобраться. Разбор задачи по ACM -- думаю, очень полезный опыт совместных усилий. Разбор Geniepro очень полезный. Побольше бы таких вещей. Думаю, резюмировал достаточно взвешенно и уж никак ФП не выглядело в этой ситуции в проигрыше. Что касается "мелочи" в отношении квалифицирующего импорта, то никто не запрещает это использовать в Хаскеле и Delphi (как некоей дисциплине) исходя из многолетнего опыта Вирта и людей, связанных с Модулой-2 и Обероном. Взять чужой опыт и использовать в любимом языке. Но сама реплика неожиданно для меня вызвала бурю негодования (хотя нет худа без добра, что-то полезное, думаю, для себя мы все вынесли).
Не вижу вообще основы для размежевания, кроме разве что личных амбиций, которые часто мешают вести дискуссию. Давайте все же поднимем уровень обсуждения над амбициями. Понимаю, что это не очень принято в интернет-форумах (равно как и признавать свои заблуждения, недопонимания, ошибки, промахи). Но если есть желание совместно постичь нюансы того, в чем каждая сторона сильна -- это надо делать. Делиться опытом (а не нахваливать свое болото). Да и Delphi-программистам, думаю, будет интересно поучаствовать в конструктивном обсуждении.
Проблемы Оберона настолько тщательно разбирали (хотя еще многое предстоит), что Вы вряд ли найдете эти вещи в другом месте (сами по себе архивы обсуждения, если оттуда отсеять личностно-амбициозный мусор, представляют большую ценность). Разговор идет довольно откровенный, хотя иногда и лукавим (куда без этого), но скорее по инерции формата общения и как защитная реакция на внешние уколы.
Оберон, в отличие от Хаскеля, -- неудобная вещь для среднестатистического программиста именно в силу своей оппозиционности мэйнстриму, нарушает картину всеобщего благополучия. Хаскель же спокойно может вписаться (и уже вписывается) в обойму популярных инструментов. После некоего разочарования в ООП (хотя это результат искусственно завышенных ожиданий народных масс -- в своей сфере ООП очень сильная вещь) нужно дать отдушину, переключить внимание на кардинально другую вещь. ФП и Хаскель спокойно могут взять на себя роль нового универсального лекарства от всех болезней. Мы же все больше лечимся, чем занимаемся профилактикой. Они очень удобны производителям железа и инструментария -- будущее "золотое дно". Пожирание ресурсов в невиданных объемах. Это негативная сторона ФП, которая для законодателей мод (того же Microsoft), становится самой привлекательной. Но давайте больше говорить о реальных положительных сторонах ФП -- они есть и их немало.
№ 2739 06-04-2007 09:02 | |
Ответ на »сообщение 2731« (Руслан Богатырев)
___________________________
Просто пояснил, что в решении Geniepro меня смутило. А дальше пошла цепочка упорного недопонимания (возможно с обеих сторон).
Окей, Руслан, Вы меня убедили - в отчуждаемых программах лучше квалифицировать импорт, особенно если это не приводит к серьёзному распуханию кода. :о)
Я обновил ту программку на ЖЖ...
№ 2738 06-04-2007 08:16 | |
Ответ на »сообщение 2737« (Geniepro)
___________________________
>>>Если для Оберона естественно и логично каждый раз точно указывать, что за объект-модуль используется в том или ином месте, потому что это вытекает из требований к динамичной компонентности, то в статических программах, написанных на том же Хаскелле, это уже не так логично и естественно.
Но почему-то в статических программах, написанных на SML, это опять уже логично и естественно. ;-)
А на OCaml, кажется, не так логично.
№ 2737 06-04-2007 07:48 | |
Ответ на »сообщение 2735« (Илья Ермаков)
___________________________
Имя класса второстепенно, имя модуля - который является активной сущностью - важнее...
Вот она, суть взгляда оберонщиков на модули, кардинально не совпадающего с взгядом на модули со стороны функциональщиков!!!
В Обероне модуль - не просто единица упаковки данных и кода, а именно некий объект со своими меняющимися со временем состоянием и поведением, компонент, одним словом...
В чистом ФП модули не могут хранить изменяемое состояние, функции, определённые в этих модулях, могут вызываться из других модулей и обрабатывать данные, находящиеся в других модулях, и не более...
Если для Оберона естественно и логично каждый раз точно указывать, что за объект-модуль используется в том или ином месте, потому что это вытекает из требований к динамичной компонентности, то в статических программах, написанных на том же Хаскелле, это уже не так логично и естественно.
Хотя ничто не мешает сделать среду, в которой модули на Хаскелле будут загружаться и выгружаться, так что в таких случаях строгая квалификация имён может весьма понадобиться. Но тем не менее, модули на Хаскелле не являются активными сущностями...
№ 2736 06-04-2007 07:37 | |
Ответ на »сообщение 2727« (AVC)
___________________________
Где и когда эти слова применялись к ФП?
А то запомнились только перлы (вроде "разумности" маклиспа). :)
По поводу разумности Маклиспа все претензии к горячим финским парням, написавшим книгу "Мир Лиспа", откуда этот абзац я и выдрал (квалифицировав ссылку на источник, кстати :о))
А то, что у ФП есть некоторые ограничения - так это даже Jack Of Shadows много раз повторял в этой ветке...
№ 2735 06-04-2007 07:11 | |
Ответ на »сообщение 2733« (panda)
___________________________
Ответ на »сообщение 2730« (Илья Ермаков)
___________________________
Я уже написал, если в Delphi два класса реализуют функциональность по-разному, то и называться они должны по-разному. Это защитит гораздо лучше любых встроенных средств языка. А то ведь и модули можно назвать MemoryManager1, MemoryManager2 - и все старания по квалифицирующему импорту пропадут даром.
Мы с Вами пишем на модульных языкак - это значит, что функциональность реализует не класс (который всего лишь тип данных), а тот модуль, в котором он определен. Имя класса второстепенно, имя модуля - который является активной сущностью - важнее...
Ваша позиция проистекает от того, что Вы используете ООП в стиле немодульных языков - класс как контейнер для поведения, а модуль - просто пакет для подключения...
Если Вам так удобно и привычно для ваших задач - ну и прекрасно! Наша с Русланом позиция проистекает из более прямого взгляда на архитектуру паскалевских языков...
№ 2734 06-04-2007 07:06 | |
Ответ на »сообщение 2731« (Руслан Богатырев)
___________________________
В том-то и дело, что непонимание с обеих сторон. Оберонщики превозносят Оберон, отрицая ФП в принципе, функциональщики - наоборот. Грустно все это.
№ 2733 06-04-2007 06:51 | |
Ответ на »сообщение 2730« (Илья Ермаков)
___________________________
У нас позиция другая - если можно ввести большую ясность/прозрачность/аккуратность, то это надо делать...
Вы не поверите, но у меня тоже такая позиция ;)
Проблема в том, что для обеспечения максимальной ясности/прозрачности/аккуратности в любом языке нужны усилия программиста. И если они есть, то разница между некоторыми языками может очень сильно нивелироваться. Я уже написал, если в Delphi два класса реализуют функциональность по-разному, то и называться они должны по-разному. Это защитит гораздо лучше любых встроенных средств языка. А то ведь и модули можно назвать MemoryManager1, MemoryManager2 - и все старания по квалифицирующему импорту пропадут даром.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|