| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 882 21-08-2006 01:34 |   |
Заметки на полях.
Тут упоминалось о разработке Perl на Haskell
Интересная ссылка:
http://www.parrotcode.org/faq/
А вопрос звучит так:
Pugs is going great shakes - why not just toss Parrot and run Perl 6 on Pugs?
| № 881 21-08-2006 00:37 | |
Ответ на »сообщение 869« (SJ)
___________________________
>>>математики еще в прошлом веке доказали эквивалентность всех машин Тьюринга, которыми, собственно, и являются любые существующие в мире процессоры.
1. Эквивалентность всех машин Тьюринга никто не доказывал, и не думаю, что это возможно.
2. Вообще говоря, любые существующие в мире процессоры являются конечными автоматами. ;-)
| № 880 20-08-2006 17:23 | |
Ответ на »сообщение 877« (SJ)
___________________________
Математики всего мира уже почти 80 лет уверяют нас, что любая функция, для которой существует алгоритм решения может быть вычислена с помощью машины Тьюринга.
Читайте внимательнее. Geniepro не говорил что функцию Акермана нельзя написать в итерации.
Он сказал что ее гораздо труднее написать в итерации.
То есть теоретически можно, практически, вряд ли вы найдете программиста который с этим бы справился.
Я попробую прогнать ее на lispworks попозже. Сейчас занят.
| № 879 20-08-2006 15:30 | |
Строим дерево ссылок, доходим до оси m (типа стриммерного разряда
в целочисленном пространстве), получаем данные и назад в будущее!
Не знаю, итеративный ли это метод, но без рекурсии можно обойтись.
Головоломка к практике отношения не имеет, но очень забавная.
Думаю, сильно упростит дело запоминание численных значений,
особенно у оси n.
Первая строчка - раздача значений.
Вторая - отбойник от оси n (m=0) со сползанием по n.
Третья - генератор разветвления дерева, но в сторону начала
координат. В нём весь прикол.
А если ввести СуперАккермана (вместо третьей строки)?
Что-то вроде: A:=A(n-1,A(n,A(n-1,m-1)). Вот Haskel запищит!
| № 878 20-08-2006 12:51 | |
Ответ на »сообщение 866« (Jack Of Shadows)
___________________________
А математики неформального языка не понимают и не признают.
Я Вас умоляю... хоть за математиков не говорите...
| № 877 20-08-2006 11:58 | |
>>>Тут утверждалось, что рекурсия и итерация полностью эквивалентны. Это
>>>не совсем так!
У меня лично на борьбу с функцией Аккермана времени сейчас нет, последний день отпуска :))))
Но Вас можно поздравить с открытием :)
Математики всего мира уже почти 80 лет уверяют нас, что любая функция, для которой существует алгоритм решения может быть вычислена с помощью машины Тьюринга. Впрочем точно так же, как и с помощью любой другой алгоритмической модели: машины Поста, нормальных алгоритмов Маркова, частично-рекурсивных функций Черча и т.д.
Стиль работы машины Тьюринга - это, по сути, итерация: цикл вида - выполнить команду, перейти к следующей. До тех пор, пока не будет выполнена команда стоп.
Так вот. Если Вы уверены, что функцию Аккермана нельзя вычислить на машине Тьюринга, то это значит, что ее вообще нельзя вычислить. И наоборот, если ее вычислить можно, то это можно сделать с помощью машины Тьюринга, т.е. путем итерационного алгоритма.
Жаль, что нет Нобелевской премии по математике - она была бы Вашей :)))
| № 876 20-08-2006 11:38 | |
Тут утверждалось, что рекурсия и итерация полностью эквивалентны. Это не совсем так!
Вы упускаете из виду, что есть два вида рекурсии: рекурсивное определение и рекурсивное использование.
Скажем, рекурсивные варианты функций Фибоначчи и факториала являются рекурсивно определёнными и их легко представить в итеративном виде.
Но, например, известная функция Аккермана использует и рекурсивное определение, и рекурсивное использование:
function Acc (m, n : integer) : integer;
begin
if m = 0 then return n + 1 else
if n = 0 then return Acc (m - 1, 1)
else return Acc (m - 1, Acc (m, n - 1))
end; или (defun acc (m n)
(cond ((= m 0) (+ n 1))
((= n 0) (acc (- m 1) 1))
('t (acc (- m 1) (acc m (- n 1))))
) )
Попробуйте переделать эту функцию в итеративный вариант! ;-)
ЗЫ. Кстати, не могли бы Вы посчитать эту функцию с аргументами 5 и 0 ? ( Асс(5, 0) или (асс 5 0) )
Мне очень интересно, какой результат Вы получите...
А то мой комп не справляется с этой простенькой задачкой - стек переполняет...
Даже DrScheme и тот практически зависает... :-(
| № 875 20-08-2006 11:36 | |
Ответ на »сообщение 863« (Jack Of Shadows)
___________________________
Closures это не только доступ к локальным переменным своего контекста.
Это также инкапсулирование. Как например private поле класса инкапсулировано в обьекте класса, и методы этого класса могут менять значение этого поля и считывать его много раз.
Так и closures это функция которая может "закрывать" собой локальную переменную. Но эта переменная не уничтожается когда функция отрабатывает.
Ок, позвольте сформулировать, как я понял сlosures из разных источников:
Closures - это некие функции, возвращаемые некоторыми другими функциями в качестве результата, и имеющие доступ к локальному контексту (пременным, типам, функциям и тд) возвращающих их функций.
Из этого вытекает следующее:
Результат выполнения сlosures зависит не только от их аргументов, но так же и от посторонних по отношению к этим сlosures сущностей; по сути, сlosures используют побочные эффекты и сами могут создавать их!
Значит, сlosures являются нарушениями чистоты функционального подхода?
Некая смесь функционального и императивного подходов?
| № 874 20-08-2006 11:23 | |
Уточнение и дополнение к #872.
Что интересно - зависимость времени создания массива (array) в Haskell (Hugs98) от его размера явно нелинейная:
-Для матрицы 300х300 (90000 элементов) мой комп думал примерно 1 минуту.
-Для матрицы 500х500 (250000) ~ 5 минут.
-Для матрицы 1000х1000 (1000000) ~ 38 минут.
При простом связывании элементов списка такое вряд ли возможно - количество элементов увеличилось в 4 раза, а время создания почти в 8.
| № 873 20-08-2006 05:02 | |
>>>Вы невнимательно прочитали:
Я же успел извиниться :))) Еще раз - прошу прощения за ляп.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
