Не морочьте мне голову со своим функциональным программированием / Виталий Брагилевский
Вставка
- Опубліковано 4 січ 2020
- Apps Conf Moscow 2019
Зал «Против глупости»
22 апреля, 14:00
Тезисы и презентация:
appsconf.ru/moscow/2019/abstra...
Адепты функционального программирования очень любят завлекать неопытных программистов обещаниями идеальной выразительности кода, его стопроцентной корректности, лёгкости поддержки и простоты рефакторинга. Иные даже пророчат высочайшую производительность и попадание после смерти напрямую в райские кущи. Опытные разработчики знают, что ничего такого не бывает, программирование - это тяжёлый труд, а серебряные пули, может, и помогают от вампиров, но никак не в процессе разработки ПО. С другой стороны, если что-то может хоть как-то облегчить труд программиста, то почему бы не попробовать этим чем-то воспользоваться?
...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Отличный доклад, спасибо.
Блестящий доклад! Спасибо большое!
Просто невероятно, очень классное и понятное объяснение!
Отличный доклад! Вот что значит эксперт - уметь рассказать и объяснить тему даже на дудульке сыграв! Спасибо Виталию за взгляд на тему с высоты
Очень полезный доклад для вывода мозгов из тупика
ещё до пандемии, без масок и офлайн встреча... какие времена были... :(
Супер доклад , все правильно, делайте хорошие компиляторы, а уж мы-то напишем :)
Почему так мало людей дозревает до такой "простоты" в понимании?
Видимо потому что с умным видом произносить "страшные слова" легче, приятней и льстит самолюбию.
"Не морочьте мне голову со своим функциональным программированием!" - дайте хоть основы выучить
Есть вещи, которые ahead of time компилятор в принципе никогда не сможет оптимизировать. Например, вызов виртуальной функции невозможно заинлайнить, если вызов осуществляется через таблицу виртуальных функций, которая строится в run-time. Так что аргумент «не бывает медленных способов программирования, это компиляторы плохие» не состоятелен.
Поэтому полиморфизм типажей и дженериков в Rust куда лучше чем наследование абстрактных методов в той же Java. С одной стороны вроде как интерфейс (набор виртуальных методов), а с другой - no cost abstraction, потому все накладные расходы во время компиляции снимаются (ну также как Templates в С++). Ну, а если мы говорим про, скажем, массив экземпляров разных классов с одним интерфейсом, то тут я не вижу особых способов оптимизации даже руками программиста. То есть так или иначе будет if else или что-то типа того, завязанного на конкретном типе.
Если у Вас есть идеи как эту проблему исправить руками программиста (а не компилятора), было бы интересно узнать)
@@user-ob7tt2ku8r, разницы с Java никакой нет. Разница лишь в том будет инлайн или нет, а это зависит. А инлайна может не быть вовсе если вы соберёте себе Array - но тут вы явно попросили рантаймовых абстракций
Доклад очень интересный. Если брать аналогии с живым миром, никого не удивляет присутствие в нем птиц, насекомых, бактерий, рыб, растений, грибов и тд, но почему то в мире программистов все еще бывают споры относительно того, какой подход самый "правильный"))
Автор доклада явно уже определился, и счетчики ему не то, и циклы фу, а что под капотом они же и сидят - ну не видно, значит неть! Уровень передергивания зашкаливает.
@@berghauz споры про это все-равно не утихнут никогда и все ветки программирования будут развиваться, как и все живое на земле)) впрочем, пригладное программирование хочется видеть давно уже посредством "крупных кубиков", а не ломать копья про ООП/функциональное/структурное и етс программирование. Хотя отраслевые решения на эту тему уже имеются давно.
@@berghauz Не очень понятна суть претензии. Следуя этой логике, раз "под капотом" процессор работает с машинными кодами, то все, кто считает более эффективным писать код хотя бы на ассемблере или на более высоких уровнях абстракции и так делают - "передёргивают".
Речь же идёт конкретно про код программиста, который выполняет бизнес-задачу. На 8:39 был отличный пример. Декларативный код, который описывает суть задачи, занимает три строки. Проще читать, проще поддерживать. Чем лучше 10+ строк кода с циклами, проверками и счётчиками, который делает абсолютно то же самое?
Понятно, что надо всегда быть разумными и использовать более применимый подход для кажого конкретного случая. Но доклад автора был только про ФП, в этом смысле тоже претензия непонятна
@@NICKy1038ausc На 8:39 был отличный пример сахара, какое отношение этот пример имеет к счетчикам, циклам и всему прочему, о чем выступающий говорил минутой ранее? Никакого, но выступающий зачем-то акцентировал свое внимание на зашкварности использования этих методов, словно все программисты, пишущие "эффективный" код только и занимаются тем, что считают строчки в файле. Это и называется - передергивать.
@@berghauz Это рофл? Прямое отношение. Вы смотрели видео, суть поняли? Были показаны два метода, которые делают одно и то же. В императивном и функциональном стиле. Первый занимает гораздо больше места и менее читаем из-за того, что в теле этого метода используются циклы и счётчики, о которых шла речь.
В хорошем читаемом коде метод должен делать одну вещь и делать её хорошо. Перебор коллекции и чтение файлов посимвольно - как раз примеры того, почему императивный метод не является хорошо читаемым кодом. Когда все рутинные действия были вынесены в методы поменьше, функциональный код стал гораздо более лаконичным и декларативным. Он и пишется гораздо быстрее, и читается как книга: последовательно и на понятном языке. А не как код студента-младшекурсника. Программисты на реальных проектах ощутимо быстрее пишут код и быстрее его поддерживают, с этим очень странно спорить. Никто не считает каждую строчку кода, но когда функциональный код на практике В ТРИ РАЗА короче, это огромная разница.
А так любую удобную абстракцию можно назвать сахаром и сказать, что она не нужна. И так раньше нормально жили, чего вообще развиваться, усваивать что-то новое и увеличивать производительность программистов.
Вы сами-то решаете реальные задачи? И как, императивно? Пробовали иначе? Поделитесь, пожалуйста, своим опытом.
Включила на прослушку, показалось Вячеслав Мясников говорит... =)
Хочу такой презентер с "подсветкой экрана"
Управлять не очень удобно!
Я видел другой режим: фон не становится чёрным, а пятно желтоватое или красноватое (с прозрачностью).
00:15:40 - чел 100% закрывает вопрос что такое ФП и ООП, красавчик есть же
Какой нафиг компилятор с искусственным интеллектом, о чём они ?
3734 note
когда лектор оговорился про то, что скорость - это проблема компилятора, я выключил. какие знакомые боевые фразы.
Чёт херь какая-то.
Надеюсь,что в комитете Haskell этот человек просто пьёт кофе
Общий смысл - переходить на языки ещё более высокого уровня, а если будет плохо работать - это виноваты разработчики компилятора, что дураки - остались на низком. 😎
Штош, компилятор виноват в медленном коде, так заказчику и скажем, пусть подождет пока допилят...
на кого вешать собак разрабам компилятора ? :) короче выяснится, что во всем виноват собака Тьюринг
Дано: гугл-1шт. ,есть поток данных n>1, дискретность данных будет n>1÷a+(b•b). Сжатие фаилов b не позволяют высокоуровнивые кодаки. основанные на последних языках програмирования, т.к в фортан больше не могем. Попытки сжимать медиа.- нейросетями привели к неслабой ловле лулзов. Вопрос: сколько потребуется времени чтобы компания гугл освоила сжатие медиафаилов крипто шифрованием, используя при этом сторонние мощьности?
Бред.
Хаскелевский интерпретатор и вправду медленный. Отсюда вопрос: если хаскелисты, сплошь и рядом - ученые-исследователи и математики, то почему бы не написать быстрый компилятор для своего языка?
потому что ученые-исследователи и математики не инженеры
компилятор или интерпритатор? GHCI - медленный так как интерпретатор. А вот GHC - вполне быстрый, главное писать директиву ghc-options: -o2 в package.yaml, чтобы включилась оптимизация
Ну так он медленный, потому что умный. Что не понятно, это 2 стороны одной монеты. Но пока Хаскеллист напишет код за x времени, напишет y тестов и будет ждать z времени компиляцию. Какой-нибудь гошник напишет то же самое за 5x времени, напишет 3y тестов, но скомпилирует быстрее, кто в итоге продуктивнее
Да я на ассемблере функций наделал средствами макроса и функионирую! ))
пишу программы на машине Тьюринга, симулированной в игре жизнь и не жалуюсь))
очередной манямир функциональщиков на этапе вопросов
Python ведь тоже на 79% функциональный. А вы его не упомянули, почему ? Как будете оправдываться ?! А ?!
АААААААА !!!!
А не че, что он ООП и сам создатель языка до последнего не хотел добавлять функциональные методы по типу map, filter, reduce и тп
Очень сильный язык, боится оговорится.
Что там функционального. Лямбды однострочные или может быть отсутствие иммутабельных данных