ФЯП

Не тру, у фяп читабельность больше. Покури onLisp.

"The aims of functional programming may show more clearly when
contrasted with those of the more common approach, imperative
rogramming.

A functional program tells you what it wants; an imperative program
tells you what to do. A functional program says “Return a list of a and
the square of the first element of x:”
(defun fun (x)
(list ’a (expt (car x) 2)))

An imperative programs says “Get the first element of x, then square it,
then return a list of a and the square:”
(defun imp (x)
(let (y sqr)
(setq y (car x))
(setq sqr (expt y 2))
(list ’a sqr)))"

> ну и если серьезная реализация будет нечитаемой - где же фича хаскелла?

Быстрое прототипирование. Можно очень быстро набросать приемлимого качества решение, можно убедиться, что работает, а потом, погоняв профайлер, заоптимизировать узкие места, сделав только их нечитабельными (но с большим количеством комментариев - Literate Haskell рулит).

> Не тру, у фяп читабельность больше.

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

Здравствуй дерево!

Сказать-то есть чего по теме, или как обычно - взбзнул и в кусты?

читабельность - синоним выразительности, тоесть показатель простоты восприятия смысла написанного кода, анонимус, на пост которого я отвечал, писал, что серьезная реализация quicksort будет не сильно выразительней c++, к этому и вопрос мой был

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

да собсно пока я ваял свой пост, ответ уже появился, сенк, пойду еще про фп почитаю

> Здравствуй дерево!

Папа? Карло? Неужели это ты?!?

> Сказать-то есть чего по теме, или как обычно - взбзнул и в кусты?

А что не по теме то? Попробуй написать настоящую быструю сортировку читабельно. На любом языке. Независимо от языка какашка получится.

> всегда ли фп рулит по выразительности и какие такие места могут быть, где он нерулит

Не всегда, но часто.

Суровая оптимизация сложных алгоритмов по скорости и памятежору - не та область, где ФП рулит. Но зато тут рулит метапрограммирование на макросах.

Вообще есть много задач, где ФП не рулит: логическое программирование, программирование автоматов, агентное программирование, параллельное программирование.

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

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

Классно ты Lisp описываешь, я аж облизнулся :)

> какие все вежливые, аж противно :D

Не вежливости ради, а выживания для: скору уже так понизили, что полагаю скоро забанят :)

> Вообще есть много задач, где ФП не рулит: логическое программирование, программирование автоматов, агентное программирование, параллельное программирование.

Почему ФП не рулит для параллельного программирования ?

Может быть, приведёшь пример? Скажем, те самые пять строчек на питоне?

Потому что я, например, уверен, что как раз эта задача решится на хаскеле моментально. Берусь показать.

> Почему ФП не рулит для параллельного программирования ?

Потому что лямбда-исчисление является частным случаем пи-исчисления, но никак не наоборот.

Вообще-то реализация пролога в лиспе занимает афаик 140 строчек c коментариями. Так что опять анонимус безрезультатно взбзнул.

Программирование автоматов - назови хоть 1 причину почему "не рулит". Ато опять что-то завоняло. По большому счету программа на функциональном языке куда ближе к конечному автомату, чем императивное угребище.

Агенты - с какого банана тут-то не рулит? И чего в них такого мистического, ась? Давай расскажи, просвяти темноту пока я не выбрал лисп для своего агентного workflow.

Параллельное программирование. Таже песня. MPI для кого придумали?

В сухом остатке от поста - H2S.

С добрым утром буратино! Эрланг уже что, не функциональный язык???? =))))

Нет конечно же. Совсем не функциональный. У каждого потока там есть состояние.

> Вообще-то реализация пролога в лиспе занимает афаик 140 строчек c коментариями.

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

> Программирование автоматов - назови хоть 1 причину почему "не рулит".

Эффективность. Автомат имеет состояние. Если его завернуть в монаду, то теряется сильно производительность.

> Агенты - с какого банана тут-то не рулит? И чего в них такого мистического, ась?

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

> Давай расскажи, просвяти темноту пока я не выбрал лисп для своего агентного workflow.

Я тоже Лисп использую для агентного программирования. Но ведь он не чисто функциональный.

> Параллельное программирование. Таже песня. MPI для кого придумали?

Что в MPI функционального?

Заданее на дом: придумать чисто функциональную модель обмена сообщениями (в работы Р. Милнера не подглядывать!). Показать, как сложность модели зависит от числа элементов в ней. Попытаться изобразить в рамках модели классическую задачу "обедающих философов".

P.S. По поводу пролога: советую сравнить чисто функциональную унификацию (например, как она реализована в том прологе, который идет с Hugs), и разрушающую унификацию в машине Уоррена (например, gprolog).

> Расскажите про ФЯП

Вызываем дух Профессора?

> придумать чисто функциональную модель обмена сообщениями (в работы Р. Милнера не подглядывать!).

Для не осиливших самостоятельно глупых школьников ссылку на почитать можно? Google не помог.

>>Так шашечки -- это и есть выразительность.

>ну не сказал бы, чем меньше код тем легче сопровождать и тем меньше глюков

Тогда perl заруливает всех. В нём можно обойтись знаками препинания.

Nemerle? pravda eto kazhetsya ne ot Microsoft

> http://www.softcraft.ru/paradigm/fp/whyfp.shtml

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

У меня дежа-вю, или это описание классических юниксовых пайпов?

> Этот метод называется "ленивыми вычислениями"

Значит ли это, что в sh тоже реализуются "ленивые вычисления"?

>> ну не сказал бы, чем меньше код тем легче сопровождать и тем меньше глюков

> Тогда perl заруливает всех. В нём можно обойтись знаками препинания.

Имеет значение не количество байт, а скорее, количество синтаксических единиц. Грубо говоря, количество узлов в AST. Пол Грэм когда-то на эту тему рассуждал: http://paulgraham.com/power.html.

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

>Нет конечно же. Совсем не функциональный. У каждого потока там есть состояние.

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

> Тогда perl заруливает всех. В нём можно обойтись знаками препинания.

А он и заруливает, при желании. Мультипарадигменный язык (императивное, функциональное, обьектно-ориентированное и, местами, логическое программирование), с поддержкой макропрограммирования (source filters могут менять как синтаксис так и семантику языка), чего еще надо?

Еще бы не был он таким извращенным, да работал пошустрее...

В Perl 6 все украсят и упростят, правда, но он в готовом к рядовому использованию виде вряд ли выйдет раньше пробуждения Ктулху.

Ну, например, нормальную типизацию. Хотя бы типобезопасность; о статической типизации я пока молчу. Лямбду, без которой о функциональном программировании говорить не приходится. Много чего надо.

> Ну, например, нормальную типизацию. Хотя бы типобезопасность; о статической типизации я пока молчу.

Есть она. Модуль Variable::Strongly::Typed

> Лямбду, без которой о функциональном программировании говорить не приходится.

Эээ... Есть они, можно используя Acme::Lambda добавить сахару в синтаксис. Правда это немножко хак (ага, Perl это очень мощная система хаков-костылей) из-за того, что это не функции, а все же ссылки на них, но это все можно скрыть, так что все будет выглядеть вполне прилично.

1) И что, списки таки перестанут работать скалярами? Интересно... 2) Это лямбда или то, что в пхп?