Не морочьте мне голову со своим функциональным программированием / Виталий Брагилевский 

Поэтому полиморфизм типажей и дженериков в Rust куда лучше чем наследование абстрактных методов в той же Java. С одной стороны вроде как интерфейс (набор виртуальных методов), а с другой - no cost abstraction, потому все накладные расходы во время компиляции снимаются (ну также как Templates в С++). Ну, а если мы говорим про, скажем, массив экземпляров разных классов с одним интерфейсом, то тут я не вижу особых способов оптимизации даже руками программиста. То есть так или иначе будет if else или что-то типа того, завязанного на конкретном типе. Если у Вас есть идеи как эту проблему исправить руками программиста (а не компилятора), было бы интересно узнать)

@@user-ob7tt2ku8r, разницы с Java никакой нет. Разница лишь в том будет инлайн или нет, а это зависит. А инлайна может не быть вовсе если вы соберёте себе Array - но тут вы явно попросили рантаймовых абстракций

Автор доклада явно уже определился, и счетчики ему не то, и циклы фу, а что под капотом они же и сидят - ну не видно, значит неть! Уровень передергивания зашкаливает.

@@berghauz споры про это все-равно не утихнут никогда и все ветки программирования будут развиваться, как и все живое на земле)) впрочем, пригладное программирование хочется видеть давно уже посредством "крупных кубиков", а не ломать копья про ООП/функциональное/структурное и етс программирование. Хотя отраслевые решения на эту тему уже имеются давно.

@@berghauz Не очень понятна суть претензии. Следуя этой логике, раз "под капотом" процессор работает с машинными кодами, то все, кто считает более эффективным писать код хотя бы на ассемблере или на более высоких уровнях абстракции и так делают - "передёргивают". Речь же идёт конкретно про код программиста, который выполняет бизнес-задачу. На 8:39 был отличный пример. Декларативный код, который описывает суть задачи, занимает три строки. Проще читать, проще поддерживать. Чем лучше 10+ строк кода с циклами, проверками и счётчиками, который делает абсолютно то же самое? Понятно, что надо всегда быть разумными и использовать более применимый подход для кажого конкретного случая. Но доклад автора был только про ФП, в этом смысле тоже претензия непонятна

@@NICKy1038ausc На 8:39 был отличный пример сахара, какое отношение этот пример имеет к счетчикам, циклам и всему прочему, о чем выступающий говорил минутой ранее? Никакого, но выступающий зачем-то акцентировал свое внимание на зашкварности использования этих методов, словно все программисты, пишущие "эффективный" код только и занимаются тем, что считают строчки в файле. Это и называется - передергивать.

@@berghauz Это рофл? Прямое отношение. Вы смотрели видео, суть поняли? Были показаны два метода, которые делают одно и то же. В императивном и функциональном стиле. Первый занимает гораздо больше места и менее читаем из-за того, что в теле этого метода используются циклы и счётчики, о которых шла речь. В хорошем читаемом коде метод должен делать одну вещь и делать её хорошо. Перебор коллекции и чтение файлов посимвольно - как раз примеры того, почему императивный метод не является хорошо читаемым кодом. Когда все рутинные действия были вынесены в методы поменьше, функциональный код стал гораздо более лаконичным и декларативным. Он и пишется гораздо быстрее, и читается как книга: последовательно и на понятном языке. А не как код студента-младшекурсника. Программисты на реальных проектах ощутимо быстрее пишут код и быстрее его поддерживают, с этим очень странно спорить. Никто не считает каждую строчку кода, но когда функциональный код на практике В ТРИ РАЗА короче, это огромная разница. А так любую удобную абстракцию можно назвать сахаром и сказать, что она не нужна. И так раньше нормально жили, чего вообще развиваться, усваивать что-то новое и увеличивать производительность программистов. Вы сами-то решаете реальные задачи? И как, императивно? Пробовали иначе? Поделитесь, пожалуйста, своим опытом.

Управлять не очень удобно!

Я видел другой режим: фон не становится чёрным, а пятно желтоватое или красноватое (с прозрачностью).

пишу программы на машине Тьюринга, симулированной в игре жизнь и не жалуюсь))

Бред.

потому что ученые-исследователи и математики не инженеры

компилятор или интерпритатор? GHCI - медленный так как интерпретатор. А вот GHC - вполне быстрый, главное писать директиву ghc-options: -o2 в package.yaml, чтобы включилась оптимизация

Ну так он медленный, потому что умный. Что не понятно, это 2 стороны одной монеты. Но пока Хаскеллист напишет код за x времени, напишет y тестов и будет ждать z времени компиляцию. Какой-нибудь гошник напишет то же самое за 5x времени, напишет 3y тестов, но скомпилирует быстрее, кто в итоге продуктивнее

А не че, что он ООП и сам создатель языка до последнего не хотел добавлять функциональные методы по типу map, filter, reduce и тп

Очень сильный язык, боится оговорится.

Что там функционального. Лямбды однострочные или может быть отсутствие иммутабельных данных