Википедия:К объединению/23 ноября 2015

• Начинающим
• Сообщество
• Порталы
• Избранное
• Проекты
• Запросы
• Оценивание

К объединению: 21 апреля 22 апреля 23 апреля 24 апреля 25 апреля 26 апреля 27 апреля 14 апреля 15 апреля 16 апреля 17 апреля 18 апреля 19 апреля 20 апреля 7 апреля 8 апреля 9 апреля 10 апреля 11 апреля 12 апреля 13 апреля 31 марта 1 апреля 2 апреля 3 апреля 4 апреля 5 апреля 6 апреля

 | 

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

Язык функционального программирования и Функциональное программирование

По-моему, давно пора. У первой отсутствуют иноязычные эквиваленты. Начерно можно подразделом, а потом уже дорабатывать. Arachnelis 20:24, 23 ноября 2015 (UTC)

• Объединить, согласен с номинатором, содержимое перенести во вторую статью (если есть что переносить) -- Dgeise 09:30, 6 декабря 2015 (UTC)
• Объединить, но аккуратно, так как статья претендовала в хорошие, и поэтому её будет проще довести до хорошей, если просто так не сливать всё подряд. РоманСузи 17:22, 30 декабря 2015 (UTC)

Итог

Предложение об объединении поддержано на обсуждении, к тому же есть сомнения в принципиальной возможности разделить две сущности. Технически объединено следующим образом: со статьи Язык функционального программирования установлено перенаправление на статью Функциональное программирование с сохранением истории правок; так сделано по трём соображениям: (1) вторая статья создана на полмесяца раньше; (2) предмет второй статьи заявлен чуть более общо; (3) к первой статье есть давняя претензия к стилю изложения (установлен шаблон {{стиль}} в шапке статьи). Тем не менее, можно для развития оставшейся статьи пользоваться текстами первой статьи (достаточно будет в комментарии к правке указать oldid=74722563 — ключ, по которому можно будет найти авторов текста, bezik° 16:28, 1 января 2016 (UTC)

Комментарий

Пока итог не оспариваю (рано), но в будущем статьи однозначно подлежат разделению. Смотрим с одной стороны на книги вроде Functional JavaScript by Michael Fogus ISBN 978-1-4493-6072-6, Functional Programming for Java Developers: Tools for Better Concurrency, Abstraction, and Agility by Dean Wampler ISBN 978-1-4493-1103-2 и прочие книги про Functional Programming in Java/JavaScript/C# (не буду перечислять их все, они легко ищутся) и, как апогей, Functional C by Pieter H. Hartel & Henk Muller ISBN 978-0-201-41950-4 и, с другой стороны, книги вроде классического труда Саймона Джонса The Implementation of Functional Programming Languages или, скажем, The optimal implementation of functional programming languages ISBN 978-0-521-62112-0 и всё станет ясно. Хотя тесную связь одной темы с другой и плавность перехода между ними нам покажет хотя бы вот такая статья. --be-nt-all 19:25, 1 января 2016 (UTC) И, кстати, статьи вроде последней, намекают на возможность ещё и отдельной статьи функциональное программирование на императивных языках --be-nt-all 23:39, 1 января 2016 (UTC)

• Вообще-то «программирование на одном языке в стиле другого» описывается в статье «Идиома (программирование)». Если она разрастётся, то, как водится, разделы выносятся в отдельные статьи. Да, я и сам предпочитаю отделять «техническое (оно же чистое, оно же ссылочно-прозрачное) ФП» от «ФП-стиля» — особенно спорно эти категории сталкиваются в контексте моего любимого ML. Но я сильно сомневаюсь, что статью про «ФП-стиль» удастся вменяемо по всем правилам написать. Arachnelis 18:50, 2 января 2016 (UTC)

• Но если вы всерьёз настроены попробовать, то заранее подкину материал: John Carmack about Functional programming in C++ Arachnelis 18:58, 2 января 2016 (UTC)

• Но к обсуждаемому слиянию это отношения не имеет. «Функциональное программирование» — это то же, что «функциональная парадигма программирования», а парадигма объединяет технические свойства и идиомы. Техническое ФП (как свойство языка — то, что ещё как-то можно отнести к «Язык функционального программирования») — это не что иное как ссылочная прозрачность, которую на русском ещё только предстоит сделать. Касательно статьи на «fprog», то автор делает множество типичных для поверхностно знакомых с темой ошибок. Вывод типов имеет к ФП исчезающе малое отношение — в конечной версии языка нового поколения successor ML нам очень повезёт, если вывод будет хотя бы в ограниченных контекстах, так как семантика системы типов языка будет основана на полной Системе F-омега с подтипами (Система F<) и первоклассным полиморфизмом, а это тихий ужас для вывода. (upd: хотя далеко ходить не надо — в Хаскеле при использовании RankNTypes о выводе типа тоже можно забыть.) «Хиндли-Милнер» — это не алгоритм, как многие говорят, а система типов, основанная на Системе F и опционально включающая в себя «Algorithm W» для вывода типов. Гарантия TCO никак не связана с чистотой языка — Scheme и SML её гарантируют, но не являются чистыми. И так далее. Надеюсь, что этот оффтопик для данного обсуждения пригодится в работе над многими статьями. upd: Зато не все реализации Common Lisp гарантируют TCO, из-за чего многие называют его «императивным», и не спасает даже тот факт, что Лисп является самым прямым воплощением лямбда-исчисления среди всех «функциональных языков». Ну и как при таком кавардаке энциклопедически провести разделение согласно данному топику? Arachnelis 21:28, 2 января 2016 (UTC)

• Правда Лисп? После прочтения Джона Харрисона у меня сложилось впечатление, что ML таки к λ-исчислению поближе (как прямое воплощение последнего он описывает предшественник ML-а ISWIM) но ему мешают энергичные вычисления, и Haskell (ну, или Lazy ML) в этом плане выглядят получше. --be-nt-all 16:45, 3 января 2016 (UTC)

• Неотъемлемой частью лямбда-исчисления и Лиспа являются пары Чёрча, образующие S-выражения. Они непосредственно есть только в Лиспе, а в потомках ISWIM они уже эмулируются (создаются ручками) через ADT, которых в чистом лямбда-исчислении нет. Но таки «a list» — это не совсем S-выражение, ибо quote/antiqoute/etc теряется (upd: хотя частные надстройки, конечно, возможны — Sml/NJ Quote/Antiquote и Template Haskell — но по громоздкости реализации эти решения и сравнивать с Лиспом нельзя). Переход от Лиспа (чистого лямбда) к ML (типизированному лямбда) делается с целью обеспечения типобезопасности и оптимизации, но ценой потери концепции «код-как-данные» (en:homoiconicity). Ну это насколько я знаком с темой, мож где и упустил чего. Arachnelis 21:42, 3 января 2016 (UTC)
• Что касается ленивости, то тут я уже готов до хрипоты спорить, что оно не является требованием к «функциональности». По одной банальной причине — чтобы в ML сделать ленивость, надо просто вместо «Cons(hd,tl)» писать «Cons( hd, fn () => tl )». Более того, Paulson описывает три степени ленивости списков, которые можно так вот делать по своему усмотрению. В терминах «стиля» ленивость — это просто один дополнительный глагольный уровень — вместо «посчитать» идёт «убедиться в необходимости, и тогда уже посчитать». Arachnelis 18:35, 7 января 2016 (UTC)