[капитан][ФП] Чистые функции не такие чистые

круто, дополнительный аргумент для троллинга в ФП-сраче :)

По ссылке как-то все уныло и печально...

почему об этом не орут на первой странице каждой книги по функциональному программированию?

Может быть потому, что функциональное программирование - это не только чистота и отсутствие побочных эффектов вкупе со ссылочной прозрачностью. Хотя в последнее время создается стойкое ощущение, что хаскелисты отобрали у лисперов знамя ФП, а затем нагло присвоили себе, хотя прежние хозяева несли это знамя на протяжении многих десятилетий. Интересно, а кто отберет его у хаскелистов? :)

А в видео вообще треш и угар. На конференции PyCon обсуждают медлительность функциональных языков, лол :D

Все потому что лисперы орут что Лисп не ФП язык

брейкин ньюс. Атомы компьютера имеют связанные СОСТОЯНИЯ даже если выполняется программа на хаскеле.

Для пятницы подойдет?

Капитанство, понятно. Но ведь почему нет этого большими буквами в каждом учебнике, чтобы особо медлительные это осознавали?

Может быть потому, что функциональное программирование - это не только чистота и отсутствие побочных эффектов вкупе со ссылочной прозрачностью

А что еще?

Для пятницы подойдет?

Да для пятницы отлично)

основательно попахивает безграмотностью...

Ъ: У чистых функций всегда есть side-effects, которые выражаются в пожирании памяти и CPU.

У императивных тоже есть такой side-effect и что?

Угу, все так. Тока вот у меня 85 процентов ну никак не получается. Может 10 от силы и то всякая хрень.

ФП срочно необходимо ввести понятие квантово-чистых функций.

Все потому что лисперы орут что Лисп не ФП язык

Пол Грэм явно не из их числа.

Ну, иногда можно и смухлевать. А тут, понимаешь, тоталитаризм какой-то получается.

Следующая версия Haskell. Настолько функциональная, что ее не только использовать, но даже практически реализовать нельзя. Реализации на бумаге вполне достаточно, так как можно доказать что она может существовать, если пренебречь силой трения.

Питоноукурки даже не догадываются, что связь между хаскельными функциями «на бумаге» и кодом в исполняемом файле настолько условная, что говорить о «пожирании функцией» памяти и CPU может только конченный олигофрен. Местным же Табаки пофиг на что рычать - главное стаей. ЛОР как всегда «торт»

Для начала пройдемся по цитатам (подчеркивания сделаны мною).

Вот, Питер Норвиг пишет в PAIP, хотя несильно акцентируя:

[..]It is very common to use Lisp in a functional style where new variables may be introduced, but once a new variable is established, it never changes.[..]

Совсем новая книга «Land of Lisp» (2011 год) за авторством Конрада Барского:

A key design goal with Common Lisp was to create a multiparadigm language, meaning it includes support for many different styles of programming. You’ve probably heard of object-oriented programming, which can be done quite nicely in Common Lisp. Other programming styles you may not have heard of before include functional programming, generic programming, and domainspecific language programming. These are all well supported within Common Lisp. You’ll be learning about each of these styles, along with others, as we progress through this book.

Теперь довольно древняя книга Турецкого «COMMON LISP: A Gentle Introduction to Symbolic Computation» (1990 год):

[..]Today Lisp is a leading language for sophisticated research on functional, object-oriented, and parallel programming styles.[..]

А что говорить про Грема? Книга «ANSI Common Lisp» (1995 год):

Functional programming means writing programs that work by returning values, instead of by modifying things. It is the dominant paradigm in Lisp. Most built-in Lisp functions are meant to be called for the values they return, not for side-effects.

Если подводить итог, то можно сказать, что CL хорошо поддерживает функциональное программирование, впрочем, как и другие стили. Другое дело, что сейчас можно найти таких лисперов, которые не смогут простой цикл записать через рекурсию.

Потом, этот термин сейчас наделяется несвойственным ему смыслом. Вот, типы классов и GADT - это функциональное программирование или нет?

Питоноукурки даже не догадываются, что связь между хаскельными функциями «на бумаге» и кодом в исполняемом файле настолько условная, что говорить о «пожирании функцией» памяти и CPU может только конченный олигофрен.

Ооо, матерые практики Хаскеля в топике.

Другое дело, что сейчас можно найти таких лисперов, которые не смогут простой цикл записать через рекурсию.

Таких надо срочно на Clojure пересаживать :)

отобрали у лисперов знамя ФП

У каких именно лисперов, хотелось бы знать?

Очевидно, так и есть.

Другое дело, что сейчас можно найти таких лисперов, которые не смогут простой цикл записать через рекурсию.

А некоторые, такие крутые, только этим и занимаются, а потом какой-нибудь оптимизатор перепилит её опять в цикл

Ъ: У чистых функций всегда есть side-effects, которые выражаются в пожирании памяти и CPU.

Наркомания какая-то.

матерые практики Хаскеля в топике

да нет, он мне совсем не по душе, равно как и местные амозглики

матерые практики Хаскеля в топике

да нет, он мне совсем не по душе

Для того, чтобы говорить «связь между хаскельными функциями „на бумаге“ и кодом в исполняемом файле настолько условная», нужно таки быть практиком. При этом испытывать симпатию к Хаскелю не обязательно.

Очевидно конечно, но почему об этом не орут на первой странице каждой книги по функциональному программированию?

Наверное, потому, что это принципиально ничего не меняет и ни на что не влияет. С практической точки зрения. Имхо.

Падение из-за нехватки памяти ни на что не влияет?

У каких именно лисперов, хотелось бы знать?

Наверное, молодой еще. Вон, выше я привел цитаты старичков.

Падение из-за нехватки памяти ни на что не влияет?

А они так часто падают (в смысле - проги на ФЯП)? Что-то не замечал. Во всяком случае не чаще, чем проги на ИЯП. Так что: в чём проблема-то?

PS: Проблемы утечек памяти не есть проблемы функциональной или императивной парадигмы, имхо.

Таких надо срочно на Clojure пересаживать :)

Лучше на хаскеле подержать чуток.

во-первых, что этот ГСМ делает в девеле? во-вторых, не орут об этом потому, что чистым функциональным программированием в том смысле, который вкладывает в него ОП, никто не занимается. в специфических статьях данный момент упоминается

с тем же успехом можно требовать печатать на первой странице любых книг по программированию максимальным кеглем «МАШИН ТЬЮРИНГА С БЕСКОНЕЧНОЙ ЛЕНТОЙ НЕ БЫВАЕТ». ну не бывает. ну и что?

Нет, я знал что типичные жабакодеры идиоты, но чтобы настолько.

Наверное потому, что чистое ФП это абстракция навроде сферического коня в вакууме? И вообще то практики это хорошо понимают, а теоретикам с ФП головного мосга... им все равно.

Ъ: У чистых функций всегда есть side-effects, которые выражаются в пожирании памяти и CPU.

Пожирание памяти и CPU не является побочным эффектом, т.к. не изменяет состояние haskell-среды.

Тут, правда, можно придраться к тому, что же есть состояние haskell-среды. Его можно определить, как совокупность всех объектов, не подлежащих удалению GC. Таким образом, чистая функция есть функция, которая не изменяет состояний существовавших на момент ее вызова объектов. На это не влияет ни потребление памяти, ни потребление CPU.

Если что сказал не так - поправьте, с хаскеллем знаком на уровне не намного выше, чем Hello, World.

Для того, чтобы говорить «связь между хаскельными функциями „на бумаге“ и кодом в исполняемом файле настолько условная», нужно таки быть практиком.

Та ну... это-ж не опыт

Знамя ФП это как тот пресловутый неуловимый Джо. Ладно хоть кому-то нужен.

Тоже так думал. Пока не прижало.

Может быть потому, что функциональное программирование - это не только чистота и отсутствие побочных эффектов вкупе со ссылочной прозрачностью

А что еще?

Функция как фёст-класс ситизен, очевидно же

Это я и в Питоне могу :)

но почему об этом не орут на первой странице каждой книги по функциональному программированию?

Потому что для той или иной абстрактной или реальной машины функция (процедура) это абстракция над кодом машины и её свойства изначально известны (например, временная и пространственная сложность). Чистая функция, с точки зрения такой машины, это та же функция, только с наложенными на неё дополнительными условиями (чистоты - отсутствия I/O операций). Понятно, что чистая функция будет обладать всеми общими свойствами функции обычной (временной и пространственной сложностью, например, или наличием аргументов и результата, и тому подобное), потому что это её разновидность. Точно так же чистая типизированная функция это функция с ещё более специфичными свойствами, а чистая типизированная тотальная (терминируемая) функция - ещё более специфичными. При этом то или иное ограничение функций (процедур) общего вида может быть эквивалентно понятию функции из какой-нибудь математической теории, например, понятию функции из теории рекурсивных функций.

То есть, вот человек изучает императивное программирование, знакомится с понятием функций-процедур, архитектуры, временной и пространственной сложности, потом, когда он знакомится с функциональным программирование, он узнаёт, что чистая функция это такая _функция_ (а функции реализованные на той или иной архитектуре всегда расходуют какие-то ресурсы), которая не имеет побочных эффектов (тут имеются в виду I/O операции, то есть просто накладываются _ограничения_ на функции), поэтому для одних и тех же значениях аргументов возвращает одни и те же значения.

В языке с неограниченными нетипизированными функциями (Scheme, Python) понятия чистоты, типизации и тотальности будут чисто дедуктивными, то есть умозрительными. В языке со статической типизацией (C, Java) умозрительными будут понятия чистоты и тотальности. В чистом языке со статической типизацией (Haskell, Clean) умозрительным будет понятие тотальности, но при этом все конструкторы термов не будут выполнять I/O операции, поэтому все сложные (индуктивно составленные) термы тоже не будут иметь побочных эффектов. В этом смысле чистота будет индуктивной. Операции I/O при этом могут быть составлены чистыми функциями как некая спецификация для выполнения рантаймом (как IO термы хаскеля, которые составляются монадическими комбинаторами, такой eDSL для I/O операций). В языках вроде Coq, Agda рекурсивные конструкции ограничены, поэтому функции являются тотальными (терминируемыми).

Вот, типы классов и GADT - это функциональное программирование или нет?

«Типовое» программирование :) От слова «тип». «Функциональное» - от слова «функция» (которая высшего порядка), всё что касается ФВП - анонимные функции, функции принимающие функции, функции возвращающие функции. Необходимая метатеория - нетипизированное лямбда исчисление. «Типовое», алгебраическое, тотальное - всё что касается типов (тоже высшего порядка). Метатеория - какое-нибудь типизированное лямбда исчисление. В пределе у нас будет программирование основанное на теории типов (MLTT) в котором типы и термы неразрывно связанны и изоморфны индуктивным множествам и тотальным рекурсивным функциям, утверждениям и доказательствам в логике высшего порядка, топологическим пространствам и классам гомотопий непрерывных отображений.

Это я и в Питоне могу :)

Python поддерживает ФП в ничуть не меньшей степени, чем CL.

Ну так тебе, как молодому, объясняю: У всяких этих Грэмов одни восторги на пустом месте по поводу лиспа. CL, вон, вообще больше ООП, чем ФП

больше ООП, чем ФП

Молодой молодому объяснил как молодому, похоже.

Вы хотите что-то добавить? Продолжайте

Черт, а я так надеялся узнать здесь о Common Lisp'е больше, про другие лиспы не знаю, а на CL пишу уже некоторое время, но тут такие гуру, шо куды мне

вообще больше ООП, чем ФП

Это не взаимоисключающие вещи.