Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 3042 03-10-2007 02:12 | |
Ответ на »сообщение 3037« (Jack Of Shadows)
___________________________
Ответ на »сообщение 3035« (Илья Ермаков)
___________________________
Задача, котору решает программист настолько далека от машины, что ему приходится разбивать ее на сотни и тысячи микроскопических задачек и записывать их в правильной последовательности. Именно этот процесс поддается и должен быть автоматизирован.
Да, в тех случаях, когда для решаемой задачи эта последовательность не имеет значения.
Например, математические вычисления - ну какая разница, в каком порядке записать соотношения? Пускай машина сама за нас раскидает...
Другой пример - кулинарный рецепт. Переставьте местами порядок действий и Вы окажетесь очень далеко от правильного результата :-)
Если я буду описывать кулинарный рецепт функциями вместо алгоритмов, то я буду вынужден изобретать некоторый способ вернуть в функциональный мир понятие времени, и взваливать на себя дополнительную работу по борьбе с этой проблемой (монады, которые неспроста называют самой трудной частью Хаскелла). Это пример того, как выбор неадекватного задаче инструмента (ФП для управляющей по своей сути программы, или ИП для преобразующей) может заставить человека вместо борьбы с самой задачей бороться с инструментом.
Не ну серьезно что такого творческого вы увидели в жонглировании счетчиками циклов ? :))
№ 3041 03-10-2007 02:07 | |
Ответ на »сообщение 3040« (Руслан Богатырев)
___________________________
Ну Руслан, уж вы то должны знать что элементом множества может быть другое множество.
Так что отображение X -> Y вполне может быть и единственного элемента из множества X на множество входящее в множество Y.
Вам привести примеры функций, принимащих одно значение и возвращающих список ? Или сами сподобитесь ?
№ 3040 03-10-2007 01:49 | |
№ 3039 03-10-2007 01:40 | |
№ 3038 03-10-2007 01:09 | |
Ответ на »сообщение 3036« (Руслан Богатырев)
___________________________
>>> Возьмите два множества: X и Y. Поставьте в соответствие элементам X элементы Y. Т.е. осуществите отображение (ключевая вещь в мышлении: аналогии, ассоциации, связи, отношения).
>>> Увы, математическая функция требует однозначности: нельзя одному и тому же элементу множества X поставить в соответствие несколько элементов множества Y.
О, да... Наука в проекте "Роса" явно в привилегированном положении...
Классическая математическая функция: y = x * x, осуществляет сжимающее отображение. Двум элементам (a, -a) – ставится в соответствие один. Обратная функция ставит в соответствие одному элементу два – x = +/-sqrt(y).
А если вспомнить хеш-функции... Там столько элементов в соответствие одному ставится...
№ 3037 02-10-2007 16:38 | |
Ответ на »сообщение 3035« (Илья Ермаков)
___________________________
Задача, котору решает программист настолько далека от машины, что ему приходится разбивать ее на сотни и тысячи микроскопических задачек и записывать их в правильной последовательности. Именно этот процесс поддается и должен быть автоматизирован.
То есть даже если человека не удастся заменить вообще, то по крайней мере задачу "доведения до машины" можно сильно облегчить.
Приведу пример с эволюцией оператора цикла.
while условие
...
end
Это самый общий, самый низкоуровневой вариант цикла. С его помошью можно решать любые задачи, в том числе и скажем обработку массива.
Но для обработки массива таким образом программист должен выполнить ряд подготовительных и технических микрозадачек.
i = 0 ; Вручную создать до цикла и инициализировать счетчик.
while i < 11
....
i := i + 1; Вручную управлять счетчиком
end
Это приводит к появлению ряда возможностей для часто встречающихся и типичных ошибок.
1. Забыл инициализировать счетчик
2. Забыл обновить счетчик, программа вошла в вечный цикл и зависла.
Можно ли перепоручить эти микрозадачи машине ? Оказывается можно:
for i = 0 to myArr.count - 1 do
....
end
Как видите забыть инициализировать счетчик программист уже не сможет. И забыть его увеличить на единицу тоже не сможет. Эти автоматически занимается компьютер. Вот уже 2 ошибки ИСКЛЮЧЕНЫ, благодаря тому что часть работы отдана машине.
Однако все ли микрозадачи убраны, все ли возможности для ошибок исключены ?
Нет. Человек все еще должен вручную инициализировать переменную, и вручную проверять условие на выход.
Это приводит к еще ряду часто встречающихся типичных ошибок:
1 - Перепутал границы массива. 1 вместо 0, count вместо count - 1
2. Изменил переменную i внутри цикла, таким образом перепрыгнув через несколько эоементов массива, или выйдя за ее пределы.
3. При двух и более вложенных циклах перепутал i с j
Можно ли избавиться раз и навсегда от этих ошибок ? Можно ли перепоручить эти микрозадачи решать компьютеру ? Оказывается можно.
foreach item in myArr
....
end
Как видите здесь программист уже не задает ни начальное ни конечное значение счетчика.
Он уже не может ошибиться с 0 или 1 или count или count - 1
Программа всегда правильно начнет с начала массива и всегда гарантированно закончит на последнем элементе.
Далее при вложенных циклах программист не перепутает счетчики циклов просто потому что их нет этих счетчиков. Они упрятаны внутрь. Ими занимается компьютер, и это вообще не ваше дело.
Вот вам еще три частые ошибки ИСКЛЮЧЕНЫ, благодаря тому что часть работы отдана машине.
И вот так вот можно довольно долго продолжать, отдавая автоматическую, рутинную, однообразную работу машине, которая никогда не ошибается.
Творческая составляющая при этом не затрагивается.
ФП конечно не заменит человека полностью, но может автоматизировать множество мелких микрозадачек, тем самым сильно подняв надежность программ, уменьшив количество ошибок, и позволив человеку сконцетрировать творческий подход там где это действительно нужно.
Не ну серьезно что такого творческого вы увидели в жонглировании счетчиками циклов ? :))
№ 3036 02-10-2007 16:28 | |
Ответ на »сообщение 3032« (Jack Of Shadows)
___________________________
Функция, преобразующая данные. Весь мир состоит из громадного количества таких вот ВНЕШНИХ и ВЗАИМОПРОНИКАЮЩИХ связей, а не обьектов у которых все методы обработки акуратно так "пришпилены" к данным.
Скажите, а Вы никогда не задумывались над тем, что функция в математике есть жесткая фиксация одного значения из ряда возможных? Возьмите два множества: X и Y. Поставьте в соответствие элементам X элементы Y. Т.е. осуществите отображение (ключевая вещь в мышлении: аналогии, ассоциации, связи, отношения).
Увы, математическая функция требует однозначности: нельзя одному и тому же элементу множества X поставить в соответствие несколько элементов множества Y. Недопустима вариативность. Надо принимать решение здесь и сейчас, не откладывая до лучших времен (когда и будет ясность, что выбрать). Философы, изучающие качественную сторону бытия и сознания, оперируют естественным языком, полным противоречий и многозначности (в чем и ценность его), а математики, изучающие количественную сторону бытия и сознания, -- морозят одно конкретное значение.
Что есть существование в математике? Анри Пуанкаре считает, что слово "существовать" в математике означает "не заключать в себе противоречия". Что интересно, именно противоречия и есть движущая сила бытия и сознания. Именно они предмет интереса философов (и математиков, которые на время любят/вынуждены становиться философами, чтобы потом вновь "морозить" значение).
№ 3035 02-10-2007 16:06 | |
Ответ на »сообщение 3034« (Jack Of Shadows)
___________________________
Ответ на »сообщение 3033« (Илья Ермаков)
___________________________
Как конвееры заменили ручное перемещение,
Затем роботы на конвеерах заменили ручную сборку.
Существует только один единственный способ улучшения результата в любом деле, включая и программирование - это убирание из дела человека.
Я бы не стал опрометчиво строить параллели между промышленным производством и созданием ПО.
Фабричное производство - это этап тиражирования продукта. Т.е. аналогия не с разработкой ПО, а с вырожденной в ИТ фазой физического производства - штамповкой на СД :-)
"Производство ПО" - это на самом деле не этап производства, а этап конструирования. И если и говорить о "выживании человека", то оно происходит совсем другими путями, чем на конвейере... А на самом деле - не особенно-то и происходит. Ну, заменили карандаш и ластик на AutoCAD или Компас - стало быстрее, но разве что-то в секторе умственного контроля изменилось, машина стала что-то продумывать за человека? Так же и в программировании, надо думать, - ничего особенного за человека машина додумать не в состоянии. Тот же поминаемый Вами сборщик мусора ПРИНЦИПИАЛЬНО не способен понять, когда точно пора освобождать память. Он способен только определить, что уже давно пора, потому что она никому не нужна....
№ 3034 02-10-2007 15:57 | |
Ответ на »сообщение 3033« (Илья Ермаков)
___________________________
Я не о теории, я об индустриализации. ФП это индустриализация программирования. Впрочем точно также как и ООП по сравнению с процедурным а до этого машинными кодами.
Убирается ручной труд. Человек выживается, выпихивается с нижних уровней все выше и выше. Ради увеличения производительности.
Как конвееры заменили ручное перемещение,
Затем роботы на конвеерах заменили ручную сборку.
Существует только один единственный способ улучшения результата в любом деле, включая и программирование - это убирание из дела человека.
№ 3033 02-10-2007 15:53 | |
Ответ на »сообщение 3032« (Jack Of Shadows)
___________________________
Ответ на »сообщение 3030« (Илья Ермаков)
___________________________
Парадигма на которой построена ООП - это игрушечная и неработающая "модель" в которую несчастные программисты вынуждены впихивать реальный мир. Да еще и без права на ошибку. Ведь даже поиграться с несколькими построенными моделями нельзя. На одну (самую первую и по определению неверную) уходит слишком много усилий и времени.
Так я в некотором смысле об том же самом :-)
Вы господа топчетесь на одном месте. Оттачиваете до блеска дедовский самурайский меч.
А ФП этот тот самый прогресс, автоматизация, который и выжил на пенсию всех этих самураев, могикан и ОО программистов :))
Рекурсивные функции Гёделя-Чёрча выжили на пенсию машину Тьюринга? Или, может быть, регулярные выражения Клини выжили на пенсию конечные автоматы?
Давайте, может быть, ещё скажем, что волновая природа света выжила корпускулярную :-)
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|