Функциональная парадигма

Код должен быть эффективным и красивым. А следование каким-то «парадигмам» как правило ограничивает возможность написания такого кода.
Поэтому всякие лисперы, хаскелисты и фанаты эрланга — просто сумасшедшие фанатики. Разумеется, среди них есть и адекватные люди, но ты никогда не узнаешь что они используют Лисп, пока сам не задашь прямой вопрос. Они об этом молчат. Но не потому что им стыдно, а потому что никому до этого нет дела. И они об этом знают.

Вы мне лучше вот что скажите: зачем уродовать читаемый код лямбдами? Например в java. Оно как-то эффективнее работает, чем лупы, или что?

Очень сложно чем-то изуродовать код на Java.

Лямбдами можно изуродовать всё.

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

Мол, стиль со взглядом в будущее, распараллеливание, оптимизация, замена устаревшему ООП, который не способен идти в ногу с современными процессорами

Совсем поехавший что ли?

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

А по теме: я писал на haskell и на prolog. Об оба сломал мозг чуть более чем совсем. Теперь их днем с огнем ненавижу и пишу все в лоб процедуральщиной с легким впрыском ООП.

Сейчас вычислительная мощность процессоров растет с количеством их ядер. Считаешь что, многопоточность- характерный признак императивных языков?

Что-то в последнее время начали хайпить функциональное программирование.
в последнее время

Это с начала нулевых идёт

Код с лямбдой:

button.setOnClick(() => {
    doSomething();
});

То же, но без лямбды:

button.setOnClick(new Button.OnClickHandler {
    @Override
    void onClick() {
        doSomething();
    }
});

Где уродство? Просто убрали несколько строк лишнего оверхеда, который не нес никакой смысловой нагрузки.

Считаешь что, многопоточность- характерный признак императивных языков?

Каким боком связаны многопоточность и парадигмы программирования?

о-о-пе это инкапсуляция, сокрытие состояния. А наличие состояния — это главное препятствие для concurrency. Особенно если оно где-то скрыто и ты не знаешь, что может привести к data race.

Поэтому о-о-пе сакс.

Представь себе обновление участков кода без остановки его функционирования.

Не имеет отношения к парадигмам программирования

Может ли такое java?

с определенными ограничениями может

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

не могут

Формочкоклепание оставь себе. Я про лупы говорю. Ясные и понятные. Вместо map.reduce.hujuce(x -> x.element {}$#@@#$ raz raz i <-()();;=v production!)));;{

Что-то в последнее время

Ты от жизни лет так на 15 отстал.

Есть ли профит переходить на ФП?

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

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

Это если он не программист. Процедуральщина калечит моск и после 10 лет сишки перелезть просто так на хацкель или логическую парадигму не так-то просто.

Ты это им скажи, что не могут http://erlang.org/doc/reference_manual/code_loading.html#12.3

Где уродство?

Во втором-то случае тип коллбэка декларируется, и не просто формально «функция без параметров», а конкретный интерфейс, т.е. не подсунешь абы какую функцию, а только объект с названным интерфейсом Button.OnClickHandler.

о-о-пе это инкапсуляция, сокрытие состояния. А наличие состояния — это главное препятствие для concurrency. Особенно если оно где-то скрыто и ты не знаешь, что может привести к data race.

функциональщина не избавляет от состояний

Поэтому о-о-пе сакс.

сильно

таким, что она характерна функциональному программированию

Ты это им скажи, что не могут http://erlang.org/doc/reference_manual/code_loading.html#12.3

Erlang представляет из себя все множество функциональных языков программирования? Ну ок. А что на счет Haskell, Ocaml, F#, etc?

таким, что она характерна функциональному программированию

Многопоточность характерна функциональному программированию? Шизофазия на марше.

сильно

Да, очень сильно сакс.

таким, что она характерна функциональному программированию

наличие в Java, C++, C#, Python, etc возможности работать с потоками делает их функциональными?)

Я тебе привел пруф представителя функциональной парадигмы, этого разве не достаточно? Или может мы Erlang объединим в свою собственную парадигму?

Я не спорю, что ООП умеет работать с потоками, но ФП делает это гораздо проще и из коробки, даже если ты пишешь однопоточную по сути программу

Я тебе привел пруф представителя функциональной парадигмы, этого разве не достаточно? Или может мы Erlang объединим в свою собственную парадигму?

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

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

что не верно в общем случае.

Я не спорю, что ООП умеет работать с потоками, но ФП делает это гораздо проще и из коробки, даже если ты пишешь однопоточную по сути программу

И, конечно, у тебя есть пример этого «гораздо проще и из коробки»?

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

Есть ли здесь люди, которые пишут на Haskell или тому подобных языках?

Нет их тут. Тебя обманули.

стиль со взглядом в будущее

Смотришь в завтрашний день?.. (с)

Код должен быть эффективным и красивым. А следование каким-то «парадигмам» как правило ограничивает возможность написания такого кода.

Можно дефиницию красивого кода? А то я у кого не спрашивал - люди дают разные ответы.

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

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

инкапсуляция, сокрытие состояния

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

наличие состояния — это главное препятствие для concurrency

Не любого состояния, а только общего и при этом изменяемого.

начали хайпить функциональное программирование

Хипстеры нашли очередную серебряную пулю, которая наконец-то позволит им писать правильный код не включая голову. <spoiler>не поможет.</spoiler>

Ты лямбды не осилил? :)

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

Адепты-геронтофилы продолжают мучать старушку-С, не приемля никакие новые инструменты (да что там новые, даже просто иные).

Что-то в последнее время начали хайпить функциональное программирование. Мол, стиль со взглядом в будущее, распараллеливание, оптимизация, замена устаревшему ООП

это исключительно маркетинг и мода. пипл хавает - типа не для всех, ЧСВ + 100% и т.п., а комерсам позволяет выкатывать новые версии языков, библиотек, иде. в общем, всем нравится. Ну и да, функциональщина иногда бывает к месту, когда дозирована.

Что-то в последнее время начали хайпить функциональное программирование.

в последнее время

Лет так 30-40 как.

// Мимокрокодил. Против самого ФП ничего не имею, хотя и не применяю.

А наличие состояния — это главное препятствие для concurrency.

Это бред. Читай Actor Model — это реально Ъ-конкурентная модель. Когда про фапэ говорят, что он параллелится, имеется в виду не концептуальная сторона дела, а просто то, что если у нас, скажем естьfoo(bar, baz), и мы знаем что bar и baz независимы друг от друга, то оптимизатор может их распараллелить. Вот на этом убожестве все и заканчивается. Это, кстати, не относится даже к конкурентности как таковой, просто небольшая оптимизация

Читай Actor Model — это реально Ъ-конкурентная модель

Не спорю. message passing это очень конкурентно. А о-о-пе — нет.

Не спорю. message passing это очень конкурентно. А о-о-пе — нет.

ООП вообще ортогонально акторам.

Представь себе обновление участков кода без остановки его функционирования. Может ли такое java?

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

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

Лямбды лучше использовать на месте анонимных классов. Вот и всё их применение в Java.

ООП вообще ортогонально акторам.

Ты это portquest2016 объясняй, он меня отправляет про акторы читать, чтобы убедить в том, что ООП не препятствует конкурентности.

В городі бузина, а в Києві дядько, короче.

Свертки и map'ы - это не проблема никоим разом.
map - аналог forEach.
fold(l|r) - просто проход списка слева|справа однотипной операцией с сохранением значения в неком аккумуляторе.

Достаточно один раз понять, что это не «huyak-huyak-i-v-production», а просто применение однотипных операций к списку.

А вообще, воспользуйся scan(l|r) вместо fold(l|r) в примерах по сверткам из интернета, scan сохраняет промежуточные состояния вычисления в списке. Быстро понимание придёт, как работает свертка.

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

Считаешь что, многопоточность- характерный признак императивных языков?

Персистентные структуры фукнциональных языков в многопоточном режиме заметно менее эффективны, чем конкурентные структуры императивных языков. Так что многопоточнось+функциональщина = МИФ, красивая сказка для студентов.

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