Я правильно понимаю, что единственным определяющим признаком функциональной программы является отсутствие изменяемых переменных?

Здравствуйте, Аноним, Вы писали:

А>Я правильно понимаю, что единственным определяющим признаком функциональной программы является отсутствие изменяемых переменных?

START:
    Console.WriteLine("Hello, functional programming!");
    goto START;

Здравствуйте, nikov, Вы писали:

Хм... Мне кажется, тут такая вещь: императивной эту программу делает выделенная строка, оперирующая состоянием, а не goto, который просто эквивалентен бесконечной рекурсии.

N>

N>START:
N>    Console.WriteLine("Hello, functional programming!"); // << Imperative
N>    goto START;
N>

Для сравнения:

void Print()
{
    Console.WriteLine("Hello, functional programming!");
    Print();
}

Здравствуйте, Аноним, Вы писали:

А>Хм... Мне кажется, тут такая вещь: императивной эту программу делает выделенная строка, оперирующая состоянием, а не goto, который просто эквивалентен бесконечной рекурсии.

У меня есть вредная привычка неточно использовать терминологию. На самом деле, под "состоянием" я имел в виду переменные ("состояние" памяти), а не состояние потока выполнения программы.

То есть, WriteLine в итоге должен записать что-то в какие-то переменные, чтобы это вывелось на экран нашего абстрактного компьютера.

Если говорить о состоянии потока выполнения императивной программы, то, по-моему, оно является просто деталью реализации вычислителя, выполняющего программу. Если мы не будем менять никаких переменных, вычислитель вполне в праве не иметь никакого состояния.

Кроме того, как известно, любая программа с goto может быть преобразована в программу без goto по теореме структурного программирования.

Здравствуйте, Аноним, Вы писали:

А>Я правильно понимаю, что единственным определяющим признаком функциональной программы является отсутствие изменяемых переменных?

Единого определения нет, и скорее всего не будет. Более того, представления об ФП в каждом десятилетии свои. Часто даже отрицают то, что считалось незыблемым ранее. Ну, конфликт отцов и детей, да и диалектика Гегеля с Энгельсом

А так, вообще, отсутствие побочных эффектов и чистота. Только тут вырисовывается следующий конфуз. Фактические побочные эффекты можно эмулировать без формальных побочных эффектов (монады IO, ST). Тогда некоторые начинают сводить к требованию ссылочной прозрачности. Уже близко, но тут возникает такой фундаментализм, что некоторые горячие головы выбрасывают с водой и младенца с пеной у рта начинают завлять, что даже ocaml c clojure никак не являются функциональными, не то, что какой-нибудь там common lisp. Самое смешное, что находятся и такие, которые даже смеют сомневаться в том, что есть единое определение ссылочной прозрачности, ну ты понял..

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

Здравствуйте, Аноним, Вы писали:

А>Я правильно понимаю, что единственным определяющим признаком функциональной программы является отсутствие изменяемых переменных?

Это вряд ли. Раз уж мы хотим определить функциональное программирование, то в определении должны упоминаться функции.
А дальше варианты есть разные:
1) Программирование посредством математических функций. Которые как раз чистые и ссылочно-прозрачные.
2) Программирование с использованием первоклассных функций.

Приверженцы первого подхода — функциональщики-фундаменталисты, шииты. Они не считают Лисп с Окамлом ФП, наряжают женщин в черные чехлы и закидывают грешников камнями. Сторонники второго — сунниты, они менее экстремальны. Возможны и другие варианты, они оказываются где-то между этими двумя.

DM>Приверженцы первого подхода — функциональщики-фундаменталисты, шииты. Они не считают Лисп с Окамлом ФП, наряжают женщин в черные чехлы и закидывают грешников камнями. Сторонники второго — сунниты, они менее экстремальны. Возможны и другие варианты, они оказываются где-то между этими двумя.

самые ярые фундаменталисты -- иудеи. Занимаются только тем, что отвечают редуцированным запросом на запрос.

Здравствуйте, D. Mon, Вы писали:

DM>Раз уж мы хотим определить функциональное программирование, то в определении должны упоминаться функции.

Функции, в том числе первоклассные, есть и в императивных языках, так что это не может являться отличительным признаком функционального программирования.

Вот об этом и речь: похоже, единственное, что может позволить отличить императивную программу от функциональной — это отсутствие изменяемых переменных.

Здравствуйте, Аноним, Вы писали:

А>Функции, в том числе первоклассные, есть и в императивных языках, так что это не может являться отличительным признаком функционального программирования.

Одно дело просто иметь какие-то "функции", совсем другое — программировать исключительно посредством чистых функций. Это очень разные вещи.

A>отсутствие изменяемых переменных

Я так понял, выше вы и WriteLine отнесли к изменению переменных. В таком случае, ФП не существует вовсе, ибо программа без сайд-эффектов не делает ничего, ее нет смысла даже запускать. Сайд-эффекты присутствуют и поддерживаются всеми чистыми ФЯ общего назначения вроде Haskell, Clean, Idris и пр.

Здравствуйте, Аноним, Вы писали:
А>Я правильно понимаю, что единственным определяющим признаком функциональной программы является отсутствие изменяемых переменных?

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

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

Здравствуйте, Аноним, Вы писали:

Erratum:

А>Если мы не будем менять никаких переменных, вычислитель вполне в праве вправе не иметь никакого состояния.

Здравствуйте, Аноним, Вы писали:

А>Я правильно понимаю, что единственным определяющим признаком функциональной программы является отсутствие изменяемых переменных?

Я думаю, это зависит от определения. Вроде бы общепринятого нет. В МГУ меня учили когда то, что функциональный стиль программирования, это когда функция считается объектом первого класса. Например её можно передавать как параметр или возвращать как результат другой функции. А отсутствие изменяемых переменных это т.н. чистое функциональное программирование (pure).

Здравствуйте, vsb, Вы писали:
vsb>Я думаю, это зависит от определения...

система типов влияет, если значение считать функцией без параметров, то разницы нет.

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

Здравствуйте, D. Mon, Вы писали:

DM>Одно дело просто иметь какие-то "функции", совсем другое — программировать исключительно посредством чистых функций. Это очень разные вещи.

В каком смысле? Функции в императивном и функциональном программировании — это два принципиально разных объекта?

DM>Я так понял, выше вы и WriteLine отнесли к изменению переменных. В таком случае, ФП не существует вовсе, ибо программа без сайд-эффектов не делает ничего, ее нет смысла даже запускать. Сайд-эффекты присутствуют и поддерживаются всеми чистыми ФЯ общего назначения вроде Haskell, Clean, Idris и пр.

Вы имеете в виду, что чисто функциональный компьютер сделать невозможно и все равно в итоге где-то придется перейти к императивности? В каком-то смысле это камень в огород функционального программирования вообще. Но в данном случае нас это не интересует, так как речь идет о модели программирования. То, что в итоге результат работы функциональной программы будет использован в императивной среде, не мешает нам оставаться в рамках функциональной модели. Иначе, следуя вашим рассуждениям, (чистое) функциональное программирования вообще невозможно.

Здравствуйте, Аноним, Вы писали:

DM>>Одно дело просто иметь какие-то "функции", совсем другое — программировать исключительно посредством чистых функций. Это очень разные вещи.

А>В каком смысле?

Ключевые слова — "исключительно посредством".

А>Функции в императивном и функциональном программировании — это два принципиально разных объекта?

"Императивные" ф-и имеют мало общего с математическими. Возьмите определение функции из математики, попробуйте построить программу целиком из таких функций, почувствуйте разницу.

DM>>Я так понял, выше вы и WriteLine отнесли к изменению переменных. В таком случае, ФП не существует вовсе, ибо программа без сайд-эффектов не делает ничего, ее нет смысла даже запускать. Сайд-эффекты присутствуют и поддерживаются всеми чистыми ФЯ общего назначения вроде Haskell, Clean, Idris и пр.

А>Вы имеете в виду, что чисто функциональный компьютер сделать невозможно и все равно в итоге где-то придется перейти к императивности?

Нет. Я имею в виду, что чистое функциональное программирование включает в себя и работу с сайд-эффектами. И уже по вашему определению программы с вводом-выводом не являются ФП. Т.е. я указываю на проблему в вашем определении.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, D. Mon, Вы писали:

А>Вы имеете в виду, что чисто функциональный компьютер сделать невозможно и все равно в итоге где-то придется перейти к императивности? В каком-то смысле это камень в огород функционального программирования вообще. Но в данном случае нас это не интересует, так как речь идет о модели программирования. То, что в итоге результат работы функциональной программы будет использован в императивной среде, не мешает нам оставаться в рамках функциональной модели. Иначе, следуя вашим рассуждениям, (чистое) функциональное программирования вообще невозможно.

Ну, хорошо. Давайте рассмотрим подробнее.

Ошибка в том, что вы пытаетесь противопоставить функциональный подход императивному. Так делать нельзя. Это просто разные взгляды на то, как можно писать программы: либо рассматривать программу как вычисление, приложение и комбинацию функций, либо как строгое описание того, как должен работать компьютер. Здесь противопоставления нет.

Вообще, императивный подход раньше противопоставляли декларативному, но то было давно. Вообще, черно-белая картина мира — это не самая удачная идея. За этим лучше в политику или на сайт CNN и BBC. В реальности, часто нет границы, где можно сказать, в каком стиле написан код. На мой взгляд самый яркий контрпример — это макросы LOOP и ITER в Common Lisp, которые воплощают в себе и императивный, и декларативный, и функциональный подходы одновременно.

Если идем от функций, то попутно возникает требование чистоты как бы само собой. Просто с побочными эффектами трудно предсказывать поведение функций, особенно их комбинаций. Если есть чистота, то почему бы тогда не сделать язык ленивым? Чистоту обеспечивает ссылочная прозрачность, позволяя как раз вычислять лениво. А еще можно обнаружить, что ссылочная прозрачность дает много других плюшек, помимо ленивости.

Но как было замечено, без побочных эффектов нет никакого практического смысла в программировании. Парадокс в том, что побочные эффекты замечательно кодируются на чистом языке программирования.

В хаскеле для этого используется монада IO. Более того, она не противоречит ссылочной прозрачности. Фокус или гениальная идея в том, что мы просто вводим новый уровень косвенности. Мы не создаем сами побочные эффекты, а мы просто оперируем функциями, которые уже при своем выполнении будут создавать эти побочные эффекты. Похоже на тавтологию, но это не так, потому что язык программирования хаскель остается практически чистым и ссылочно-прозрачным.

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

С практической точки зрения побочные эффекты просто требуют явной декларации в сигнатуре функции. То бишь, там должен быть явно прописан IO или его производная. Отсюда, кстати, идет второе условное понимание чистоты: нет зависимости от IO. Условное, потому что не является формально строгим, и эта двойственность в толковании чистоты по моим наблюдениям сильно затрудняет понимание хаскеля начинающими. Люди откровенно путаются, особенно, когда переходят к изучению монадических трансформеров, где условное понимание нечистоты уже не работает. Формальная же чистота, как правило, соблюдается, даже с функциями, создающими побочные эффекты в IO.

Продолжим далее о связи императивного и функционального.

Итак, в хаскеле побочные эффекты описываются в монаде IO. Соответствующие вычисления еще называют "императивными".

Казалось бы, все просто. Вот, есть код с IO, а есть код без IO. Значит, найден святой Грааль, и можно поставить знак равенства между IO == императивный? Но не тут и было!

В хаскеле есть такая штука, как "рекурсивная нотация do". Это, когда можно задавать монадические вычисления практически в произвольном порядке, особо не заботясь о последовательности вычисления. Главное, чтобы вычисление было конечным, т.е. когда-нибудь заканчивалось.

Метод основан на идее о неподвижной точке, и его реализация обычно существенно завязана на ленивости. За деталями искать по слову MonadFix. Там сплошное ФП. Суть в том, что по заданной функции методом последовательного приближения находим сам результат функции, не зная ее аргумента. Просто аргумент вычисляем лениво.

Так вот, апофеозом всего этого является то, что IO является экземпляром класса типов MonadFix. На простом языке это означает, что "императивные" вычисления IO можно задавать рекурсивно, особо не заботясь о порядке вычислений. Главное, чтобы вычисления заканчивались. А как я написал выше, MonadFix — это чистейшее функциональное программирование.

Ничего не настораживает? Правильно. Ведь один из главных принципов императивного программирования: рассматривать программу как последовательность действий, а мы от этого уходим, позволяя "императивные" вычисления IO задавать чуть ли не в произвольном порядке. Впрочем, если у нас там идет запись в файл, или чтение из нее, то может получиться фигня, но нет совершенства.

В итоге получается, что не все так просто на самом деле.

Здравствуйте, Аноним, Вы писали:

А>Я правильно понимаю, что единственным определяющим признаком функциональной программы является отсутствие изменяемых переменных?

Да, так и есть.

Здравствуйте, D. Mon, Вы писали:

DM>"Императивные" ф-и имеют мало общего с математическими. Возьмите определение функции из математики, попробуйте построить программу целиком из таких функций, почувствуйте разницу.
Хм. Вы не могли бы эту разницу пояснить подробнее? А то Чёрч с Тьюрингом её не заметили.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, D. Mon, Вы писали:

DM>>"Императивные" ф-и имеют мало общего с математическими. Возьмите определение функции из математики, попробуйте построить программу целиком из таких функций, почувствуйте разницу.
S>Хм. Вы не могли бы эту разницу пояснить подробнее? А то Чёрч с Тьюрингом её не заметили.
Ну а как ты из стдина считаешь символ с помощью "ФУ́НКЦИЯ, в математике — Соответствие y = f (x) между переменными величинами, в силу которого каждому рассматриваемому значению некоторой величины x (аргумента, или независимого переменного) соответствует определенное значение другой величины y (зависимой переменной, или функции)". Т.е. то, что ты считаешь я не сомневаюсь, например подействовав оператором стдин(стдоут, время) на нулевой элемент, но это будет психоделика та еще.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, D. Mon, Вы писали:

DM>>"Императивные" ф-и имеют мало общего с математическими. Возьмите определение функции из математики, попробуйте построить программу целиком из таких функций, почувствуйте разницу.
S>Хм. Вы не могли бы эту разницу пояснить подробнее? А то Чёрч с Тьюрингом её не заметили.

А граница как раз между Черчем с Тьюрингом и пролегает, образно говоря.
В математике функции чистые (результат зависит лишь от аргументов, кроме вычисления результата ничего не "делается") и ссылочнопрозрачные (можно смело делать всякие подстановки). Вот когда все программирование делается такими функциями — это чистое ФП. А в машине Тьюринга ничего похожего не наблюдается.