| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 1962 22-02-2007 17:16 |   |
Ответ на »сообщение 1961« (Илья Ермаков)
___________________________
В статье Info21 перечилил те моменты ФП, которые он считает значимыми, и как именно эти моменты применяются в программировании на Обероне.
Все это отмазки, да еще и в виде мнения кого то там, кто к ФП сбоку припека.
Где размашисто функциональное программирование на обероне ? Код в студию.
Сказать то много чего можно :))
Ах да попытались уже. Вместо map получился раскоряченный в интерфейсном приседе непойми что.
Если это функциональное программирование то тогда я папа римский :))
| № 1961 22-02-2007 16:53 | |
Ответ на »сообщение 1959« (Jack Of Shadows)
___________________________
Ответ на »сообщение 1958« (Илья Ермаков)
___________________________
http://www.inr.ac.ru/~info21/qna.htm#functional
Не понял, как отмазка на вопрос почему в Оксфорде хаскель первый а оберон второй, является доказательством того что на обероне можно писать "размашисто по-функцыональному" ? :))
В статье Info21 перечилил те моменты ФП, которые он считает значимыми, и как именно эти моменты применяются в программировании на Обероне.
| № 1960 22-02-2007 16:51 | |
Ответ на »сообщение 1956« (Jack Of Shadows)
___________________________
Ответ на »сообщение 1952« (AVC)
___________________________
О том и речь шла когда я говорил об ортогональности.
Нет ее в ИЯ, приходится извращаться и создавать такие вот СПЕЦИАЛЬНЫЕ функции Double вместо того чтобы пользоваться той что есть. И так в кажом конкретном случае.
Библиотека всевозможных функций "на все случаи жизни" растет как на дрожжах.
И чем закончился пример ?
Вместо одной строчки использующей СТАНДАРТНЫЙ один раз написанный map со стандартными один раз написанными ЛЮБЫМИ функциями, работающими с ЛЮЫМИ типами, при этом и сохраняющий СТРОГУЮ ТИПИЗАЦИЮ, имеем зоопарк разных НЕСТАНДАРТНЫХ функций, которые надо написать потому что стандартные функции, эта - в дырку не лезут :))
Ортогональность - это допустимость языком любых разумных сочетаний конструкций? В этом есть и плюсы, и минусы. Число степеней свободы не пропорционально мощности. У червяка огромное количество степеней свободы, потому что нет скелета. Однако встать на свой хвост червяк не может. У человеческой руки число степеней свободы строго ограничено, и тем не менее она решает огромный спектр задач. Эти аллегории не привязаны к конкретным языкам, просто для примера - что ортогональность, как и все в нашем мире, палка о двух концах...
По поводу второй проблемы - да, такая проблема есть. Решается введением обобобщенки Однако опять же - все зависит от решаемых задач. Я знаю об этой проблеме и прекрасно понимаю, в каких задачах прикладник может ее ощутить. Однако сам почти не ощущал нехватки дженериков. Просто в силу работы над системными задачами. Ну, не нужен для них общий Map. Обобщенности, даваемой расширением типов и метапрограммированием хватает. Зато ясность и простота языка в выражении архитектуры, разъемов между модулями системы, выходит на первый план по сравнению со средствами записи алгоритмов.
| № 1959 22-02-2007 16:36 | |
| № 1958 22-02-2007 16:30 | |
Ответ на »сообщение 1946« (pepper)
___________________________
Ответ на »сообщение 1942« (info21)
___________________________
Именно по этой причине я отказался от ФЯ в пользу Оберона -- где можно начать размашисто по-функцыональному, и закончить статическими структурами.
Размашисто по-функциональному? На обероне? Это даже не смешно. Более неприспособленного для написания в функциональном стиле ЯВУ придумать сложно. Даже дельфя даст фору.
http://www.inr.ac.ru/~info21/qna.htm#functional
| № 1957 22-02-2007 15:01 | |
Ответ на »сообщение 1952« (AVC)
___________________________
Насколько я понимаю, в Scheme динамическая типизация (верно ли?).
Динамическую проверку типа можно применить и в Обероне.
...
А процедуру Double напишем примерно так:
...
То есть Вы предлагаете идти от обратного?
Если в Scheme Вам достаточно определить функцию double в очень простом виде:
(define (double x)
(* 2 x))
а map - так как Вы предлагаете:
(define (map f list)
(if (null? list) ()
(cons (f (car list)) (map f (cdr list)))))
то потом можно задавать такие запросы, как:
(map double '(1 2 3 4))
(map double '(1.0 2.0 3.0 4.0))
(map double '(1/2 2/3 3/4 4/5))
и не нужен никакой оператор WITH... Результат будет нужным:
(2 4 6 8)
(2.0 4.0 6.0 8.0)
1 1 3
(1 1- 1- 1-)
3 2 5
Аналогично и в Хаскелле...
| № 1956 22-02-2007 14:54 | |
Ответ на »сообщение 1952« (AVC)
___________________________
Не получится :))
Именно строгая типизация вам не позволит. Ну лист ладно вы мапу передадите по интерфейсу.
А функция Double то требует КОНКРЕТНЫЙ ТИП numeric.
Именно поэтому вам пришлось переписать Double как принимающий тоже интерфес List :))
Получается что вы не можете ВООБЩЕ никакую функцию мапу передать а только те которые специально перепишете.
А это грабли :))
О том и речь шла когда я говорил об ортогональности.
Нет ее в ИЯ, приходится извращаться и создавать такие вот СПЕЦИАЛЬНЫЕ функции Double вместо того чтобы пользоваться той что есть. И так в кажом конкретном случае.
Библиотека всевозможных функций "на все случаи жизни" растет как на дрожжах.
И чем закончился пример ?
Вместо одной строчки использующей СТАНДАРТНЫЙ один раз написанный map со стандартными один раз написанными ЛЮБЫМИ функциями, работающими с ЛЮЫМИ типами, при этом и сохраняющий СТРОГУЮ ТИПИЗАЦИЮ, имеем зоопарк разных НЕСТАНДАРТНЫХ функций, которые надо написать потому что стандартные функции, эта - в дырку не лезут :))
При этом все прелести строгой типизации ТЕРЯЮТСЯ, потому что никто вам не запрещает такому вот мап передать вместо списка числе - спискок строк. Вы не получите никакой ошибки при компиляции.
А в хаскеле - получите.
| № 1955 22-02-2007 14:53 | |
Разница между конкурирующими ветками составляет ровно 1000 сообщений. :)
| № 1954 22-02-2007 14:50 | |
Ответ на »сообщение 1953« (Geniepro)
___________________________
PROCEDURE Map* (f: PROCEDURE(p: IntList); p: IntList);
Если я правильно понимаю, такая декларация процедуры map гарантирует отсутствие изменения содержимого переменной p, не так ли?
<...>
ЗЫ. Поправьте меня, если я вдруг сполусонья ашипся... :о))
В данном конкретном случае Вы понимаете неправильно. :)
List и IntList -- указатели.
TYPE
List* = POINTER TO EXTENSIBLE RECORD next: List END;
IntList* = POINTER TO RECORD (List) x*: INTEGER END;
Перед тем, как привести пример кода, я сделал набросок в ББ, откомпилировал его и исполнил, получив 2 4 6 8.
| № 1953 22-02-2007 14:44 | |
Ответ на »сообщение 1951« (AVC)
___________________________
Похоже, что после вызова первоначальный список уходит в корм сборщику мусора.
Зачем же мне брать пример с не самой лучшей стороны ФП?
Ну хорошо, допустим, что для Вас не имеет особого значения такое важное для ФП понятие, как прозрачность по ссылкам, связанная с отсутствием изменения каких-либо объектов...
PROCEDURE Map* (f: PROCEDURE(p: IntList); p: IntList);
Если я правильно понимаю, такая декларация процедуры map гарантирует отсутствие изменения содержимого переменной p, не так ли? Тогда эта процедура может производить очень ограниченный набор действий над списком - например вывести его на печать, но никак не удвоить значения его элементов... :о))
Разве не следует объявить её вот так:
PROCEDURE Map* (f: PROCEDURE(VAR p: IntList); VAR p: IntList);
Казалось бы, такая простая задача, а так чревата ошибками в императивных языках... То ли ещё будет, ой-ё-ёй! ;о)
ЗЫ. Поправьте меня, если я вдруг сполусонья ашипся... :о))
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
