Перевод: Почему ФП важно даже для ООП программистов?

[dev96]

Не убедили)

[aikixd]

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

[jetcar]

это как, что не так с ними? ни разу с этим проблем не видел

[aikixd]

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

[jetcar]

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

[aikixd]

Смысл не в том, что у функции нет зависимостей, а в том, что если зависимости те же, то результат — тот же.

К примеру функция f(x) = x + 1. Если неважно сколько раз вы вызовите f(1), вы всегда получите 2. А вот функция g(db, str) = db.getByString(str) + 1 может вернуть разный результат в зависимости от состоянии базы данных. То есть вы завязали функцию на внешний мир.

Зная это, вы захотите переписать программу так, что-бы логика программы не была завязана на внешний мир. Вы переместите доступ к данным на внешний слой, что-бы в ядре программы использовать f(x), которую проще тестировать и контролировать. Так все изменчивые компоненты будут находится за пределами ядра и вы получите луковую архитектуру естественным образом.

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

[jetcar]

ну в каком-то виде я уже пишу используя ФП :D есть классы которые делают чтото с данными, есть те которые берут извне, но не хаскель потому можно всё
хорошенько смешать, тут разве что разделение по проектам немного помогает не позволяя создавать круговые зависимости и ревью кода

[AstarothAst]

Ну, как бы код пишется, что бы делать какую-то работу и сообщать о ней в наш внешний мир. То есть, ради побочных эффектов он и пишется.

[aikixd]

Разница в том, где вы эту связь осуществляете. Для этого нужен отдельный компонент и этот компонент не должен попадать в ядро программы.

[wlr398]

Слишком лаконичная статья. Здесь же на Хабре можно найти гораздо более объёмные и интересные статьи как про ФП в целом, так и по конкретным языкам типа Эрланга или Хаскеля.

[Bojczuk]

«Разбудите меня лет через сто, и спросите, что сейчас делается на хабре. И я отвечу — рассказывают про ФП и чем оно лучше ООП.»

[papercuter]

Собственно в этом смысл статьи. Техники функционального программирования полезны и в ООП.

[ionicman]

Ага — Молоток лучше чем отвертка!

Нельзя сравнивать ФП или ООП — все это — инструменты, и каждый лучше или хуже подходит для конкретных задач, вот и все.

Прекратите уже сравнивать несравнимое!

[papercuter]

Данная статья не сравнивает ФП и ООП. Как раз наоборот, показывает, что можно использовать практики ФП и в ООП и таким образом улучшать код.

[AstarothAst]

Как раз доказательств-то и не видать.

[papercuter]

А какие доказательства Вам нужны? Что и в ООП можно писать чистые функции и что их легче тестировать? Что и в ООП при неизменяемости состояния кол-во багов ниже, чем когда разные нечистые функции меняет одну общую переменную?

[AstarothAst]

А какие доказательства Вам нужны?

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

[VaalKIA]

Автор, если уж вы решили поразмышлять над языками, то должны чётко осозновать, что в утилитарном смысле — чем шире возможности языка, тем — лучше, а в теоретическом смысле, всё наоборот: язык это — набор ограничений. Только когда мы говорим об ограничениях, нет такого простого критерия, типа: больше ограничений — лучше язык, нет, ограничения должны быть разумными, а ещё лучше — концептуальными. Если не понятно о чём я говорю, то начните с основ, что такое процедурное программирование, почему запрещают goto и т.п. Так вот, вы говорите о концепции в контексте — можно, значит концепция — верна, вы ничего — не попутали, так-то и на асме можно ООП и ФП?

[papercuter]

Скажем, такой процедурный язык как Go позволяет использовать и чистые функции и неизменяемость, однако в нем отсутствуют такие популярные методы, как .map() или .filter(). Хотя, опять таки, ничего не мешает написать их самостоятельно.

[VaalKIA]

Вы вообще не поняли о чём я говорю, не важно какие есть методы и какие можно написать, это никак не относится к концепциям языка. Когда есть концепция, каких-то вещей, в принципе не может быть в языке, потому что они противоречат концепции, а не потому что их не написали. Это ограничение, для того что бы концепция была не виртуальной, а реальной. Из того, что вы можете силой воли писать только чистые функции ничего не следует, точно так же как javascript не станет строго типизированным, если вы будете использовать только один единственный тип. Ещё раз, есть концепция, и есть ограничения, которые заставлют строго её соблюдать. Можете соблюдать её силой воли, и возможно, подобный стиль программирования вам подходит: вполне возможно писать на ассемблере в рамках ООП. Но в чём открытие-то? Это всё равно что заявить, что оказывается на русском языке можно не ругаться матом, да — можно, и что!? А дальше концепция должна докзать свою жизнеспособность, то есть, то какие преимущества она обменивает на ограничения, точно так же как откзавшись от мата и крича «ой мамочки, мамочки», когда вам ногу придавило пятитонным станком и никто нифига не понял, что вам нужна помощь… возможно ограничение вовсе не нужно, а достаточно здравого смысла, что бы что-то использовать умеренно. К примеру GoTo, это очень мощный инструмент и его очень удобно использовать, по вашему, отсутствует этот популярный метод, но ничто не мешает написать его самостоятельно? А вот если вы посмотрите критику этого оператора, практику языков, в которых его нет и собственный опыт его использования, то думаю согласитесь что от него полностью можно и нужно отказаться, но в поддерживающем антиGoTo будут развиты конструкции циклов, выбора и т.п. что бы целенаправленно не использовать GoTo. Вы говорите, смотрите я от готу могу откзаться и даже циклы я могу сделать вот с помощью такйо хрени, правда селектов нет, ну молодец, но программируешь-то ты на ООП, а в концепции важна концепция, если ты до неё дошёл, так и работай только в её рамках и докажи, что ограничения не зря придётся терпеть, а не — «я такой борец за здоровье, но ночью буду жрать колбасу» Я могу и дальше параллели проводить, но смысл?

[papercuter]

Мы, видимо, по разному поняли эту статью. Лично я вынес из нее, что вышеуказанные техники совсем не противоречат ООП. Таким образом не нарушают концепцию. Большинство языков мультипарадигменны и основная парадигма языка чаще всего определяется сообществом и открытым кодом, опять-таки написанным сообществом.

[VaalKIA]

Мы по разному поняли эту статью, вы мне о том, что обычный режим питания допускает поедание блюд веганов, но у веганов есть секретный способ готовки коры дуба с подливкой и мы её умыкнём. А я вам про то, что даже если вы будете готовить кору с подливкой вы не станете веганом, потому что дело не в том. что они кору дуба едят, а в том, что они не едеят мяса.

[papercuter]

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

[papercuter]

Все-таки хотелось бы понять, почему минусуете? Что неправильного в статье? Или в переводе?

[Welran]

В посте неправильно оформлен перевод, для этого существует специальное оформление. А сама статья — я так и не понял Почему? Какая то, если честно, бессмысленная статья. Вряд ли стоила перевода.

[papercuter]

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

[Welran]

Ммм в чем суть то? И в чем отличие? И как можно применить в ООП?

[papercuter]

Есть как минимум два ключевых момента, которые называют при описании ФП: чистые функции и неизменяемость. Их не называют при описании других парадигм. В ООП и императивном программировании, напротив, чаще всего происходит изменение состояния объекта (локальной переменной, приватного поля объекта). Данная статья вкратце описывает, что и в ООП можно использовать эти техники. Можно также не менять состояние объектов, можно вообще не использовать циклы с изменением локальных переменных, в современных более-ООП (они чаще мультипарадигменны) языках есть такие методы, как map, filter, reduce и т.п. Свои же функции и методы можно писать в том же стиле, без сайд-эффектов, создавая новые инстансы вместо изменения имеющихся.

[AstarothAst]

можно вообще не использовать циклы с изменением локальных переменных

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

[papercuter]

Так может и стоит перейти на функциональный язык, чтобы иметь возможность применять эти техники в соответствии с природой языка, натурально? Лично мой бэкграунд — это .NET (C#), но сейчас я не начинаю новых проектов на C#, теперь только F#.

[aikixd]

Современный язык неподдерживающий tailcall это моветон.

[AstarothAst]

Поддерживать и быть оптимизированным специально под него — разные вещи.

[aikixd]

Это и есть оптимизация. Позволяет не создавать фрейм для каждого рекурсивного вызова.

[AstarothAst]

В java этой оптимизации нет: habr.com/post/319282

[Sie]

В Комментариях автор пару раз упоминал функции — map, filter, reduce и т.п. разве наличие этих функций делает язык программирования функциональным? складывается такое впечатление что автор думает что именно наличие этих функций делает из ООП языка функциональный. По мне так это звучит как бред и наличие или отсутствие указанных функций не делает язык функциональным