Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2402 01-04-2007 04:17 | |
Ответ на »сообщение 2391« (Geniepro)
___________________________
Ответ на »сообщение 2384« (Руслан Богатырев)
___________________________
Неужели Вы действительно думаете, что решать типичные школьные задачки на Обероне легче, проще и быстрее, чем на этих трёх языках?
Знаете, я как-то не помню никаких проблем с решением "типичных школьных задачек" на Паскале, когда был в школе... В 11 классе реализовывал даже распознавание образов на Дельфе - и вполне успешно (программа заняла 1 место на всеройссийском конкурсе Intel-Авангард).
Так вот, о чем я - освоить паскалеский инструмент школьнику вполне по силам самостоятельно, как по силам и делать на нем что-то реальное. А если говорить о ББ - то вообще, более или менее способный школьник унесет с собой не только основы алгоритмизации, но и отличный "карманный" инструмент для решения каких-либо несложных задачек или "любительского" программирования в дальнейшем.
А вот с ФП-то, господа, вы как раз ставите школьнику жесткий "потолок": вроде бы и все легко сначала, и функции вы рекурсивные попишете, но дальше для самостоятельной работы дорога закрыта - для окончившего школу и не ставшего проф. программистом два выбора: либо так ничего никогда и не написать за пределами школьного курса, либо лезть в дебри сверхвысоких для среднего ума абстракций...
№ 2401 01-04-2007 03:57 | |
Если сформулировать предварительное впечатление от обсуждения, то функциональщики несколько увлекаются деталями языка Хаскель, как будто ФП и Хаскель одно и то же (на мой взгляд, Хаскель -- частный случай), а оберонщики склонны не замечать механизмы, отсутствующие в "чисто" императивных языках (например -- лямбды; каюсь).
№ 2400 01-04-2007 03:39 | |
Ответ на »сообщение 2395« (AVC)
___________________________
Ответ на »сообщение 2393« (Geniepro)
___________________________
Просто потому, что это главная единица лямбда-исчисления - основы ФП.
По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.
Насколько я понял, необходимости в лямбдах нет, как и прямой связи между лямбдами (как безымянными функциями) и функциональностью (в смысле ФП).
Я подумал и решил, что вчера был неправ. :)
Действительно, λ нужна для анонимного и динамического создания функций.
Это как раз та специфика ФП, которая выходит за рамки отсутствия побочных эффектов и относится к функциям как "объектам первого порядка".
Короче, возражение по этому пункту снимаю.
№ 2399 01-04-2007 02:26 | |
Ответ на »сообщение 2398« (slava)
___________________________
Синтаксический сахар, как анонимные классы в Java.
Верно. Однако 2 замечания.
Во первых анонимные классы в java - это провальный эксперимент. Слишком громоздкий синтаксис. Синтаксический сахар должен быть коротким и удобным. Иначе его смысл теряется.
Во вторых в данном конкретном случае это смотря с какой стороны смотреть.
Со стороны ИЯ - анонимные функции это синтаксический сахар.
Со тороны ФЯ - наименование функций это синтаксический сахар, потому что лямюа является основополагающей абстрацией, основным механизмом, солью ФП
То есть функция в ФП записывается так:
f = lamdba x y -> bla bla x y
и привычное вам обьявление функций
f(x,y) = bla bla - это с точки зрения ФП и есть синтаксический сахар к лямбде.
№ 2398 01-04-2007 02:20 | |
Здесь (<10) является анонимной функцией. Не будь этой фозможности вам пришлось бы писать так:
Синтаксический сахар, как анонимные классы в Java.
№ 2397 31-03-2007 23:30 | |
Ответ на »сообщение 2396« (AVC)
___________________________
Я просто никак не могу себе хорошо представить эту глобальную структуру, в которой все хранится. :)
Попробуйте написать сами.
Короче, один пример (даже схематичный) стоит тысячи слов.
Вам уже этот пример приводили. В целых 63 строчки. Требовать от кого либо чтобы он тратил на вас свое свободное время, мягко говоря некорректно. Хотите посмотреть код побольше и посложнее - есть такие известные open source проекты на хаскеле как darcs, pugs, HaskellDB, и еще много много других библиотек.
Есть также и большие программы типа Quake на хаскеле. Тоже с исходным кодом.
Ну какая принципиальная разница, именована функция или нет, если ее имени не видно за пределами модуля?
Почему, собственно, без анонимных функций нет ФП?
Во первых динамическое создание функций. Там названия так просто не дашь.
Во вторых я уже приводил примеры как раз показывающие преимущество использования анонимных функций.
Приведу еще раз
less_than_10 = filter (< 10) mylist
Здесь (<10) является анонимной функцией. Не будь этой фозможности вам пришлось бы писать так:
is_less_than_10 x = x < 10
less_than_10 = filter is_less_than_10 mylist
№ 2396 31-03-2007 20:26 | |
Ответ на »сообщение 2394« (Geniepro)
___________________________
Ну так меняйте, в чём проблема-то?
Если этот тип - абстрактный, то вся работа с ним будет вестись через набор операций, с ним связанных, а кишки его будут спрятаны в каком-нибудь отдельном модуле. Сама структура-то собственно и не всплывёт наружу - это ведь абстрактный тип данных.
Я просто никак не могу себе хорошо представить эту глобальную структуру, в которой все хранится. :)
Как она соединяется в одно целое?
Как с ее помощью получить доступ к отдельным объектам?
И т.д.
Конечно, причиной может быть моя неопытность в ФП.
Мое представление о соединении структур данных в ФП ограничено использованием пар в Схеме (car, cdr etc).
Короче, один пример (даже схематичный) стоит тысячи слов.
№ 2395 31-03-2007 20:04 | |
Ответ на »сообщение 2393« (Geniepro)
___________________________
Просто потому, что это главная единица лямбда-исчисления - основы ФП.
По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.
Насколько я понял, необходимости в лямбдах нет, как и прямой связи между лямбдами (как безымянными функциями) и функциональностью (в смысле ФП).
Начиная с Алгола-68, существуют императивные языки, ориентированные на ?-исчисление, но не ставшие от этого функциональными.
Разве Оберон (или др. ИЯ) обязан подражать ФП во всех деталях реализации?
Конечно же не должны, на то они и не функциональные языки.
Переформулирую. :)
Разве все ФЯ реализуют ФП одинаково?
Я просто хочу подчеркнуть, что Вы сводите разговор на уровень реализации (не ФП, а Хаскель; лямбды есть во всех ФЯ, а в Обероне нет и т.д.) вместо уровня концепций.
Вместо локальной процедуры вполне можно вернуть объект с функцией (функтор, объект-функцию).
Это уже ООП...
Разве?
Хочу напомнить, что в функторы (объекты-функции) в STL никакого отношения к ООП не имеют.
А то, если так рассуждать, то почти все ИЯ являются еще и ФЯ: ведь практически в каждом есть функции. :)
Языки, в которых функции не являются объектами первого класса, по определению не являются функциональными языками. Всё-таки главное в ФП - функции, всё остально вертится вокруг них, а не они вокруг всего остального.
Здесь у меня есть некоторое сомнение.
Ведь функция есть некое отображение.
Может ли она логически быть первой ("главной"), если само ее определение предполагает существование других объектов (не функций)?
Конечно же, аскеты не нуждаются в новомодных штучках, но зачем отказываться от удобств-то?
Так же говорили и сторонники PL/I. :)
"Мы слишком любили удобства."
Конечно, очень большого труда не составит, но труд будет всё-таки больше.
Это опять же из раздела автоматизации труда программиста. Сборщик мусора необязателен, но очень желателен. Так же и list comprehensions необязательны, но очень желательны...
Пардон?
Я правильно понял, что в ФП сборщик мусора -- необязательный элемент, кусок синтаксического сахара?
Например, в Обероне его необходимость считается математически доказанной...
>>>Э-э, это не ко мне. Не я постановщик этого вопроса ("Может ли Оберон использоваться как ФЯ?")
Повторю вопрос: все ФЯ реализуют ФП одинаково?
Между кортежами и записями есть небольшая разница. Кортежи можно рассматривать как безымянные записи. Т.е. при использовании записей приходится создавать специальные новые типы, при использовании кортежей от этой ненужной работы можно избавиться.
Кому ненужная работа, а кому спасение.
Илья Ермаков уже много раз говорил о том, какую роль играет т.н. "избыточность".
Не верите нам, так хотя бы возьмите в руки учебник по теории кодирования (раздел дискретной математики).
>>>Так и язык ведь он не функциональный, а императивный. Потому и по-другому устроен...
Вместе с тем, он позволяет писать в функциональном стиле.
Естественно, это не слишком удобно, но возможно (а речь и шла именно о принципе).
№ 2394 31-03-2007 19:37 | |
Ответ на »сообщение 2392« (AVC)
___________________________
Вот создал я АТД, а он должен торчать "кишками наружу", чтобы выдержать принципы ФП.
Допустим, от многих неприятностей меня функциональность как раз и защитит (не даст модифицировать мои структуры данных).
Но что будет, если мне потребуется изменить эти структуры?
В модульном и объектно-ориентированном программировании здесь нет никаких проблем (да-да, то самое сокрытие информации), но там структура данных не всплывает наверх, в отличие от ФП.
Ну так меняйте, в чём проблема-то?
Если этот тип - абстрактный, то вся работа с ним будет вестись через набор операций, с ним связанных, а кишки его будут спрятаны в каком-нибудь отдельном модуле. Сама структура-то собственно и не всплывёт наружу - это ведь абстрактный тип данных.
А если Вы вдруг поменяете интерфейс этого типа - то тут Вас не спасёт и ООП...
Если же "кишки наружу" будут, то какой же это АТД? :о))
Эти данные будут у Вас проходить через главный поток управления - но они же не будут размазаны по всей программе! Доступ к ним будет жёстко ограничен, а интерфейс - абстрактным! В чём проблема-то? Главный поток (называйте как хотите - монада ввода-вывода или как-нибудь по другому...), так вот, главный поток программы и будет тем самым модулем, который скрывает свои данные от чужих рук и глаз...
Ссылка в тему: D. Obradovic "Structuring functional programs by using monads"
№ 2393 31-03-2007 19:20 | |
Ответ на »сообщение 2390« (AVC)
___________________________
Лямбда-абстракции (безымянные/анонимные функции) - это очень важный элемент ФП, который напрочь отсутствует в Оберонах. Без этого элемента язык не может считаться функциональным.
Почему?
Просто потому, что это главная единица лямбда-исчисления - основы ФП.
По-моему, не существует ни одного ФЯ, в котором бы не было лямбд.
Главное отличие поименованных функций от безымянных в том, что безымянные создаются динамически, а поименованные - статически.
Разве Оберон (или др. ИЯ) обязан подражать ФП во всех деталях реализации?
Конечно же не должны, на то они и не функциональные языки.
Вместо локальной процедуры вполне можно вернуть объект с функцией (функтор, объект-функцию).
Это уже ООП...
Языки, в которых функции не являются объектами первого класса, по определению не являются функциональными языками. Всё-таки главное в ФП - функции, всё остально вертится вокруг них, а не они вокруг всего остального.
Сопоставление по образцу (pattern matching) - очень модный аттрибут современных ФЯ и некоторых гибридных языков.
Причем здесь ФЯ?
Да ни при чём, просто это сейчас очень модно в ФЯ. Мода, ничего больше.
Конечно же, аскеты не нуждаются в новомодных штучках, но зачем отказываться от удобств-то?
Вообще, pattern matching - аттрибут декларативного программирования, а так как ФП часто относят к разделу ДП, то в ФЯ этот элемент очень желателен - повышает уровень декларативности программ.
Если содержимое массива можно задать в "удобной декларативной манере" (т.е. не надо перечислять все элементы, а есть некая система), то и в императивной большого труда не составит.
Это из области синтаксического сахара.
Конечно, очень большого труда не составит, но труд будет всё-таки больше.
Это опять же из раздела автоматизации труда программиста. Сборщик мусора необязателен, но очень желателен. Так же и list comprehensions необязательны, но очень желательны...
Опять же, предрассудок, что Оберон должен делать все так же, как ФЯ.
Э-э, это не ко мне. Не я постановщик этого вопроса ("Может ли Оберон использоваться как ФЯ?")
Между тем, кортежи в Обероне есть -- это записи-параметры.
На их использовании основана работа часто упоминаемой в обероновской ветке software bus.
Запись можно передать в качестве аргумента, можно вернуть в качестве результата.
Между кортежами и записями есть небольшая разница. Кортежи можно рассматривать как безымянные записи. Т.е. при использовании записей приходится создавать специальные новые типы, при использовании кортежей от этой ненужной работы можно избавиться.
Могу выделить два пункта.
1) Большая любовь к синтаксическому сахару (что для ФЯ, возможно, необходимость).
Синтаксический сахар не только приводит к раку точки с запятой, но иногда просто делает язык вкуснее... :о))
2) Уверенность, что Оберон должен реализовывать некую функциональность так же, как ФЯ. Поэтому просто выпадает из зрения тот факт, что он эту функциональность реализует по-другому.
Так и язык ведь он не функциональный, а императивный. Потому и по-другому устроен...
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|