Обсуждение:Функциональное программирование

Категории

Заголовок темы этого обсуждения был добавлен участником Nashev.

Не знаю, по-моему для "Функциональное программирование" логична именно категория "Программирование", которая затем уже включается в "Информатика". Но если Вы настаиваете на прямом включении, тот давайте так и сделаем, зачем по мелочам спорить. MaxiMaxiMax 14:02, 1 Окт 2004 (UTC)

Дело в том, что сама теория функционального программирования является больше абстрактной математической теорией, что вовсе должно относить её в дискретную математику (у нас в ВУЗе этот курс читается именно в разряде «Дискретная математика»), потом только в «Кибернетику», и только в последний случай — в «Информатику». Я не очень знаком с системой классификации на Википедии, поэтому тут больше буду полагаться на Ваш опыт (тем более, Вы заметили, что категоризацией статей я особо не занимаюсь, оставляя это дело на Администраторов). Но собственно свою точку я объяснил. Dark Magus 14:45, 1 Окт 2004 (UTC)

А вот и зря не ставите, администраторам тоже хочется статьи писать, а не только за всеми расставлять категории и интервики. Посмотрите как она устроена, надеюсь что она интуитивно понятна. Если видите что её нужно изменить — давайте менять. В области информатики она на мой взгляд уже действительно несколько запутана. MaxiMaxiMax 02:53, 2 Окт 2004 (UTC)

Я постепенно учусь писать статьи в полном соответствии с требованиями Википедии. Если Вы заметили, то во многих новых статьях, которые я сделал, я уже самостоятельно поставил категории. Так что не серчайте, всё будет, только не сразу. Dark Magus 11:43, 3 Окт 2004 (UTC)

Рекурсия

Что-то я не понимаю данное утверждение:

Отсутствие циклов для промышленных программ является очень серьёзным ограничением — далеко не все виды рекурсии могут быть автоматически преобразованы в цикл.

Зачем рекурсии преобразовывать в цикл? MaratIK 08:17, 18 августа 2008 (UTC)

Затем что каждый «правильный» рекурсивный вызов требует выделения памяти для сохранения адреса перехода и значений локальных переменных выполняемой функции. Промышленные программы, предназначенные для непрерывной работы, работают очень часто в режиме бесконечного цикла по потоку входных данных. В чисто функциональной программе для реализации бесконечного цикла можно применить только бесконечную рекурсию. Через какое-то время программа неизбежно исчерпает стек и аварийно завершится. Чтобы этого не произошло — необходимо преобразовать рекурсию в цикл. Если рекурсия в целом окажется достаточно сложной, либо компилятор окажется недостаточно интеллектуальным — получаем самопадающую программу с утечкой памяти. Причём даже не обязательно, чтобы рекурсия была логически бесконечной — есть масса алгоритмов, в которых глубина рекурсии окажется чрезмерной. Самое неприятное в этом — то, что корректность работы такой программы будет зависеть от совершенства оптимизационных возможностей транслятора. То есть откомпилировали одним — пашет. Другим — не пашет. Даже банальный QuickSort в самом худшем случае приводит к такой глубине рекурсии, которую слабые машины могут не потянуть. --dm ^{обсужд.} 09:01, 18 августа 2008 (UTC)

Что бы скрывать не функциональные "вводы-вывод" придуманы монады. Всё остальное в равной степени относится к любым языкам программирования. 95.83.165.13 19:58, 26 июля 2011 (UTC)hello

Хвостовую рекурсию любой компилятор преобразует в итерацию-цикл. --Claymore 10:10, 18 августа 2008 (UTC)

Обычно цикл работает эффективнее рекурсии. Но если рекурсия хвостовая (en:Tail recursion), то её можно преобразовать в аналогичный цикл. Так что циклы в функциональных языках есть. --Claymore 10:10, 18 августа 2008 (UTC)

В том-то и дело, что В ЯЗЫКАХ — нет. Точнее, те, что есть (например, в Лиспе) — нарушение принципа функционального программирования. Преобразование хвостовой рекурсии в цикл — это средство оптимизации программы транслятором. Ни в одном языке нет языкового требования «такой-то вид рекурсии обязательно будет преобразован транслятором в цикл». Получается лоторея — стоит перенести программу на другой транслятор того же языка, и невозможно гарантировать её корректную работу. О чём и сказано в статье. Можно сказать более развёрнуто, но я полагал всё это общеизвестными истинами… --dm ^{обсужд.} 16:03, 18 августа 2008 (UTC)

Вообще-то есть. Любая реализация Scheme, например, должна преобразовывать хвостовую рекурсию в итерацию. --Claymore 16:11, 18 августа 2008 (UTC)

В стандарте языка Лисп это есть? Есть точное определение, позволяющее на глаз определить, какая именно рекурсия преобразуется, а какая — нет? Если да — значит, ура, есть такой язык. Если нет — увы, нет.--dm ^{обсужд.} 17:21, 18 августа 2008 (UTC)

Это есть в стандарте Scheme, одного из диалектов Lisp: proper tail recursion. --Claymore 17:33, 18 августа 2008 (UTC)

Интересно. Я этого не знал. Тогда уместно внести уточнение в статью. --dm ^{обсужд.} 18:15, 18 августа 2008 (UTC)

Рецензия 19 января 2009 года

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Более доработанная статья, интересует критика и мнения о том, что нужно доработать или изменить. --AIupdated 7:58, 19 января 2009

• Для начала проставьте АИ вместо тегов ^{[источник?]} потом уже можно дальнейшей вычиткой заняться. goga312 19:31, 19 января 2009 (UTC)

ЧЗН?

Джон МакКарти, 1958, множество его потомков, наиболее современные из которых — Scheme и Common Lisp 178.126.38.175 16:17, 17 мая 2011 (UTC)

входит ли javascript в список функциональных языков?

сабж

msangel 19:45, 2 ноября 2011 (UTC)

О здравом смысле и правках на скаку

Возьмём предложение: "Мясной полуфабрикат, частично состоящий из животных продуктов, содержит в себе и растительные продукты." Не кажется ли оно участникам вполне разумным? Или в конце нужно поставить шаблон "Нет АИ"? Хотя зачем? Ведь в самом предложении постулируется (т. е. вводится самим автором), что продукт лишь частично животный, а значит в нём есть и растительные компоненты.

Однако, некоторым участником хотелось бы и это подтвердить АИ, как например в таком предложении из этой статьи: "Тем не менее, языки программирования обычно представляют собой гибрид нескольких парадигм программирования, поэтому «большей частью императивные» языки программирования могут использовать какие-либо из этих концепций."

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

Вот, Участник:Be nt all не только откатил правку по удалению такого шаблона, т. к. ему она не понравилась, но и отменил всё остальные полезные изменение разом! Т. е. не понравилось что-то одно, но у него нет времени разбираться и читать, поэтому он рубанул шашкой сразу по всем. Возможно, он — хозяин Википедии, и мы плебеи своими правками ему просто мешаем? Правда, приписал, что завтра сделает нужные и умные правки сам! (Которые, видимо, уже никто ни-ни... Ибо сделаны САМИМ!) Однако, прошло 10 дней. Видимо, некогда с нами плебеями дискуссии вести. Отменил, а там рабы и забудут...

Именно из-за такого жёсткого и недружелюбного стиля общения между участниками русскоязычной Википедии я и покинул проект в качестве автора/редактора. Но тут случайно исправил данную статью. Но тут же убедился, что не стоит ничего править и писать в Википедию. Пусть живёт своей камерной жизнью местных "полубожков". (Кстати, в большинстве случаев в англоязычной ВП такого не наблюдается. Там люди понимают, что ВП не их собственность в части наблюдаемых статей, а общественный проект.) Всем привет! ;) --= APh =-- (обс.) 03:04, 30 августа 2017 (UTC)

• Остальные полезные правки, это нажатие кнопки викифицировать? Я что-то там ничего другого не увидел. Источник (реально полезный читателю) я добавлю, пока руки до просмотра источников просто не дошли. Пока королём тут себя чувствуете вы. Ну или наоборот, ниспровергателем. Вот не дали вам убрать запрос источников (а это вообще не поощряется, если вы не в курсе), так вы тут целое либретто оперы написали. Ну-ну. —be-nt-all (обс.) 03:18, 30 августа 2017 (UTC)

Надо упомянуть фичи подхода

Странно, что не упомянуты такие фичи функционального программирования, как замыкания, лишь вскользь упомянуты анонимные функции, каррирование (карринг), мемоизация, монады. Мне одному кажется, что в статье было бы уместным иметь компактный перечень всего такого? Под заголовком "Связанные понятия" или чем-нибудь таким? --Nashev 14:15, 27 февраля 2019 (UTC)

О функциях

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

Функция "умножить А на Б", А=2, Б=2 - может получиться в начале иполднения программы 3, а в конце 5? Это серьёзно? Но ведь это, как и любое другое подобное, говорит лишь о том, что язык негодный, использовать нельзя, надо удалить и забыть. Разве нет? Michael MM (обс.) 15:49, 20 октября 2021 (UTC)

• В этой статье надо постоянно читать между строк, такая тут тема абсурдная. Под входными параметрами имеются ввиду те, что переданы самым примитивным образом через список задекларированных переменных, что описан в объявлении функции. А если это указатель, внешняя переменная, глобальная переменная или указатель на структуру this, то всё! функция использует оттуда значение и результат будет другой. например, а умножить на б и умножить на this->dt. если this->dt изменится, то результат будет другим. При этом потом утвеждается, что кеширование результата якобы невозможно, как будто-то компилятору или интерпретатору ничего не известно о глобальной переменной или об указателе this. Надеюсь что в настоящих авторитетных источниках такого бреда нет, и там сказано что эта парадигма просто для помощи рассеянным программистам. Как бы найти такую литературу? Gnuzz (обс.) 03:27, 17 марта 2023 (UTC)