Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Senior C#/Typescript Dev
  • Збираємо 31 млн грн на PD-2 — святкуємо 31 рік Незалежності України

  • Почему стоит задуматься о функциональном программировании: плюсы, минусы и применение

    GC — чего обидного-то? Абстракция GC часто протекает (как и другие абстракции).

  • Почему стоит задуматься о функциональном программировании: плюсы, минусы и применение

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

    Я не вижу особого смысла в задрачивании на чистое ФП вне академических областей. В практической области можно и нужно подбирать инструменты под задачу. Цель ведь создать что-то полезное, а не писать код ради кода.

    Или вы считаете, что для защиты ФП нужно упарываться концепцией по самые гланды?

    Кстати. LISPы же всегда славились своей практичностью. Они ориентированы на иммутабельность+ФП, но дают возможность писать код и в императивном стиле, и в ООП. Вопрос: вы пользовались этой возможностью или оставались в рамках полной чистоты?

    Підтримав: Denys Poltorak
  • Почему стоит задуматься о функциональном программировании: плюсы, минусы и применение

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

    Или вас смущает существование областей, в которых не нужно выдрачивать код?

  • Почему стоит задуматься о функциональном программировании: плюсы, минусы и применение

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

    Давайте я уточню получше область, где ФП лучше не применять.

    Задачи, в которых мы упираемся в ЦПУ — вот здесь лучше не лезть со всякой шнягой типа ФП, GC и прочим. Так, к примеру, в C# большинство людей понимают, что простое переписывание LINQ на foreach может дать 2x-4x в производительности.

    Но только не везде эта производительность нужна. А вот выразительность нужна везде. ФП дает выразительность в некоторых задачах. Но это не zero-cost абстракция. Она имеет цену. Когда у вас накладные расходы на ФП достоточно малы для вас, то заменять ФП на что-то другое будет микрооптимизацией.

    И я как-бы очень рад, что у вас есть performance critical задачи. Но есть куча областей, где их нет. Если для ваших задач что-то не подходит, то это не значит, что это что-то является бесполезной хуетой. То, что вы не видите задач, где ФП рулит скорее всего следство вашей специализации на performance critical задачах.

    Теперь, о том, как мне помогает ФП. Задачи трансформации/обработки данных очень легко выражаются через map/filter/flatMap/toDictionary и тому подобное. И императивный код зачастую у меня занимает больше строк и менее понятен, чем ФП-подобный. Если я вижу проседание производительности из-за неэффективности ФП, то я делаю фоллбек на более низкий уровень.

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

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

    Підтримав: Alex Koshterek
  • Почему стоит задуматься о функциональном программировании: плюсы, минусы и применение

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

    А со штампами в чем проблема? Если аргументация типичная, но корректная, то это збс аргументация, нет?

  • Почему стоит задуматься о функциональном программировании: плюсы, минусы и применение

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

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

  • Почему стоит задуматься о функциональном программировании: плюсы, минусы и применение

    Гм. Вы умудряетесь спорить о вещах, о которых не имеете ни малейшего понятия.

    Во-первых, ООП не может быть следующей ступенью ФП, потому что «объекты — замыкания для бедных, замыкания — это объекты для бедных». Задание «написать свое ООП» является вводным для многих курсов по ФП.

    Во-вторых, ваша идея о том, что процедурное программирование == функциональному страдает двумя болячками. Болячка первая: в ФП как-ни странно не функции, а замыкания (функция + захват переменных). Без замыканий, на чистых функциях нельзя получить мощь аналогичную ООП. Болячка вторая: процедуры нельзя легко передавать в другие процедуры. Что делает невозможным high-order functions. А high-order functions позволяют выразить как минимум 1/3 (мне лень считать) паттернов GoF. То, что вы в старом добром С могли передать ссылку на метод — это неудобная ерунда, которая убивает легкость ФП.

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

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

    Підтримав: Alexander Taran