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

A>До лямбда-функций приходилось или писать метод на каждое действие (с обходом контейнера) — код обхода дублировался; или придумывать интерфейс визитора, от него наследовать классы, в классе делать метод типа Visit и все это куча кода.

Не такая уж и куча. C++98:

void print(int x)
{
    cout << x;
}

struct Print
{
    void operator()(int x)
    {
        cout << x;
    }
};
// ...
{
    vector<int> xs;
    // ...
    for_each(xs, print);
    for_each(xs, Print());
}

Тем не менее, сила лямбд не в том что не нужно создавать класс — это всё константные синтаксические расходы, а в том что для захвата N переменных из контекста, не нужно писать Θ(N) кода.

A>С появлением лямбда-функций все упростилось, просто передаешь код в метод ForEach контейнера и все, никакой лишней писанины.

Да, но всё же стоит отметить, что ForEach (и другие ФВП) не всегда целесообразно использовать с лямбдами. Например если лямбда сильно увеличивает количество строк в функции, или код внутри неё используется в разных местах.

P.S. AFAIK, в ФП считается хорошем тоном НЕ использовать лямбды:

https://wiki.haskell.org/Pointfree
It is a common experience when rewriting expressions in pointfree style to derive more compact, clearer versions of the code -- explicit points often obscure the underlying algorithm.

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

vsb>>Если судить с этой точки зрения, то ФП это расширение других парадигм (императивное программирование, ООП) и никаких ограничений тут нет, сплошные возможности. И они частенько помогают.

S>Почему? Мне вот кажется, что другие парадигмы являются расширением ФП.

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

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

F>>меньше шансов облажаться с изменением состояния.

D>+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!

Удобно ровно до тех пор, пока не приходится выжимать биты. Скажем, обработку видео или звука при помощи иммутабельных структур данных в своём уме никто не делает. С железом никто не работает при помощи иммутабельных структур данных.

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

F>>а ещё во многих языках нет банального наследования.

D>Ну это уже проблемы отдельных языков, а не сабжа как такового.
D>UPD. Наследование — это ООП, а ООП + ФП = мультипарадигменный язык (на других нынче писать довольно глупо).

Есть мнение, ООП включает в себя ФП. За подробностями к Бертрану Мейеру

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

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

Ну так в любом подходе есть свои ограничения. Если говорить о чистом ФП, там одни ограничения, если говорить о чистом ООП, там другие ограничения. И я сильно сомневаюсь, что если писать на чистом ООП, радость будет больше. Не зря же в C# есть анонимные функции и классы. Это уже уход от ООП и мне бы сильно не хотелось бы к нему возвращаться. Таким образом, изначальный вопрос можно переформулировать: "Смысл функционального программирования программирования в ограничениях любого подхода?"
Я не знаю, какой подход более ограничивает, ФП или императивный, но ООП точно ограничивает сильнее.

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

D>>+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!

I>Удобно ровно до тех пор, пока не приходится выжимать биты. Скажем, обработку видео или звука при помощи иммутабельных структур данных в своём уме никто не делает. С железом никто не работает при помощи иммутабельных структур данных.

Я написал не про обработку видео и звука и не про работу с железом. А про entities, и даже в скобках указал, что речь про работу с базой.

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

I>Есть мнение, ООП включает в себя ФП. За подробностями к Бертрану Мейеру

Я тут где-то рядом давал ссылку на старый пост IT, где тот говорит, что ООП работает вне метода, а ФП — внутри. При этом IT всегда рассуждает как сугубо практик. А читать всяких левых теоретиков и жонглёров баззвордами — только грузиться и запутываться.

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

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

rfq>>>Какой смысл программировать в условиях искусственных ограничений?

F>>меньше шансов облажаться с изменением состояния.

D>+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!

А где?

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

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

Если лабать формы для отчетов, может и не нужно.
Но если строить серьёзное ПО, например, такое http://www.reactivemanifesto.org/, то речь идёт о правильном проектировании программных систем.
Но в целом ФП — сплошный возможности.

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

EP>P.S. AFAIK, в ФП считается хорошем тоном НЕ использовать лямбды:

WAT
а как без них?

EP>

EP>https://wiki.haskell.org/Pointfree
EP>It is a common experience when rewriting expressions in pointfree style to derive more compact, clearer versions of the code -- explicit points often obscure the underlying algorithm.

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

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

D>>+1. Я когда-то давно прочитал на кывте чьё-то откровение, что immutable entities (замапенные на таблицы классы модели) — это аццки удобно. Хмыкнул недоверчиво, но таки-рискнул попробовать. И имею подтвердить — это АЦЦКИ удобно!

F>А где?

Что где? Где прочитал — не помню. Где юзаю — да во всех проектах, где есть база.

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

rfq>Какой смысл программировать в условиях искусственных ограничений? Может, это просто детская забава, типа скакать на одной ноге?

Ограничения мешают прострелить себе ногу. Это относится не только к ФП, это про вообще.

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

I>Странное мнение. Если начать осваивать программирование с процессора, то окажется, что никакого ФП и близко нет, всё насквозь мутабельное.

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

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

rfq>Какой смысл программировать в условиях искусственных ограничений?

использование ЯВУ вместо ассемблера — как сказывается на производительнсоти, надёжности и твоём лично впечатлении от процесса програмирования?

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

I>Удобно ровно до тех пор, пока не приходится выжимать биты. Скажем, обработку видео или звука при помощи иммутабельных структур данных в своём уме никто не делает. С железом никто не работает при помощи иммутабельных структур данных.

делают при соответствующей оптимизации/библиотеках. даже для gpu библиотеки есть. но большая часть кода не требует оптимизации вообще. я лично хочу иметь ФП язык, совместимый с С++ по структурам данных и исключениям

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

EP>>P.S. AFAIK, в ФП считается хорошем тоном НЕ использовать лямбды:
F>WAT

http://rsdn.ru/forum/decl/5350211.1

Автор: Klapaucius
Дата: 01.11.13

K>ФП — это комбинирование комбинаторов как основной способ решения задач программирования, а не "я тут как-то раз фильтр использовал вместо цикла".

F>а как без них?

Комбинирование комбинаторов полно по Тьюрингу. Смотри например SKI, Unlambda:

http://en.wikipedia.org/wiki/Unlambda
Unlambda is a minimal, "nearly pure"[1] functional programming language invented by David Madore. It is based on combinatory logic, a version of the lambda calculus that omits the lambda operator. It relies mainly on two built-in functions (s and k) and an "apply" operator (written `, the backquote character). These alone make it Turing-complete, but there are also some I/O functions to make it possible to interact with the user, some shortcut functions and a function for lazy evaluation. There are no variables in the language.

EP>>

EP>>https://wiki.haskell.org/Pointfree
EP>>It is a common experience when rewriting expressions in pointfree style to derive more compact, clearer versions of the code -- explicit points often obscure the underlying algorithm.

F>pointfree вообще не об этом. даже не рядом.
F>это скорее "старайтесь не указывать лишних аргументов, если у вас есть частичное применение".

Pointfree в том числе именно об этом — лямбды либо принимают какие-то параметры, либо захватывают. Pointfree же о том, чтобы вообще не использовать никакие параметры.

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

I>>Есть мнение, ООП включает в себя ФП. За подробностями к Бертрану Мейеру
D>Я тут где-то рядом давал ссылку на старый пост IT, где тот говорит, что ООП работает вне метода,

Вне метода — то есть в интерфейсе — ФП или его элементы прекрасно работают. Все эти pure, иммутабельные структуры данных, или например ФВП — в том числе и про интерфейс.

D>а ФП — внутри.

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

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

I>Есть мнение, ООП включает в себя ФП. За подробностями к Бертрану Мейеру

Угу. {Замыкания|объекты} — это {объекты|замыкания} для бедных.

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

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

rfq>>Какой смысл программировать в условиях искусственных ограничений?

BZ>использование ЯВУ вместо ассемблера — как сказывается на производительнсоти, надёжности и твоём лично впечатлении от процесса програмирования?

А где тут ЯВУ, а где ассемблер?
Можно ли назвать ЯВУ язык, в котором даже циклов нет? (трольфейс)

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

K>Можно ли назвать ЯВУ язык, в котором даже циклов нет? (трольфейс)

согласен — в асме были переходы, в С циклы, в хаскеле — формулы. какой тебе вариант понятней — асмовский, сишный или

fac 0 = 1
fac n = n*fac(n-1)

?