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

[@stanislavzemlyakov5442]

Отличный доклад, спасибо.

[@АлександрЗверев-й1х]

Блестящий доклад! Спасибо большое!

[@ultraon83]

Просто невероятно, очень классное и понятное объяснение!

[@centwor1on167]

Отличный доклад! Вот что значит эксперт - уметь рассказать и объяснить тему даже на дудульке сыграв! Спасибо Виталию за взгляд на тему с высоты

[@PetrovAlexey]

Очень полезный доклад для вывода мозгов из тупика

[@folcrams2993]

"Не морочьте мне голову со своим функциональным программированием!" - дайте хоть основы выучить

[@MrVicorl]

ещё до пандемии, без масок и офлайн встреча... какие времена были... :(

[@petrvictorovich]

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

[@TheOnlyAndreySotnikov]

Есть вещи, которые ahead of time компилятор в принципе никогда не сможет оптимизировать. Например, вызов виртуальной функции невозможно заинлайнить, если вызов осуществляется через таблицу виртуальных функций, которая строится в run-time. Так что аргумент «не бывает медленных способов программирования, это компиляторы плохие» не состоятелен.

[@АлександрФёдоров-я7ц]

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

[@alexgorodecky1661]

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

[@laticalamonzi2814]

Включила на прослушку, показалось Вячеслав Мясников говорит... =)

[@SergRyabinin]

Доклад очень интересный. Если брать аналогии с живым миром, никого не удивляет присутствие в нем птиц, насекомых, бактерий, рыб, растений, грибов и тд, но почему то в мире программистов все еще бывают споры относительно того, какой подход самый "правильный"))

[@berghauz]

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

[@SergRyabinin]

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

[@NICKy1038ausc]

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

[@berghauz]

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

[@NICKy1038ausc]

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

[@ivanfedorov7934]

Супер доклад , все правильно, делайте хорошие компиляторы, а уж мы-то напишем :)

[@kujoxer-yep]

00:15:40 - чел 100% закрывает вопрос что такое ФП и ООП, красавчик есть же

[@ArgentSmith]

Хочу такой презентер с "подсветкой экрана"

[@VBragilevsky]

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

[@alexanderskusnov5119]

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

[@IExSet]

Какой нафиг компилятор с искусственным интеллектом, о чём они ?

[@yaroslavpiddubnyak2025]

Общий смысл - переходить на языки ещё более высокого уровня, а если будет плохо работать - это виноваты разработчики компилятора, что дураки - остались на низком. 😎

[@cheefoxcheefox2372]

Чёт херь какая-то. Надеюсь,что в комитете Haskell этот человек просто пьёт кофе

[@lenin1st]

когда лектор оговорился про то, что скорость - это проблема компилятора, я выключил. какие знакомые боевые фразы.

[@0xsadcat92]

Штош, компилятор виноват в медленном коде, так заказчику и скажем, пусть подождет пока допилят...

[@inbuckswetrust7357]

на кого вешать собак разрабам компилятора ? :) короче выяснится, что во всем виноват собака Тьюринг

[@АндрейСимаков-ь9и]

Дано: гугл-1шт. ,есть поток данных n>1, дискретность данных будет n>1÷a+(b•b). Сжатие фаилов b не позволяют высокоуровнивые кодаки. основанные на последних языках програмирования, т.к в фортан больше не могем. Попытки сжимать медиа.- нейросетями привели к неслабой ловле лулзов. Вопрос: сколько потребуется времени чтобы компания гугл освоила сжатие медиафаилов крипто шифрованием, используя при этом сторонние мощьности?

[@princessmary5556]

Бред.

[@mslq]

Да я на ассемблере функций наделал средствами макроса и функионирую! ))

[@АлександрФёдоров-я7ц]

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

[@deleteddeleted1940]

3734 note

[@Devof-n9i]

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

[@СтаниславВершков-т2т]

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

[@АлександрФёдоров-я7ц]

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

[@ChannelCheesecake]

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

[@Darellat]

очередной манямир функциональщиков на этапе вопросов

[@Yetishkin_Pistolet]

Python ведь тоже на 79% функциональный. А вы его не упомянули, почему ? Как будете оправдываться ?! А ?! АААААААА !!!!

[@nikitatimofeenko9351]

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

[@mslq]

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

[@ChannelCheesecake]

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