| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 1882 19-02-2007 09:42 |   |
Ответ на »сообщение 1881« (Geniepro)
___________________________
А вот программа, скомпилированная GHC, при расчёте миллионного элемента списка чисел Фибоначчи, всё время удерживала фиксированный объём памяти (ок. 50 мегабайт).
А чего так много, если там только голые вычисления?
Вычислялось долго (само это число в распечатанном виде 204 кБта занимает), но в конце концов вычислилось и без хранения всех элементов в памяти (что-то около ста гигабайт).
Чего-то я не понял. Оно вычислялось в символьном виде, что ли?
| № 1881 19-02-2007 09:07 | |
Ответ на »сообщение 1880« (Jean)
___________________________
Ленивые вычисления и ленивые (бесконечные) структуры данных помогают повысить эффективность программирования в ряде ситуаций. Но насколько ленивыми являются эти конструкции?
...
Понятно, что вопрос имеет общий характер - как поступает ленивый ФЯ в подобных ситуациях?
Вообще-то это вопрос не столько к языку, сколько к его транслятору.
Оптимизирующие компиляторы, проведя анализ строгости (strictness analysis), могут вообще не создавать код с отложенными вычислениями (если задача это позволяет). Именно эта оптимизация и позволяет в подобных случаях программам на ленивых функциональных языках держаться на примерно одинаковом уровне по быстродействию с обычными императивными программами с энергичными вычислениями, а в некоторых случаях (когда задача хорошо подходит под отложенные вычисления) - и превосходить...
Анализ строгости - задача, конечно, непростая, и очень важная (в плане быстродействия) для ленивых ФЯ. Если результаты каких-то вычислений рано или поздно придётся куда-то вывести, то вычислять их всё равно придётся, и там, где это возможно, транслятор должен делать энергичный код, при этом не переусердствовав.
В данном случае мне нужно только значение одного единственного целого числа. Будет ли программа реально строить список длиной 100 и занимать под него необходимую память или "поймет", что требуется только одно число из списка и для этого достаточно только "имитировать" построение списка в памяти -т.е. можно вычислять элементы в одной "ячейке" и не тратить на это больше памяти, чем требуется на самом деле?
Это вопрос к создателям используемого Вами транслятора.
По идее, анализ строгости может подсказать транслятору хранить в памяти только нужные вычисленные элементы списка (если предыдущие элементы нигде не используются).
В данном случае HUGS и GHCi, похоже, удерживают в памяти весь список, потому что очень сильно расходуют память. В этих интерпретаторах не производится анализ строгости, да и вообще какие-либо оптимизации, похоже.
А вот программа, скомпилированная GHC, при расчёте миллионного элемента списка чисел Фибоначчи, всё время удерживала фиксированный объём памяти (ок. 50 мегабайт).
Вычислялось долго (само это число в распечатанном виде 204 кБта занимает), но в конце концов вычислилось и без хранения всех элементов в памяти (что-то около ста гигабайт).
| № 1880 19-02-2007 06:30 | |
У меня вопрос к знатокам ФЯ.
Ленивые вычисления и ленивые (бесконечные) структуры данных помогают повысить эффективность программирования в ряде ситуаций. Но насколько ленивыми являются эти конструкции?
Поясню суть моего вопроса на "классическом" примере.
Последовательность Фибоначчи можно определить в форме бесконечного (ленивого) списка следующим образом:
f = 1:1:[(a+b)|(a,b)<-zip f (tail f)]
Ленивость в данном случае заключается в том, что бесконечный список не создается до тех пор, пока мне не потребовалось реальное вычисление.
Но что будет происходить, если мне потребовалось значение, например, числа Фибоначчи с номером 100 - создание списка длиной в 100 чисел или только вычисление 100 элемента в данном списке?
print (f!!100)
В данном случае мне нужно только значение одного единственного целого числа. Будет ли программа реально строить список длиной 100 и занимать под него необходимую память или "поймет", что требуется только одно число из списка и для этого достаточно только "имитировать" построение списка в памяти -т.е. можно вычислять элементы в одной "ячейке" и не тратить на это больше памяти, чем требуется на самом деле?
Понятно, что вопрос имеет общий характер - как поступает ленивый ФЯ в подобных ситуациях?
| № 1879 19-02-2007 01:15 | |
| № 1878 18-02-2007 23:59 | |
| № 1877 16-02-2007 14:20 | |
| № 1876 16-02-2007 13:26 | |
| № 1875 16-02-2007 02:20 | |
Ответ на »сообщение 1874« (Geniepro)
___________________________
А вы хоть эти документы читали ? :))
Вот вступление к одному из них:
Design patterns are reusable abstractions in object-oriented software.
However, using current mainstream programming languages,
these elements can only be expressed extra-linguistically: as prose,
pictures, and prototypes. We believe that this is not inherent in
the patterns themselves, but evidence of a lack of expressivity in
the languages of today. We expect that, in the languages of the
future, the code parts of design patterns will be expressible as
reusable library components.
И дальше идет доказательство на практике путем написание библиотеки, реализующей патерны на ФЯ.
То есть реализующей в виде библиотек а не трепа на тему "как правильно надо"
Далее, design patterns не что иное как попытка решить задачу инструментом, в котором механизмы абстракции не позволяют эту задачу формализовать.
Я никогда не говорил что в ФП вообще нет потолка абстракции. Есть конечно. Но он гораздо выше.
Вы можете всю свою жизнь работать на ФЯ и никогда не столкнуться с ТИПИЧНОЙ задачей, которую невозможно было бы реализовать в виде библиотеки. Это не значит что таких задач нет.
А вот в ООП - сплошь и рядом :))
| № 1874 16-02-2007 02:08 | |
| № 1873 16-02-2007 01:37 | |
Ответ на »сообщение 948« (Jack Of Shadows)
___________________________
По просьбам трудящихся, даю ссылку на давно утонувшее обсуждение design patterns.
Костыля, совершенно необходимого для ООП, и бесполезного в ФП.
От этого сообщения и дальше, пока поток сознания не перейдет на что то еще :))
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
