Оказалось, что в мои должностные обязанности входит подготовка докладов

Докладов я, правда, раньше не делал и на публике не выступал, если не считать участия в школьной постановке "Красной шапочки". Так что проблема

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

Хотелось бы, соответственно, сделать доклад о чем-то таком, что интересно мне самому — например, об ФП. Но так как конференция не специализированная, то доклад должен быть в известной степени "адаптированным". И вот что-то у меня кризис идей.

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

Заранее спасибо.

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

Ну, предже всего -- для чего оно вообще нужно.
Т.е. тема "Преимущества и недостатки функционального подхода к программированию".

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

MZ>Ну, предже всего -- для чего оно вообще нужно.
MZ>Т.е. тема "Преимущества и недостатки функционального подхода к программированию".

В принципе логично. Ну а какие недостатки вы бы сами привели?

On 06/25/2012 11:00 AM, Воронков Василий wrote:

> В принципе логично. Ну а какие недостатки вы бы сами привели?

Может сразу уж и доклад за тебя сделать ?

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

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

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

MZ>On 06/25/2012 11:00 AM, Воронков Василий wrote:
>> В принципе логично. Ну а какие недостатки вы бы сами привели?
MZ>Может сразу уж и доклад за тебя сделать ?

Ну, положим, тема бы называлась "Недостатки ФП". Тогда бы возражений не возникало? А намерения у меня тем не менее были бы не менее гнусные. Просто я очень честный человек.

MZ>Нестандартный подход к программированию, другая модель вычислений -- язык не
MZ>является усложнённой машиной Тьюринга, там нет последовательности императивных
MZ>действий.
MZ>Вследствии этого -- сложность в реализации тривиальных опрераций, которые легче
MZ>всего выражаются в императивной логике.

Ну да, если 2+2 через чёрч энкодинг описывать. А серьезно?

> Ну да, если 2+2 через чёрч энкодинг описывать. А серьезно?

НУ 2+2 вполне легко делается и там, и там.
А вот что-то более императивное -- нет.
Я не могу сейчас придумать хороший пример.
Традиционно вроде бы операции ввода — вывода сложны для FP.

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

>> Ну да, если 2+2 через чёрч энкодинг описывать. А серьезно?

MZ>НУ 2+2 вполне легко делается и там, и там.
MZ>А вот что-то более императивное -- нет.
MZ>Я не могу сейчас придумать хороший пример.
MZ>Традиционно вроде бы операции ввода — вывода сложны для FP.

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

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

Тут дело в первую очередь не в эффективности, хотя это тоже важно,
а ещё и в трудности программирования. Часто это просто вгоняет людей в
ступор -- как же писать такую программу ? Это тоже важно.

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

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

Народ «боится» ФП, и, если у тебя есть такая возможность, его надо продвигать, но для этого его надо показывать так, чтобы императивным программистам было не страшно.

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

ВВ>Ну да, если 2+2 через чёрч энкодинг описывать. А серьезно?

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

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

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

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

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

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

ВВ>>Ну да, если 2+2 через чёрч энкодинг описывать. А серьезно?

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

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

ФЯ — это языки высокого уровня. Смысл как раз в том, чтобы не писать эти алгоритмы так, как они пишутся на императивных языках. Тема производительности вообще довольно скучная, чтобы в сотый раз ее перетирать. Я должен написать код так, чтобы он красивый, чистый и декларативный, а компилятор должен его компилировать так, чтобы он был быстрый.

Это, кстати, уже отчасти работает.

В чистом ленивом ФЯ, к примеру, вообще все эти ваши О-нотации уже не работают. Вернее, работают не совсем так как вы ожидаете. Вот положим, я хочу получить минимальный элемент в списке. Я напишу так:

min = head (qsort xs)

Какова итоговая сложность?

А>Ну и еще есть такая очевидная проблема: если мы не можем ничего менять, мы должны делать копии всего. В чисто функциональном языке без дополнительных ухищрений происходит экспоненциальный взрыв количества операций и объема памяти. На практике это с горем пополам решается ad hoc.

Предпосылка неверна, соответственно, и следствие тоже.

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

Задачи, которые решаются с помощью хэш-таблиц, можно решать с помощью, например, хэш-таблиц.

А профит от программирования на ФЯ один — программирование на высокоуровневом языке. На C# вот тоже нельзя данные по регистрам вручную распихивать — и ничего.

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

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

Самое главное — показать что именно даст использование ФП в реальных проектах по сравнению с императивными языками. Нужен просто набор success story.

On 06/28/2012 11:52 AM, Аноним 666 wrote:

> чисто функционально обойти граф? Но, главное, в чем профит от функционального
> программирования на таких (базовых для программирования) задачах?

Так если на каких-то задачах профита нет, то не надо их решать средствами FP.
Вот в том и проблема, чтобы человек ЗАДАВАЛ себе такие вопросы как задаёш ты.

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

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

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

Кстати, ленивость — это вообще-то уже хак, это уже замазывание выбоин в концепции ФП. Причем этот хак врожденно императивен.

ВВ>ФЯ — это языки высокого уровня. Смысл как раз в том, чтобы не писать эти алгоритмы так, как они пишутся на императивных языках. Тема производительности вообще довольно скучная, чтобы в сотый раз ее перетирать. Я должен написать код так, чтобы он красивый, чистый и декларативный, а компилятор должен его компилировать так, чтобы он был быстрый.

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

ВВ>min = head (qsort xs)

ВВ>Какова итоговая сложность?

Я думаю, что в данном случае ленивость не влияет на асимптотику. Она может влиять разве что на амортизированную оценку.

Так что, господа из секты функционального спасения, может, кто-то вместо того, чтобы улыбаться дебильной улыбкой скажет мне, наконец, как выглядит алгоритм поиска всех кратчайших маршрутов в чисто функциональном виде. Если нет — слив защитан. И утверждение г. Воронкова о полном отсутствии проблем в ФП объявляется глупостью и непониманием основных концепций программирования.

Г-ну DMon'у показалось смешным мое сообщение. На своем сайте г. DMon пишет о себе:

Религия
С детства испытывал интерес к буддизму, а весной 2000-го года решил познакомиться с ним поближе, о чем не жалею. Начал изучать и практиковать, с тех пор считаю себя буддистом. Весной 2001-го принял прибежище у ламы Оле Нидала и с тех пор практикую в линии Карма Кагью.

То есть, на него можно не обижаться. Ок, понятно.

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

А>Ладно, а как чисто функционально получить тот же результат, который дает алгоритм Дейкстры? Ну или хотя бы просто граф обойти? Я даже где-то видел это на самом деле. Это было основано на ленивости и было вырвиглазно по сравнению с императивным вариантом.

В Haskell используются inductive graphs. В пакете реализован алгоритм Дейкстры. В статье Inductive Graphs and Functional Graph Algorithms рассказывается в том числе и об этом алгоритме. Асимптотика там хуже не в logN, что было бы, если бы алгоритм был реализован для straightforward графов.

Обходы тоже есть, в той же библиотеке. Плюс, для многих структур можно использовать zipper. Вот, например, есть замечательная статья An Applicative Control-Flow Graph Based on Huet's Zipper.

А>Кстати, ленивость — это вообще-то уже хак, это уже замазывание выбоин в концепции ФП. Причем этот хак врожденно императивен.

Раскройте, не очень понятно — почему замазывание и почему императивен.

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

А>Так что, господа из секты функционального спасения, может, кто-то вместо того, чтобы улыбаться дебильной улыбкой скажет мне, наконец, как выглядит алгоритм поиска всех кратчайших маршрутов в чисто функциональном виде. Если нет — слив защитан. И утверждение г. Воронкова о полном отсутствии проблем в ФП объявляется глупостью и непониманием основных концепций программирования.

Глупостью является вот это:

ленивость — это вообще-то уже хак, это уже замазывание выбоин в концепции ФП. Причем этот хак врожденно императивен.

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

Клоун в маске тролля. Забавно, да.

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

DM>Клоун в маске тролля. Забавно, да.

Я? Спасибо за еще одно оскорбление. Даже если я был неправ, вы могли бы написать, где я неправ или пройти мимо.

А просто ставить смайлик на сообщении и ничего не отвечать — это оскорбление. Это как если бы я вам что-то сказал, а вы бы ничего не ответили и лишь надменно усмехнулись. Хотя в жизни вы бы так не сделали из-за боязни получить по лицу.