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

EP>>У детерминированности и отсутствии побочных эффектов действительно более широкое значение чем у pure function. Тем не менее, когда наш код целиком состоит из pure functions — то да, мы имеем дело с ФП, как минимум с чем-то крайне близким к ФП — это следует из самого определения ФП.
S>pure function накладывает ограничение на наблюдаемое извне поведение функции, а не на то, в какой парадгиме она написана внутри. Ровно поэтому "когда наш код целиком состоит из pure functions" — не гарантирует близости к ФП, т.к. тела функций могут быть 100% императивны.

Да, согласен — пропустил часть про явное мутировавшие данных. Дальше по сообщению оно есть.

IT>>>А мужики-то и не знают. Оказывается я с самого первого дня писал в функциональном стиле. Особенно на Фортране и PL/1. Ага.
EP>>Если не было никакого явного мутирования данных (в чём я сомневаюсь), функции были чистыми — то да, это был функциональный стиль.
S>Чистота функций накладывает ограничение на наличие явного мутирования данных только в том случае, когда данные могут быть восприняты в качестве побочного эффекта.

Явное мутирование внутри функции и чистота функции снаружи — как ты уже заметил, ортогональные вещи. Для ФП нужно и то, и то.

S>То есть выходит что разница между полным ФП и "чем-то крайне близким к ФП" во внутренностях? Выходит, что внутренности крайне незначительны?

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

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

EP>У детерминированности и отсутствии побочных эффектов действительно более широкое значение чем у pure function. Тем не менее, когда наш код целиком состоит из pure functions — то да, мы имеем дело с ФП, как минимум с чем-то крайне близким к ФП — это следует из самого определения ФП.

В подобных рассуждениях мне видится определённый косяк. Особенно учитывая, что код, состоящий из одних чистых функций по своей сути бесполезен именно по причине отсутствия побочных эффектов, как раз ради которых и создаются приложения.

Получается, что:

1. На любом языке можно писать в функциональном стиле, таким образом любой язык является функциональным.
2. Т.к. чистый функциональный язык по сути бесплезен, то любой язык, на котором можно писать в функциональном стиле бесполезен.
3. Таким образом функциональный стиль бесполезен.

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

IT>>Тем не менее до недавнего времени они встречались только либо в ФЯ, либо в гибридах.
EP>Лямбды-замыкания были в ООП-шном Smalltalk, а ФВП были даже в императивном C.

Тем более они всегда были в ассемблере.

IT>>Достаточно написать метод, который умножет два на три и вот уже оно ФП в полный рост.
EP>А что смущает?

Смущает весьма вольное обобщение.

EP>Несколько раз повторяешь что ИП внутри метода плох. Хотелось бы услышать аргументы, так как по моим представлением именно ИП (пусть и разбавленный фишками исторически характерными скорее ФЯ) сейчас лучше всего подходит для тел функций.

Аргументы здесь приводились уже миллионы раз. Кроме как скупостью весьма грубых доступных средств ИП больше ничем не выделяется. Три вида цикла, switch, if, break, return, да ещё чуток по мелочи. Вот и весь ИП. Честно говоря, мне вообще странно слышать подобное мнение в 2015-м году.

EP>Думаю что нет — для полного ФП нужны и ФП интерфейсы и ФП внутренности.

ФП интерфейсов не бывает. Это уже какая-то отсебятина.

EP>А при том что компоновка это про модули и namespace'ы, а не про ООП и классы.

Компонентность — это естественное развитие ООП. ФП к этому уж точно никакого отношения не имеет.

EP>Кстати, эти статические классы ведь даже импортировать нельзя в C#

Этого утверждения не понял.

EP>Насколько я понял под "ФП рулит внутри" — ты понимаешь именно ИП приправленное щепоткой фишек ФЯ — так?
EP>Или ты имеешь в виду именно "ФП внутри" в чистом "Haskell'овском" смысле?

В любых смыслах. Я вовсе не против ИП, но как только внутрь метода приходит ФП, то ИП остаётся только смущённо покуривать в сторонке и ждать пока его позовут. Ни о каком рулении речи больше не идёт.

Здравствуйте, Sinix, Вы писали:
S>Только как делегат
Удачи в объяснении девелоперам причин, почему локальную функцию можно передать в Lync to Objects и нельзя в Lync to Sql.

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

EP>>У детерминированности и отсутствии побочных эффектов действительно более широкое значение чем у pure function. Тем не менее, когда наш код целиком состоит из pure functions — то да, мы имеем дело с ФП, как минимум с чем-то крайне близким к ФП — это следует из самого определения ФП.
IT>В подобных рассуждениях мне видится определённый косяк. Особенно учитывая, что код, состоящий из одних чистых функций по своей сути бесполезен именно по причине отсутствия побочных эффектов, как раз ради которых и создаются приложения.

Разнообразный ввод/вывод описывается чистыми функциями (и трёхэтажными замыканиями). Haskell — чистый ФП язык, и на нём можно создавать полезные приложения в которых все функции будут чистыми.

Если упрощённо, то вот такая функция:

action foo(int x)
{
    return format("print %d ;", x);
}

полностью чистая, сама не делает никакого IO, но runtime может использовать её результирующее значение как угодно, в том числе сделать eval. Примерно таким образом (опять же, слишком упрощённо) и строится ввод/вывод на чистых функциях.

IT>Получается, что:
IT>1. На любом языке можно писать в функциональном стиле,

Допустим.

IT>таким образом любой язык является функциональным.

Не думаю что это достаточное условие.

IT>2. Т.к. чистый функциональный язык по сути бесплезен,

Неверно.

IT>то любой язык, на котором можно писать в функциональном стиле бесполезен.

Вдвойне неверно. Даже если допустить что ФЯ бесполезен, из этого не следует что язык, в своём подмножестве допускающий ФП, является бесполезным.

IT>>>>>Теперь понятно, что смущает в твоих рассуждениях. Фактически ты одни ФП фишки низводишь до уровня некоторых элементов характерных ФЯ,
EP>>>>Каковыми они и являются. Отсутствие тех или иных фишек в языках которые называют функциональными, плюс присутствие таких фишек даже в старых императивных языках, как раз и говорит о том что эти фишки не определяющие для ФП.
IT>>>Тем не менее до недавнего времени они встречались только либо в ФЯ, либо в гибридах.
EP>>Лямбды-замыкания были в ООП-шном Smalltalk, а ФВП были даже в императивном C.
IT>Тем более они всегда были в ассемблере.

Тем более. Это только подтверждает выделенное.

IT>>>Достаточно написать метод, который умножет два на три и вот уже оно ФП в полный рост.
EP>>А что смущает?
IT>Смущает весьма вольное обобщение.

Вольное обобщение это использование термина "ФП" для описания ИП с примесью некоторых фишек характерных для ФЯ, но их не определяющих.

EP>>Несколько раз повторяешь что ИП внутри метода плох. Хотелось бы услышать аргументы, так как по моим представлением именно ИП (пусть и разбавленный фишками исторически характерными скорее ФЯ) сейчас лучше всего подходит для тел функций.
IT>Аргументы здесь приводились уже миллионы раз. Кроме как скупостью весьма грубых доступных средств ИП больше ничем не выделяется. Три вида цикла, switch, if, break, return, да ещё чуток по мелочи.

+ Изменяемые массивы, да и вообще изменяемые структуры данных
+ ФВП (типа std::transform, std::partition_point, std::stable_partition, etc)
+ Лямбды-замыкания, в том числе изменяемые
+ ...

IT>Вот и весь ИП.

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

IT>Честно говоря, мне вообще странно слышать подобное мнение в 2015-м году.

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

Например — C++1998 STL (алгоритмы и структуры данных) — это ИП в полный рост, как снаружи, так и внутри. Свои задачи прекрасно решает, ФП бы так не справилось.
И вот подобный стиль, по моим представлением, лучше всего подходит для тел функций.

EP>>А при том что компоновка это про модули и namespace'ы, а не про ООП и классы.
IT>Компонентность — это естественное развитие ООП. ФП к этому уж точно никакого отношения не имеет.

Ранее шёл разговор про компоновку, а не про компонентность.

EP>>Кстати, эти статические классы ведь даже импортировать нельзя в C#
IT>Этого утверждения не понял.

Использование статических методов без указания имени класса. Например есть в Java.

EP>>Насколько я понял под "ФП рулит внутри" — ты понимаешь именно ИП приправленное щепоткой фишек ФЯ — так?
EP>>Или ты имеешь в виду именно "ФП внутри" в чистом "Haskell'овском" смысле?
IT>В любых смыслах.

Судя потому что чистый ФП ты считаешь бесполезным — то точно не в "Haskell'овском" смысле.

IT>Я вовсе не против ИП, но как только внутрь метода приходит ФП, то ИП остаётся только смущённо покуривать в сторонке и ждать пока его позовут.

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

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

T>>Как результат, время вхождения в проект только увеличится.

IT>Это старая песня закалённого в интригах менеджера про пучок индусов вместо одного вменяемого разработчика. Тут есть только одна проблема — функция Sum для IQ не работает. Работает только функция Max. Тренеруйте своих разработчиков, гоните в шею бездарей и всё у вас получится. Посредственности могут выдавать только посредственный результат.

Как показывает практика, в большинстве случаев — Max / n, для n > 3

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

S>>Только как делегат
S>Удачи в объяснении девелоперам причин, почему локальную функцию можно передать в Lync to Objects и нельзя в Lync to Sql.

А сейчас, простите, разве что-то не точно так же? То, что можно передать в l2o внезапно кидает "L2Entities does not recognize the method 'XXXX' method, and this method cannot be translated into a store expression."
Ничё, как-то "девелоперы" живут с этим.

Здравствуйте, Yoriсk, Вы писали:
Y>Ничё, как-то "девелоперы" живут с этим.
Нет, сейчас не точно так же. Локальная функция будет отпадать на этапе компиляции, и её замена на именованную лямбду будет выглядеть примерно таким же шаманством, как обрамление имени аргумента скобками в джаваскрипте (aka "why 42..toFixed(2) == (42).toFixed(2)").

EP>Вообще мой поинт в следующем:
EP>* В теле функций лучше всего себя показывает императивное программирование вкупе с некоторыми элементами характерными ФЯ — функции высшего порядка, лямбды/замыкания, и т.п. Добавление таких элементов не делает такой код функциональным — это всё то же ИП с явным мутированием и итерациями.

Нашёл статью на эту тему с говорящим названием: Higher Order Imperative Programming.
Kershenbaum, Musser, Stepanov.
1988 год между прочим.

http://www.stepanovpapers.com/hop.pdf
...
There is usually a further restriction to a purely applicative (no side effects) style of programming.
...
we recognize that the use of higher order techniques is orthogonal to the question of applicative vs non-applicative styles.
Higher order techniques can in fact be used with great effectiveness with imperative forms and mutative procedures, and hence can be put into much more widespread use today, in existing languages, without need for new language or architectual advances.

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

S>Без обид, но нет. Скорее, получается копипаста и дублирование кода из-за того, что никто не знает, что подобный код уже написан. Разумеется, это справедливо только для проектов, в которых один человек в принципе не сможет охватить всю codebase.

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

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

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

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

UPD: не сразу понял, что делаю некропостинг и не прочитал всю ветку ) некоторые вещи уже говорились другими авторами.

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

T>Немерле, как я понял, больше функциональный, чем объекто-ориентированный, поэтому больший уклон в функциональщину там может смотреться вполне логичным.
T>C# же скорее наоборот.

Я понимаю, если бы уклон предполагал отказ от чего-то. Но Nemerle не менее ОО, чем C#. А в функциональном плане C# его быстро догоняет и это очень здорово.