СОРВАЛИ ПОКРОВЫ ТАК СОРВАЛИ) Ждем видео, в котором Экстримцод расскажет, что языки высокого уровня это абстракция над языками низкого уровня Под названием "Языки вафлесокого уровня"
Поставил лайк за смешную шутку) Но видео, и правда, срыв покровов, так как сами сторонники ФП не признают ничего из того, что было сказано в видео. Пролистни просто комментарии и увидишь, что люди считают, будто у них ФП - это волшебный код, который работает сам по себе и обладает сверхпреимуществами (внятно перечислить которые они не в состоянии, но точно гарантируют, что эти преимущества есть).
@@ergo_____3491 Преимущество ФП кода в том, что он во многих случаях получается гораздо компактнее, легче читается, легче отлаживается, однажды отлаженный гораздо чаще работает как положено в любом окружении. Стало быть если применять его по назначению, действительно здорово снижается время на разработку и поддержку. Недостаток в том, что очень сложно сделать так, чтобы он работал каким-то конкретным способом. И если функциональный код работает плохо (жрет память, тормозит), то отладить это чрезвычайно трудно, и проще всего такой участок надо просто переписать в императивном стиле.
@@ergo_____3491 Я тоже поржал. Пишу на Haskell уже 5 лет, сначала тоже пытался объяснять и агитировать, но через полгода надоело. Люди всё равно не понимают о чём речь, пока сами шишек не набьют. Думаю, именно из-за таких новичков, как я когда-то, у адептов ФП настолько сомнительная репутация. Если говорить конкретно про Haskell, то каких-то "сверхпреимуществ" у него нет - в основном, пока только обещают и экспериментируют. С обычными преимуществами всё просто: отличная система типов, лаконичный синтаксис, хороший компилятор - остальное либо субъективно, либо прямо вытекает из вышеуказанного. Насчёт "волшебного кода" - да, есть такая проблема. В начале изучения ФП новичок всегда сталкивается с большим объёмом новой информации и специфической терминологии, которые приходится "переваривать" в несколько этапов из-за большого количества взаимосвязей. Мы сами уже настолько не стесняемся это признавать, что документация некоторых библиотек ссылается на научные статьи, а в описании одного из стандартных типов прямым текстом говорится: "deeply magical".
Вышеотписавшимся ораторам: вы подменяете понятия "парадигма программирования" и "язык программирования" - это логическая ошибка, совершение которой говорит о некомпетентности в обсуждаемом вопросе (если вы парадигму от языка, реализующего парадигму, не отличается, о чем тут говорить?). У других парадигм есть свои отличительные признаки: Императивная - смотрит на программный код, как на последовательность инструкций. Процедурная - смотрит на код, как на именованный набор последовательных инструкций, логически объединенных по признаку выполнения отдельных задач. ООП - смотрит на код, как на объекты реального мира, в которых объединяются их свойства (поля/характеризующие их данные) и их поведение, представленное процедурами. А про ФП вы что сказали? Лаконичность и понятность. Во-первых, это все относится к синтаксису конкретного ЯП, во-вторых, это субъективные категории, в-третьих, эти черты в той или иной мере присущи любому ЯП любой парадигмы, в-четвертых, не привели никакой конкретики. На все это можно ответить "нет, вы неправы" и на этом ваши тезисы рассыпались, потому что возразить по существу нечем.
Императив - описание алгоритма действий для получения желаемого. Декларатив - вы лишь указываете, чего вы хотите, но не указываете, как этого достичь. Лайканье видео не является декларативом, потому что не сообщает о намерениях. Я, например, лайкаю просто что бы отличать новые ролики от уже просмотренных.
Уважаемый автор, вы великолепны!!! Чувствую необходимость вам сообщить о том что ваши работы на данной площадке выше всяких похвал, будьте любезны продолжать в том же ключе. С превеликим уважением, отпищек.
@@ТарасА-к5р Можно ещё зарофлить рофл над рофлом, в формате рофла, что в свою очередь, в виду сложившейся тавтологии, будет являться рофлом! P.s. В зависимости от тяжести и количества принимаемых веществ, парадигму можно продолжить...
Декларативность это когда ты описываешь только то, что ожидаешь, а не инструкции как этого результата достичь. Банально вот две реализации чисел Фибоначчи на С: Декларативный вариант int fibonacci(int num) { if (num
Как человек, который НЕ пользуется функциональным подходом к программированию, могу сказать, что основная фишка функционального программирования в том, что там нет понятия состояний. Это позволяет легче отслеживать то, что происходит в коде, и позволяет избежать подводных камней, когда вызов метода вернул что-то не то, потому что состояние объекта было изменено перед его вызовом кем-то другим. Мы в ООП парадигме тоже пытаемся за этим следить, но только ООП принципиально противоречит функциональному подходу и по определению делает методы объекта "грязными", потому что сама суть многих методов - это не вернуть значение, а изменить какое-то состояние. например в ООП запись чего-то в сокет выглядела бы так: открыть сокет, записать в сокет, закрыть сокет. При этом если после "закрыть сокет" попробовать передать в него снова "записать в сокет" вылетит ошибка, потому что состояние сокета неправильное в функционально парадигме это бы вылгядело: вернуть сокет, вернуть результат записи в сокет. таким образом состояние сокета неизменно, и для него снова же можно вызвать "вернуть результат записи в сокет" передав новую порцию данных, и ничего не упадёт. А закрытие сокета будет где-то под капотом спрятано в момент выхода за пределы области видимости переменной сокета, или типа того. То есть переменная на всём протяжении своей жизни не меняет никакие состояния, а потому её значение намного легче проследить, да и работать с ней намного проще, так как не приходится заморачиваться о том, а можно ли вызвать вот это вот в этом месте или вот в такой последовательности. У них там даже есть целая процедура доказательства иммутабельности данных в коде (то есть всё, что может на это повлиять прячется под капот и доводится до состояния, чтобы к моменту выхода из функции все состояния были откачены обратно к тому, какими они были при её вызове) :) Вот где основная польза функционального программирования и почему это намного больше, чем попытка выдать обычный уровень абстракции за принципиально новый подход. Это на самом деле принципиально новый подход с кучей преимуществ, в том числе дающий более стабильный код. Правда и писать так сложнее, потому это дороже, и это минус функционального программирования.
Полностью поддерживаю. Речь не идёт о том, что императива больше нет. Речь идёт о том, что в языке не используется эта парадигма. Все внутри языка и не доступно пользователю. Это обеспечивает безопасность. Так же как в джаве безопасность обеспечена обертками и джава машиной. В плюсах менее безопасно из-за наличия возможности ручками нагадить там где норм человек будет использовать безопасные обертки. Ну от оберток не уйти, нигде, ни в функ, ни в ооп. А в нутрях голимый императив!!! Алгоритмы по-другому мать их не работают!!!
Я бы еще добавил правильную семантику: вместо сообщение.передать() можно сделать передать(сообщение). ООП хорош, когда делаешь модель чего-то, но когда описываешь процесс, появляются всякие билдеры, процессоры, хэлперы и тп. - объекты, которые должны выполнить функцию и вообще не оч связаны с самими объектами. В этом через год сам автор кода ногу сломает. Какие-то вещи действительно правильней реализовывать в виде ООП и процедурщины, но если в итоге это описывает процесс, то для дальнейшего использование вполне норм обернуть это в стэйтлесс функцию.
@@TheVolkovAlexandr в ООп я бы тоже не стал делать сообщение.передать(). В этом случае правильно было бы написать канал.отправить(сообщение). данные не должны отвечать за свою передачу кому-то куда-то. Так что нет, тут не катит, потому что семантику можно соблюдать и при ООП.
пример с сокетом некорректен, возвращается "новый сокет" из которого потом опять можно читать/писать и возвращается опять "новый сокет", а поверх всего этого монады или что-то аналогичное, вот только ошибки будут те-же самые, т.к. в данном случае побочные эффекты императивности будут фактически эмулироваться.
@@marvinnimnull9982 немного не понял зачем каждый раз новый сокет возвращать и как тогда узнать, что запись в сокет провалилась, если возвращаться будет сокет, а не результат операции?
Впервые не понял, что ты хотел сказать в видео, но лайк поставил. Декларативность - это действительно еще один уровень абстракции и это как раз и плюс, потому что тебе не нужно мясо, тебе должно быть пофиг, как официант его тебе принесет. Под капотом может быть несколько реализаций принести мясо - побежать пешком, прягнуть на скейт и поехать... Подкапотщину ты можешь легко менять без смены декларативного кода. Я думаю, что ты прекрасно и так все это понимаешь. Возможно главный вопрос - зачем, если можно без декларативщины сделать ООП абстракцию, и точно также менять реализацию классов, а потребители классов и не будут замечать, что что-то там изменилось. Отвечаю - это всего лишь вопрос читабельности. Функциональщики утверждают, что их LINQ читается лучше, чем если ты то же самое будешь скрывать с помощью ООП. Те, кто согласен с этим утверждением и для них читабельность декларативности действительно указывает на уровень мастерства, те используют функциональщину. Те, кто не любит это, те посылают на болт функциональщину и продолжают писать код старым методом. Лично я сижу на двух стульях, при работе с массивами и XML я люблю функциональщину, при работе с БД я люблю старый метод.
@@ergo_____3491 в ФП функции принимают и возвращают функции. Эта единственная фича заменяет как интерфейсы так и половину других шаблонов проектирования ООП автоматически =)
@@vladimirviktorovichivanov7577 ничего она не заменяет. Как вообще передача функции аргументом должна заменить все конструкции программы? Единственное, что в ФП заменяется - это отсутствие циклов, вместо которых вынужденно используются хвостовые рекурсии в качестве костылей (чтобы не получить переполнение стека при использовании обычных рекурсий). И функции возвращают не функции (это ж надо такое сказать), а данные, которые передаются вызывающей функции. Отличительная черта ФП - это организация кода на основе чистых функций, за счёт чего экономятся вычислительные ресурсы и упрощается распараллеливание кода, а также функций высшего порядка, что упрощает написание некоторых частей кода (и эта фишка реализована и в неФП-языках). Решаются вполне конкретные прикладные задачи. Серьезно, хоть бы один сторонник ФП об этом сказал.
Этот чувак меня всегда радует своим взглядом и способом подачи. Вот прямо о наболевшем. Молодец! Нам не хватает таких оздоравливающие мозг роликов. Весь здравый смысл кодинга только на твоих видосах держится.
>полиморфизм Загадочная, полумифическая штука. Никто не знает, что это такое, но все считают, что без этого ООП не ООП. Хорошо, если бы существовало объяснение от обратного: показали бы пример языка, начисто лишённого полиморфизма, как выглядел бы такой язык, чего бы в нём невозможно было сделать, или показали что за зверь такой не полиморфная функция, как как ведёт себя эта функция. И ещё очень интересно, какая связь между полиморфизмом и лямбда-исчислением? Если с наследованием, классами, методами, атрибутами в ООП всё ясно и однозначно, то полиморфизм и инкапсуляция напоминают чистейшее мифотворчество: апологеты ООП понимают под этими терминами что хотят.
@@ЕгорСоловец-л1н А что в полиформизме и инкапсуляции непонятного? Полиформизм - это буквально возможность наследуемого класса перезаписывать методы родительского класса. Инкапсуляция - это разграничение доступов к элементам класса. ООП на самом деле не такой сложный, как многие о нем рассказывают. В ОПП есть много специфики из-за чего многие трактуют его постулаты как хотят.
Я зашел, мне там кто-то понравился, я поставил лайк, поставил то се. Видосик посмотрел полностью, да никогда не поленюсь написать в комменте. Чувак красава! Охуенный видос, я сорок минут на нём залипал! Кип дуин вот ю дуин бро!
Функциональный подход - это как SOLID, некие правила/рекомендации/ограничения построения архитектуры приложения, которые в рамках определённых задач могут дать более чистый/короткий/лаконичный/%youradjectivehere% код. И какие-то языки более способствуют такому стилю, хотя в принципе на любом языке, где есть функции высшего порядка, можно писать в функциональном стиле.
Как по мне, то вся соль функциональных языков заключается в двух вещах: 1) все функции чистые, что решает проблему общего состояния с непредсказуемым значением, так как его можно изменить из каждого места кода 2) можно применять операторы над функциями. Это интересная и полезная вещь, если в ней разобраться
@@marvinnimnull9982 что Вы так к этим монадам прицепились? ) их функция совсем в другом же. Монады используются для выполнения операций над последовательностями. Для того, чтобы сделать обычный рандом, нужно вызвать обычную функцию рандом. Монады нужны тогда, когда Вы хотите, например, создать массив рандомов. Да, в этом случае нужна функция, которая сможет получить уже имеющееся состояние последовательности и добавить к ней одно значение. Ну или если Вам надо посчитать сумму элементов массива, то тут да, тут тоже монада нужна, потому что каждый раз она будет возвращать массив на 1 элемент короче, в котором последним элементом будем сумма двух последних элементов предыдущей монады, а всё остальное будет таким же, и остановится эта функция когда останется один элемент, являющийся полной суммой массива. Вы сложности на пустом месте придумываете. :)
@@nikolaymatveychuk6145 вот именно, над последовательностями с общим состоянием (ключевое), со списками и так можно работать (каждый раз создавая новый cons/car/cdr + рекурсия), нюанс функции рандом в том, что она не может быть чистой и выдавать случайные числа не изменяя собственное состояние (если только это не опрос аппаратуры). А насчёт монад - в своё время была книга Тимоти Бада "Мультипарадигменное програмирование в LEDA" там он вводил тип relation - вот это была монада в чистом виде :-) и делал он это ещё до того, как хаскель создали (и уж тем более, как он стал популярным). А сложности? ну, я за мультипарадигменные системы :-) язык должен от задачи идти.
@@marvinnimnull9982 ещё раз хочу уточнить что Вы подразумеваете под "не меняя собственное состояние"? У Вас с моей точки зрения странное представление о смене состояния. То есть Вы хотите сказать, что если я буду случайным образом запускать или не запускать функцию random в цикле и потом вызывать Вашу функцию, то Вы в ней гарантированно сможете определять, вызывал ли я рандом на этой итерации цикла или нет? КАК? :)
@@nikolaymatveychuk6145 а как можно случайно запускать или не запускать рандом без самого рандома? теперь уже я не понимаю. Под состоянием имеется в виду простая вещь - каждый запуск функции от неизменных аргументов должен выдавать неизменный результат. Тогда функция чистая и состояние среды вычисления не меняется (между запусками). 1+2 вернёт 3 всегда, неважно как часто и в каком порядке вы будете это делать. read/write всегда будет менять среду (как минимум выдавая/принимая символы с устройства), т.е. у этих функций есть побочный эффект. отличие такое-же как между set и let, первая изменяет имеющийся символ, а вторая вводит новый, который уже не может изменяться.
Классное объяснение. Побольше бы такого. На твоих видео я начал учится программировать, вот прямо цепляет и хочется узнавать что-то новое в этой среде. Жду новых видео. Спасибо 👍
@@HuKuTa944 Ну, наверное, подставил очко менеджеру. А менеджер скорострел, вот как раз и управился за двееее минуууууты :-D. Наверное единственный способ стать синьёром столь быстро.
"Принеси мне сендвич" это такой же императивный стиль. В декларативном стиле будет "Это сэндвич на столе, который принес официант который приготовил повар. Где сэндвич это хлеб + сыр + ветчина + помидор + хлеб"
уууууууууууууу, декларативность, императивность, чё так сложно-то, я вот просто сижу и прогаю, какие-то там классы создаю и тп а вообще лайк тебе, чувак, подача по кайфу, всё понятно 👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще! Данное сообщение (материал) создано и (или) распространено иностранным средством массовой информации, выполняющим функции иностранного агента, и (или) российским юридическим лицом, выполняющим функции иностранного агента
Нифига конечно в конце дядюшка Артем трансформировалься в Колю, нормальный переход))) а так круто что объяснили вот эту вот непонятку с декларативностью, хоть что то стало понятно про функциональщину, спасиба, однозначно, братан хорош вообще крассавчик, ставлю лукас :)
А что тогда с ООП, ведь в недрах методов тоже будет императивщина. Мне кажется обзывать псевдофункциональным или псевдоООП любой ЯП будет не справедливо, просто за то, что в нем есть выход в реальный хаотичный мир.
@@kitu-brazilieru В любом языке вообще можно писать мультипарадигменно, кроме может быть совсем обфусцированных. ЯП лишь помогают следовать какой либо из парадигм, вопрос лишь в том, будешь ли ты им следовать. Любую императивщину можно архитектурно отделить от бизнес логики, в которой у нас и появляются гарантии и возможности писать чистый код.
Круто, спасибо) всегда эт в голове вертелось и думала, что мб я че то в этом жизни не понимаю просто, так сказать не познала дзен декларативщиков. Но в итоге такие мысли не у меня одной, и это прям успокаивает☺️
Брат, молодец! Продолжай в том же духе! Содержание видео мне нравится. Можно больше сего действа? Действительно красиво получилось! Можно повторять с большей регулярностью.
Ачо всмысле, какое-то там императивное, декларативное программирование - я всегда думал, что функциональное программирование просто помагает не загаживать код миллионом имплементаций какой-то функции, если каждая имплементация нужна только один раз
Давай разберём по частям тобою скзаанное. В общем ты типа прав во всем, да есть костыли в виде императива, иначе просто никак, железо в итоге работает по императивным принципам, а декларативный стиль это надстройка, но почему она от этого не может быть крайне удобной? А? А??
@@Dadadadam999 Ни вообще ни разу. Я как-то ради прикола придумывал визуальный способ представления функционального кода, так вот он на блупринтовый визуальный язык не похож совершенно потому что в ФП функция - это объект первого уровня, то есть функция принимает другие функции в качестве аргументов и возвращает функцию как результат своей работы. Таким образом код ФП нельзя описать как блоки со связями между ними. Он будет выглядеть как матрешка где функции вставляются в в другие функции и в результате всего получается третья функция.
@Илья Прусаков суть не в этом. разница в том, как достигается конечный результат: описанием результата, который необходимо получить, или описанием как его получить. Например разные функции фильтров массивов являются декларативными, потому что вызывая их, в аргументы передаётся не алгоритм отсеивания лишних элементов, а правило, которому должны соответствовать оставшиеся/отсеянные элементы. Само происхождение слов говорит о том, что один метод описательный, а второй повелительный. И все эти примеры "принеси мне мяска" это выдумка тех, кто не понял в чём прикол. На самом деле в примере с официантом декларативный метод был бы "мне нужно мясо", в то время как императивный высокого уровня звучал бы как раз "принеси мне мясо". Или если подняться на уровень выше,чтобы была понятнее разница, то декларативно мы бы сказали "проголодавшись я буду нуждаться в мясе", а императивно "если я голоден, принеси мне мясо". Ну или как-то приблизительно так... надеюсь основная идея понятна.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще! P.S. спасибо тому, у кого все скопировали этот текст.
На самом деле, нет ничего плохого, если юзать мультипарадигменные языки, совмещая императивный и декларативный стили там, где это удобнее и понятнее. Например, в каком-нибудь Котлине, если нужно найти в коллекции объектов какие-то объекты по определённым условиям, гораздо удобнее вызвать на коллекции функцию-расширение find, передав ей лямбда-выражение, по которому будет производиться отбор. Как итог, вместо этажей из for-ов и if-ов, элегантное решение в одну строку, причём гораздо более удобочитаемое. Хуже, когда, имея возможность использовать разные подходы, человек тупо упирается во что-то одно и, как сектант, юзает это везде (только ООП или только функциональщина). Примерно так же, как и с языками программирования.
Это ты своими ебучими лямбдами не шерстил нормальный объём данных, с серьёзным условием. Они по итогу вообще перестают быть читабельными после четвёртой точки, когда ты собираешь вновь отфильтрованные данные. Ибо человеческому мозгу уже сложно удержать всю ту херову гору операций которые произошли изначальной коллекцией. Добавь сюда ещё специй из «нейминга» разных промежуточных значений типо i, map, list и т.д В итоге элегантное выражение в три точки превращается в нечитаемый отрывок, назначение которого забудут через полгода, а следующему копателю говна мамонта придётся это разбирать значительно дольше чем старые добрые, но уже «не красивые» вермишели if/else
@@ProGuitarUA если "шерстить нормальный объём данных, с серьёзным условием" при помощи for/if/else, то кода станет гораздо больше и читать его будет сложнее. Про "специи нейминга разных промежуточных значений" вообще не понял к чему это здесь; если у тебя одна коллекция вложена в другую, внутри лямбды ты можешь так же на вложенной коллекции вызвать функцию-расширение find или filter (или любую другую подходящую под ситуацию, ибо в том же Котлине их дохуя на все случаи жизни). С точки зрения читабельности в коде всё понятно что и откуда вызывается, поскольку для читающего код скрыты все сложные реализации коллекций и фильтров, а видна только сама бизнес-логика. А вот если это делать в имеративном стиле, получится хуева гора условий и циклов, "i", "j", write-only код, где как раз таки хуй разберёшься через пол года.
Логика видео: *_Я - человек, состою из атомов и палка состоит из атомов, значит палочка и человек это одно и тоже, выходит надо уравнять права человека и палки._*
Насколько я понимаю, в функциональных языках декларативность - это всего лишь побочный эффект фокуса на композиции. Идея не в том, чтобы писать "декларативно", а в том, чтобы писать максимально переиспользуемые компоненты. При этом оказывается, что, когда композируемость стоит во главе, код сам становится декларативным. При этом современное ООП точно также одобряет композицию, и у тебя точно также получается хороший декларативный код. P.S. на самом деле я fan-boy функционального программирования, но у меня такое ощущение, что некоторые не замечают насколько у ФП и ООП много общего, фокусируясь исключительно на различиях.
Очередной набор общих фраз ни о чем) Императивная парадигма: монолитный набор команд. Процедурная парадигма: набор команд, направленных на выполнение определенной задачи, объединяется в именованные блоки кода. ООП: программные сущности конструируются по образу объектов реального мира, данные объединяются в блоки с методами (функциями), изменяющими эти данные. Функциональная парадигма: ну... эээ... декларативность, ну, или, эээ... композиционность, ну, или, эээ... буковки и цыфэрки, потому что когда буковки и цыфэрки во главе угла код переиспользуемый и декларативный, в ООП буковки и цыфэрки тоже есть. Убедительно. А на различиях концентрируются, чтобы отличать одно от другого, если бы концентрировались только на общем, то ФП бы не существовало.
@@ergo_____3491 Видимо мы с тобой совершенно по-разному мыслим, потому что твой коммент я тоже абсолютно не понял. А по поводу различий я с тобой не согласен, из статей которые я читал видно только одно: евангелисты ФП, как автор канала и сказал, хвастаются тем как у них все офигительно и как ФП - это "совершенно другой мир", и нужно "забыть всё, что ты знал про программирование до этого", когда это совершенно не так и фундамент у обоих подходов один. "Если бы концентрировались только на общем, то ФП бы не существовало" - тоже не ясно откуда такие выводы взялись, как концентрация на различиях привела к появлению ФП? Alonzo Church же параллельно с Turing'ом этот вопрос изучал, они даже не знали, что одно и то же изучают..
@@ergo_____3491 вы смешали в кучу "парадигмы в большом" (вычислительные модели) и "парадигмы в малом" подходы к организации программного кода. Хотя, если это был сарказм, то он не следует из ответа того, кому вы оппонируете.
Сейчас и в ООП-языках, в той же джаве - полно разных функциональных штук - редьюсы, фильтры и иже с ними. Уж для перекладывания массива в мапу никто нормальный в 2022 не будет циклы использовать).
Спасибо, Братан, что такую тему поднял! Почитав Википедию, я так понимаю, что преимуществом Функционального ЯП является то, что выполнение его кода может быть в некоторой степени оптимизировано, ценой большей траты времени программиста. Ибо писать чистые функции сложнее, чем дергать глобальные переменные внутри любого метода) Я прав?
Как раз наоборот, функциональные языки во многих местах медленнее как раз из-за того, что они дают куеву тучу абстракций, которые помогают писать код намного быстрее. Например, тот же Сlojure, быстрее чем на нем писать практически невозможно. На самом деле прикол функциональщины в архитектуре, ее нет) В смысле буквально нет, если у тебя нет ничего кроме функций, то и городить сраные clean architecture и прочие VIPER не из чего, а это приводит к единственному решение - реши блядскую задачу, возьми данные А из источника Б, и перебери их в данные В, потом засунь в источник Г.
Смотря какой код и какая оптимизация. 1. Функциональный код достаточно просто распараллелить без лишних усилий практически в любом месте, потому что все функции чистые и один поток физически неспособен обосрать малину другому. 2. Функциональность абстрагируется над такими вещами как память, поэтому байтошаманством заниматься не получится, и перегонка туда-сюда больших кусков данных может сожрать очень много рантайма. P.S. выполнение любого кода может быть оптимизировано ценой траты времени программиста. Это и есть смысл оптимизации - трахаться дополнительное время с кодом, чтобы он потом эффективнее выполнялся.
наоборот. программист куда меньше тратит времени на ФП код - потому что там нету кучи неявных зависимостей между мутирующими стейтами. суть в том что чтобы к этому прийти нужно изучить ФП и заложить в голову навыки написания такого кода. вы наверное пишете ООП код..? вот смотрите. вы же моежете всю программу одной портянкой в одну функцию написать. верно? это проще чем создавать объекты и выделять код в методы? с одной стороны да, как вы говорите - нужно думать куда что положить и в целом конструкций становится больше. с другой стороны поддерживать второй вариант куда проще, то же самое с ФП
Да, редко на просторах ютуба встретишь более хайпово-бэйтный бред, чем у автора этого видоса. Он там ответить на вопрос просил ещё в конце. Ну что же, тогда по пунктам: 1. Видео начинается с кучи тезисов с отрицательными коннотациями в адрес неких абстрактных функциональщиков в вакууме, которые автор даже не пытается доказать. Просто поток сознания: "хитрые и беспринципные байтеры", "нагло всех обманывают", "коварно и лживо завлекают людей перейти в свою веру" 2. Продолжает автор неизвестно откуда взятыми якобы высказываниями неких абстрактных функциональщиков в вакууме: "у нас всё декларативно", "мы флексим". 3. Дальше идёт одна довольно трезвая мысль, но тоже не без недостатка: "декларативность - это абстракция поверх императивности", при этом абстракция у автора, почему-то в кавычках, хотя они тут и не нужны. Декларативность - это действительно абстракция поверх императивности, но ценность у ней от этого не исчезает. Автор врядли программирует в машинных кодах, а всё что выше, включая ассемблер - уже абстракция поверх языка, который понимает машина. Да и сами машинные коды - абстракция поверх физических процессов, происходящих в компьютере. 4. Затем идёт ещё один малопонятный тезис про некоего функциональщика, который начал автору рассказывать про SQL после того, как автор "продавил ему петрушку". Интересно бы узнать уровень навыков знаний этого самого функциональщика. 5. Далее идёт тезис про мёртвость пролога. Видимо автору не приходилось сталкиваться с решением проблемы авторизации в сложных распределённых системах, иначе он бы был в курсе существования rego - современного языка описания политик доступа, который является диалектом datalog/prolog 6. Следом, на примере того же пролога, автор оскорбляет всех учёных, занимающихся академическим программированием, сказав что порлоги придуман задротами для задротов. То есть учёные - задроты, к тому же ненормальные, так как, опять же со слов автора, нормальным людям туда (в пролог) вход строго запрещён. 7. Ну и в финале автор требует ответа на вопрос, который он сам сформулировал на основе того, что некие абстрактные функциональщики в вакууме , реализуя функции императивно, называют это декларативностью. При этом ещё что-то невнятное про лицо приплёл. Это всё к тому, что у автора 0-5% полезного познавательного контента в видео и где-то 95-100% безграмотного высера ни на чём не основанного. Теперь же про ФП: основное отличие от той же процедурной парадигмы вовсе не в декларативности, а в том, что функции в ФП могут быть аргументами других функций и результатами работы других функций. Если же говорить про "чистое" ФП, то там ещё вводится понятие чистой (ссылочно прозрачной) функции, и это подмножество ФП, хотя и менее удобно на практике, имеет под собой строгое математическое основание в виде лямбда исчисления. Надеюсь, после этого короткого экскурса, автора стало яснее, чем же ФП отличается от других парадигм. Так же очень надеюсь, что автор примет критику к сведению, и будущие видео окажутся более информативными и менее хайпожорными.
Долго мотал коменты, и был в шоке - неужто тут нет ни одного адекватного человека? Слава Богу хоть один нашелся! Спасибо вам за здравые мысли с которыми полностью согласен! Жаль остальных адептов этого блогера. Их уровень нагляден - большинство постов тут начинается с почти гопницкого - "Братан, хорош!/красавчик/молодец/..." и жаль, что с таким "гуру" им не суждено подняться выше, лишь совсем им мозги засрет. По теме лишь добавлю, что поскольку ФП в идеале оперирует неизменяемыми данными, то оно очень хорошо распараллеливается, снимается проблема организации общего доступа к данным, race condition, блокировки... Более того, это распараллеливание может автоматом делать компилятор, благо ФП это фактически чистая математика (чистые математические функции) и в computer science тут все очень хорошо исследовано, доказана куча теорем... и все это компилятор может использовать для вывода наиболее эффективного и распараллеленого вычислительного потока (вернее потоков). Как известно, тактовая частота процессоров почти уперлась в свой физический предел и дальнейшее повышение производительности уже давно идет за счет увеличения числа ядер. И это одна из важных причин почему ФП сейчас становится все популярнее. Функциональные фишки по моему наблюдению это то как сейчас эволюционируют языки - их добавление основной тренд эволюции старых языком и обязательный стиль для новых. Честно говоря, даже не верится что автор ролика настолько тупой. Возможно он специально делает такие провокационные ролики, чтобы собрать реакцию от аудитории, раскрутиться и как конечная цель - получить побольше гешефта. Это первый и последний ролик, что у него посмотрел.
@@nikolay7658 доооо. Это же не так, что монады позволяют ясно с эффектами манипулировать и комбинировать, без всяких костылей в виде эксэпшэнов и налов🤢
@@nikolay7658 ну тогда вперёд в жизнь без абстракций. В структурное программирование! А те дураки кто хочет не страдать от налов, эксэпшэнов пусть дальше свои монады используют
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще. 🦧🦧🦧
Давайте, пока!
дошёл до комма ровно в момент, когда он это говорил
прошёлся как по субтитрам, лол
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
@@ФилиппФилиппович-д6э Хм. А экстрим сидит у вудуша?
@@arbitermoralis2548 вот чего я точно не ожидал, так это Вудуш коммьюнити тут... (сам сижу)
СОРВАЛИ ПОКРОВЫ ТАК СОРВАЛИ)
Ждем видео, в котором Экстримцод расскажет, что языки высокого уровня это абстракция над языками низкого уровня
Под названием "Языки вафлесокого уровня"
Поставил лайк за смешную шутку)
Но видео, и правда, срыв покровов, так как сами сторонники ФП не признают ничего из того, что было сказано в видео.
Пролистни просто комментарии и увидишь, что люди считают, будто у них ФП - это волшебный код, который работает сам по себе и обладает сверхпреимуществами (внятно перечислить которые они не в состоянии, но точно гарантируют, что эти преимущества есть).
@@ergo_____3491
Преимущество ФП кода в том, что он во многих случаях получается гораздо компактнее, легче читается, легче отлаживается, однажды отлаженный гораздо чаще работает как положено в любом окружении. Стало быть если применять его по назначению, действительно здорово снижается время на разработку и поддержку.
Недостаток в том, что очень сложно сделать так, чтобы он работал каким-то конкретным способом. И если функциональный код работает плохо (жрет память, тормозит), то отладить это чрезвычайно трудно, и проще всего такой участок надо просто переписать в императивном стиле.
а языки низкого уровня - обертка для работы с электрончиками в полупроводниках)))
@@ergo_____3491 Я тоже поржал.
Пишу на Haskell уже 5 лет, сначала тоже пытался объяснять и агитировать, но через полгода надоело. Люди всё равно не понимают о чём речь, пока сами шишек не набьют. Думаю, именно из-за таких новичков, как я когда-то, у адептов ФП настолько сомнительная репутация.
Если говорить конкретно про Haskell, то каких-то "сверхпреимуществ" у него нет - в основном, пока только обещают и экспериментируют. С обычными преимуществами всё просто: отличная система типов, лаконичный синтаксис, хороший компилятор - остальное либо субъективно, либо прямо вытекает из вышеуказанного.
Насчёт "волшебного кода" - да, есть такая проблема. В начале изучения ФП новичок всегда сталкивается с большим объёмом новой информации и специфической терминологии, которые приходится "переваривать" в несколько этапов из-за большого количества взаимосвязей. Мы сами уже настолько не стесняемся это признавать, что документация некоторых библиотек ссылается на научные статьи, а в описании одного из стандартных типов прямым текстом говорится: "deeply magical".
Вышеотписавшимся ораторам: вы подменяете понятия "парадигма программирования" и "язык программирования" - это логическая ошибка, совершение которой говорит о некомпетентности в обсуждаемом вопросе (если вы парадигму от языка, реализующего парадигму, не отличается, о чем тут говорить?).
У других парадигм есть свои отличительные признаки:
Императивная - смотрит на программный код, как на последовательность инструкций.
Процедурная - смотрит на код, как на именованный набор последовательных инструкций, логически объединенных по признаку выполнения отдельных задач.
ООП - смотрит на код, как на объекты реального мира, в которых объединяются их свойства (поля/характеризующие их данные) и их поведение, представленное процедурами.
А про ФП вы что сказали? Лаконичность и понятность. Во-первых, это все относится к синтаксису конкретного ЯП, во-вторых, это субъективные категории, в-третьих, эти черты в той или иной мере присущи любому ЯП любой парадигмы, в-четвертых, не привели никакой конкретики.
На все это можно ответить "нет, вы неправы" и на этом ваши тезисы рассыпались, потому что возразить по существу нечем.
Императивно - это когда пишешь коммент:
"Вообще четко. Давай еще больше. "
Декларативно - это, когда просто лайкаешь видео🙂
Императив - описание алгоритма действий для получения желаемого. Декларатив - вы лишь указываете, чего вы хотите, но не указываете, как этого достичь. Лайканье видео не является декларативом, потому что не сообщает о намерениях. Я, например, лайкаю просто что бы отличать новые ролики от уже просмотренных.
Уважаемый автор, вы великолепны!!! Чувствую необходимость вам сообщить о том что ваши работы на данной площадке выше всяких похвал, будьте любезны продолжать в том же ключе. С превеликим уважением, отпищек.
Ты что функциональщик?
@@apdgslfhsodbna , я мимокрокодил
@@samuelvimes4807 , что ты куришь, я тоже хочу
@@apdgslfhsodbna это уже рофл над рофлом...врафляние какое то...
@@ТарасА-к5р Можно ещё зарофлить рофл над рофлом, в формате рофла, что в свою очередь, в виду сложившейся тавтологии, будет являться рофлом!
P.s. В зависимости от тяжести и количества принимаемых веществ, парадигму можно продолжить...
Декларативность это когда ты описываешь только то, что ожидаешь, а не инструкции как этого результата достичь.
Банально вот две реализации чисел Фибоначчи на С:
Декларативный вариант
int fibonacci(int num) {
if (num
Точно! Первую лабу по функциональному программированию даю как раз такую - на Си оба варианта сделать. Ты не у меня учился?
@@deniskuznetsov7097 Нет)
Спасибо, классный пример
я думал это называется рекурсией, а не декларативностью, а какой пример есть без цикла?
так и получается, что вся функциональность в том, что реализацию "как делать" пишешь не ты, а её уже написали до тебя. а если не написали, ну что ж..
Вообще четко. Давай ещё больше. Не хватка таких видео. Твои видео как витамин C, только C++, что значит на два очка крутости больше!!!!
на одно...
@@darkvovka7792 Уже порвали?
@@nakidai инкремент же. Два очка рвутся и соединяются в одно больше
@@yehor612 Аа, а я не думал что можно делать экскременты с ними. Ну ок
C++ придумал дьявол
Как человек, который НЕ пользуется функциональным подходом к программированию, могу сказать, что основная фишка функционального программирования в том, что там нет понятия состояний. Это позволяет легче отслеживать то, что происходит в коде, и позволяет избежать подводных камней, когда вызов метода вернул что-то не то, потому что состояние объекта было изменено перед его вызовом кем-то другим. Мы в ООП парадигме тоже пытаемся за этим следить, но только ООП принципиально противоречит функциональному подходу и по определению делает методы объекта "грязными", потому что сама суть многих методов - это не вернуть значение, а изменить какое-то состояние.
например в ООП запись чего-то в сокет выглядела бы так:
открыть сокет, записать в сокет, закрыть сокет.
При этом если после "закрыть сокет" попробовать передать в него снова "записать в сокет" вылетит ошибка, потому что состояние сокета неправильное
в функционально парадигме это бы вылгядело:
вернуть сокет, вернуть результат записи в сокет.
таким образом состояние сокета неизменно, и для него снова же можно вызвать "вернуть результат записи в сокет" передав новую порцию данных, и ничего не упадёт. А закрытие сокета будет где-то под капотом спрятано в момент выхода за пределы области видимости переменной сокета, или типа того. То есть переменная на всём протяжении своей жизни не меняет никакие состояния, а потому её значение намного легче проследить, да и работать с ней намного проще, так как не приходится заморачиваться о том, а можно ли вызвать вот это вот в этом месте или вот в такой последовательности. У них там даже есть целая процедура доказательства иммутабельности данных в коде (то есть всё, что может на это повлиять прячется под капот и доводится до состояния, чтобы к моменту выхода из функции все состояния были откачены обратно к тому, какими они были при её вызове) :)
Вот где основная польза функционального программирования и почему это намного больше, чем попытка выдать обычный уровень абстракции за принципиально новый подход. Это на самом деле принципиально новый подход с кучей преимуществ, в том числе дающий более стабильный код. Правда и писать так сложнее, потому это дороже, и это минус функционального программирования.
Полностью поддерживаю. Речь не идёт о том, что императива больше нет. Речь идёт о том, что в языке не используется эта парадигма. Все внутри языка и не доступно пользователю. Это обеспечивает безопасность. Так же как в джаве безопасность обеспечена обертками и джава машиной. В плюсах менее безопасно из-за наличия возможности ручками нагадить там где норм человек будет использовать безопасные обертки. Ну от оберток не уйти, нигде, ни в функ, ни в ооп. А в нутрях голимый императив!!! Алгоритмы по-другому мать их не работают!!!
Я бы еще добавил правильную семантику: вместо сообщение.передать() можно сделать передать(сообщение). ООП хорош, когда делаешь модель чего-то, но когда описываешь процесс, появляются всякие билдеры, процессоры, хэлперы и тп. - объекты, которые должны выполнить функцию и вообще не оч связаны с самими объектами. В этом через год сам автор кода ногу сломает.
Какие-то вещи действительно правильней реализовывать в виде ООП и процедурщины, но если в итоге это описывает процесс, то для дальнейшего использование вполне норм обернуть это в стэйтлесс функцию.
@@TheVolkovAlexandr в ООп я бы тоже не стал делать сообщение.передать(). В этом случае правильно было бы написать канал.отправить(сообщение).
данные не должны отвечать за свою передачу кому-то куда-то. Так что нет, тут не катит, потому что семантику можно соблюдать и при ООП.
пример с сокетом некорректен, возвращается "новый сокет" из которого потом опять можно читать/писать и возвращается опять "новый сокет", а поверх всего этого монады или что-то аналогичное, вот только ошибки будут те-же самые, т.к. в данном случае побочные эффекты императивности будут фактически эмулироваться.
@@marvinnimnull9982 немного не понял зачем каждый раз новый сокет возвращать и как тогда узнать, что запись в сокет провалилась, если возвращаться будет сокет, а не результат операции?
Впервые не понял, что ты хотел сказать в видео, но лайк поставил.
Декларативность - это действительно еще один уровень абстракции и это как раз и плюс, потому что тебе не нужно мясо, тебе должно быть пофиг, как официант его тебе принесет. Под капотом может быть несколько реализаций принести мясо - побежать пешком, прягнуть на скейт и поехать... Подкапотщину ты можешь легко менять без смены декларативного кода.
Я думаю, что ты прекрасно и так все это понимаешь. Возможно главный вопрос - зачем, если можно без декларативщины сделать ООП абстракцию, и точно также менять реализацию классов, а потребители классов и не будут замечать, что что-то там изменилось. Отвечаю - это всего лишь вопрос читабельности. Функциональщики утверждают, что их LINQ читается лучше, чем если ты то же самое будешь скрывать с помощью ООП. Те, кто согласен с этим утверждением и для них читабельность декларативности действительно указывает на уровень мастерства, те используют функциональщину. Те, кто не любит это, те посылают на болт функциональщину и продолжают писать код старым методом.
Лично я сижу на двух стульях, при работе с массивами и XML я люблю функциональщину, при работе с БД я люблю старый метод.
функциональщина не описывается одной лишь декларативностью, вот и все
Теперь все понятно: зумеры "изобрели" интерфейсы и назвали это функциональным программирование.
@@ergo_____3491
в ФП функции принимают и возвращают функции. Эта единственная фича заменяет как интерфейсы так и половину других шаблонов проектирования ООП автоматически =)
@@vladimirviktorovichivanov7577 ничего она не заменяет. Как вообще передача функции аргументом должна заменить все конструкции программы? Единственное, что в ФП заменяется - это отсутствие циклов, вместо которых вынужденно используются хвостовые рекурсии в качестве костылей (чтобы не получить переполнение стека при использовании обычных рекурсий).
И функции возвращают не функции (это ж надо такое сказать), а данные, которые передаются вызывающей функции.
Отличительная черта ФП - это организация кода на основе чистых функций, за счёт чего экономятся вычислительные ресурсы и упрощается распараллеливание кода, а также функций высшего порядка, что упрощает написание некоторых частей кода (и эта фишка реализована и в неФП-языках).
Решаются вполне конкретные прикладные задачи. Серьезно, хоть бы один сторонник ФП об этом сказал.
@@torburgmax Не только, но это основное свойство, если можно так говорить.
Этот чувак меня всегда радует своим взглядом и способом подачи. Вот прямо о наболевшем. Молодец! Нам не хватает таких оздоравливающие мозг роликов. Весь здравый смысл кодинга только на твоих видосах держится.
Пили еще, а еще лучше в таком формате расскажи про опционалы, замыкания, полиморфизм и тд и тп. Нам нужен полный курс от тебя!!
айосер детектед
>полиморфизм
Загадочная, полумифическая штука. Никто не знает, что это такое, но все считают, что без этого ООП не ООП. Хорошо, если бы существовало объяснение от обратного: показали бы пример языка, начисто лишённого полиморфизма, как выглядел бы такой язык, чего бы в нём невозможно было сделать, или показали что за зверь такой не полиморфная функция, как как ведёт себя эта функция. И ещё очень интересно, какая связь между полиморфизмом и лямбда-исчислением?
Если с наследованием, классами, методами, атрибутами в ООП всё ясно и однозначно, то полиморфизм и инкапсуляция напоминают чистейшее мифотворчество: апологеты ООП понимают под этими терминами что хотят.
@@ЕгорСоловец-л1н А что в полиформизме и инкапсуляции непонятного?
Полиформизм - это буквально возможность наследуемого класса перезаписывать методы родительского класса.
Инкапсуляция - это разграничение доступов к элементам класса.
ООП на самом деле не такой сложный, как многие о нем рассказывают. В ОПП есть много специфики из-за чего многие трактуют его постулаты как хотят.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
А разве полиморфизма уже не было?)
Было интересно, как всегда! Особенно интересно слушать будучи функциональщиком, кайфую от Фарша более пяти лет.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф, ваще огонь. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Давай пока
Я зашел, мне там кто-то понравился, я поставил лайк, поставил то се. Видосик посмотрел полностью, да никогда не поленюсь написать в комменте. Чувак красава! Охуенный видос, я сорок минут на нём залипал! Кип дуин вот ю дуин бро!
Самое время полностью обмазаться новым видео от Ехстрим Цоде😊
Функциональный подход - это как SOLID, некие правила/рекомендации/ограничения построения архитектуры приложения, которые в рамках определённых задач могут дать более чистый/короткий/лаконичный/%youradjectivehere% код.
И какие-то языки более способствуют такому стилю, хотя в принципе на любом языке, где есть функции высшего порядка, можно писать в функциональном стиле.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще?
Как по мне, то вся соль функциональных языков заключается в двух вещах:
1) все функции чистые, что решает проблему общего состояния с непредсказуемым значением, так как его можно изменить из каждого места кода
2) можно применять операторы над функциями. Это интересная и полезная вещь, если в ней разобраться
в результате для того, чтобы сделать "рандом" или ввод/вывод надо городить "трёхэтажные конструкции" из монад :-)
@@marvinnimnull9982 что Вы так к этим монадам прицепились? ) их функция совсем в другом же. Монады используются для выполнения операций над последовательностями. Для того, чтобы сделать обычный рандом, нужно вызвать обычную функцию рандом. Монады нужны тогда, когда Вы хотите, например, создать массив рандомов. Да, в этом случае нужна функция, которая сможет получить уже имеющееся состояние последовательности и добавить к ней одно значение. Ну или если Вам надо посчитать сумму элементов массива, то тут да, тут тоже монада нужна, потому что каждый раз она будет возвращать массив на 1 элемент короче, в котором последним элементом будем сумма двух последних элементов предыдущей монады, а всё остальное будет таким же, и остановится эта функция когда останется один элемент, являющийся полной суммой массива.
Вы сложности на пустом месте придумываете. :)
@@nikolaymatveychuk6145 вот именно, над последовательностями с общим состоянием (ключевое), со списками и так можно работать (каждый раз создавая новый cons/car/cdr + рекурсия), нюанс функции рандом в том, что она не может быть чистой и выдавать случайные числа не изменяя собственное состояние (если только это не опрос аппаратуры). А насчёт монад - в своё время была книга Тимоти Бада "Мультипарадигменное програмирование в LEDA" там он вводил тип relation - вот это была монада в чистом виде :-) и делал он это ещё до того, как хаскель создали (и уж тем более, как он стал популярным). А сложности? ну, я за мультипарадигменные системы :-) язык должен от задачи идти.
@@marvinnimnull9982 ещё раз хочу уточнить что Вы подразумеваете под "не меняя собственное состояние"? У Вас с моей точки зрения странное представление о смене состояния. То есть Вы хотите сказать, что если я буду случайным образом запускать или не запускать функцию random в цикле и потом вызывать Вашу функцию, то Вы в ней гарантированно сможете определять, вызывал ли я рандом на этой итерации цикла или нет? КАК? :)
@@nikolaymatveychuk6145 а как можно случайно запускать или не запускать рандом без самого рандома? теперь уже я не понимаю. Под состоянием имеется в виду простая вещь - каждый запуск функции от неизменных аргументов должен выдавать неизменный результат. Тогда функция чистая и состояние среды вычисления не меняется (между запусками). 1+2 вернёт 3 всегда, неважно как часто и в каком порядке вы будете это делать. read/write всегда будет менять среду (как минимум выдавая/принимая символы с устройства), т.е. у этих функций есть побочный эффект.
отличие такое-же как между set и let, первая изменяет имеющийся символ, а вторая вводит новый, который уже не может изменяться.
Классное объяснение. Побольше бы такого. На твоих видео я начал учится программировать, вот прямо цепляет и хочется узнавать что-то новое в этой среде. Жду новых видео. Спасибо 👍
Пиздец чел
Соболезную
@Недотысячник тогда как вы объясните то, что я стал сеньор программистом за ДВЕЕЕЕЕЕ МИНУУУУУУУТЫ?
@@HuKuTa944 Ну, наверное, подставил очко менеджеру. А менеджер скорострел, вот как раз и управился за двееее минуууууты :-D.
Наверное единственный способ стать синьёром столь быстро.
@@daddy-nik8551 вахаххх
"Принеси мне сендвич" это такой же императивный стиль. В декларативном стиле будет "Это сэндвич на столе, который принес официант который приготовил повар. Где сэндвич это хлеб + сыр + ветчина + помидор + хлеб"
Есть только 2 тру парадигмы программирования:
Байтоебство и нервотрёпка
уууууууууууууу, декларативность, императивность, чё так сложно-то, я вот просто сижу и прогаю, какие-то там классы создаю и тп
а вообще лайк тебе, чувак, подача по кайфу, всё понятно 👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍👍
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще? 👍
Братан, хорош!)) Давай, давай - вперёд!) Контент в кайф, вообще красавчик, давай ещё!!!)
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Давай пока
- БРАТАН ХОРОШ ДАВАЙ ДАВАЙ ВПЕРЕД МОЖНО ЕЩЕ ВООБЩЕ КРАСАВЧИК. Можно вот этого вот почаще?
- Да можно!
Континент пушка. Ваще агонь. Как святой воды с бодуна попил и здоровым трушным дивелопером стал. Спасибо, пили ещё годноту!
#CSSТожеЯзыкПрограммирования ☝️
Даже арифметика есть и сравнения
Братан, харош, давай давай вперёд! Контент в кайф, можно ещё? Ваще красавчик!
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще!
Данное сообщение (материал) создано и (или) распространено иностранным средством массовой информации, выполняющим функции иностранного агента, и (или) российским юридическим лицом, выполняющим функции иностранного агента
Давай пока
🤣🤣🤣🤣. С нижней надписи проржал
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Нифига конечно в конце дядюшка Артем трансформировалься в Колю, нормальный переход)))
а так круто что объяснили вот эту вот непонятку с декларативностью, хоть что то стало понятно про функциональщину, спасиба, однозначно, братан хорош вообще крассавчик, ставлю лукас :)
Братан, Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
return Братан хорош!!! Давай, давай вперёд!!! Контент в кайф, ваще огонь. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Давай пока
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.🤟🤘
По запросу трудящихся:
БРАТАН ХОРОШ!! ДАВАЙ ДАВАЙ, ВПЕРЁД! КОНТЕНТ В КАЕФ! МОЖНО ЕЩЁ?! ВООБЩЕ КРАСАВЧИК! Можно этого почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
#CSSтожеЯзыкПрограммирования
Хорошо братан!!! Вперёд, давай, давай!!! Кайф Контент. Еще можно?Красавчик вообще! Можно вот этого вот почаще! Музлон зачет!
Да, давайте почаще, ща учусь не хватает вот этой мотивационно-информационной атаки с вашего канала
Музычка 12/10 и сам видос отличный!
А что тогда с ООП, ведь в недрах методов тоже будет императивщина. Мне кажется обзывать псевдофункциональным или псевдоООП любой ЯП будет не справедливо, просто за то, что в нем есть выход в реальный хаотичный мир.
Что ты блядь несешь? императивный подход это когда ты вызываешь что то. Приказываешь им. ООП о это разделении на модули декларотивности.
А чем тебе ООП не бьется с императивностью? Ты не туда воюешь, чел, ООП-языки по типу шарпа вообще ни разу от императивности не открещиваются
@@kitu-brazilieru В любом языке вообще можно писать мультипарадигменно, кроме может быть совсем обфусцированных. ЯП лишь помогают следовать какой либо из парадигм, вопрос лишь в том, будешь ли ты им следовать.
Любую императивщину можно архитектурно отделить от бизнес логики, в которой у нас и появляются гарантии и возможности писать чистый код.
При таковых допущениях, разве есть смысл называть любой ЯП псевдопарадигменным?
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще. + 1
Братан, хорош давай давай вперед контент в кайф можно еще ваще красавчик!
бро контент в кайф!!! давай ещё!!!
Круто, спасибо) всегда эт в голове вертелось и думала, что мб я че то в этом жизни не понимаю просто, так сказать не познала дзен декларативщиков. Но в итоге такие мысли не у меня одной, и это прям успокаивает☺️
Забавно, что мысли, которые всегда вертелись, выразил блоггер немного погуглив. Думаю, эту мысль надо повертеть.
#CssТожеЯзыкПрограммирования
Да, как всегда - спасибо за творчество, ждём ещё, удачи. В это раз кратность переваренности кала стала явно больше в итоговом продукте.
Брат, молодец! Продолжай в том же духе! Содержание видео мне нравится. Можно больше сего действа? Действительно красиво получилось! Можно повторять с большей регулярностью.
Ачо всмысле, какое-то там императивное, декларативное программирование - я всегда думал, что функциональное программирование просто помагает не загаживать код миллионом имплементаций какой-то функции, если каждая имплементация нужна только один раз
Реализовал на css правило 34
Это как?
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще. Давайте, пока.
Давай разберём по частям тобою скзаанное. В общем ты типа прав во всем, да есть костыли в виде императива, иначе просто никак, железо в итоге работает по императивным принципам, а декларативный стиль это надстройка, но почему она от этого не может быть крайне удобной? А? А??
@Илья Прусаков чё ты душишь-то его сразу так? Ну нравится ему декларативщиной обмазываться - пусть обмазывается!
Тру функциональное программирование - это визуальное программирование, как в каком-нибудь анреале.
Не сказал бы что это прямо удобно.
@@Dadadadam999 Ни вообще ни разу. Я как-то ради прикола придумывал визуальный способ представления функционального кода, так вот он на блупринтовый визуальный язык не похож совершенно потому что в ФП функция - это объект первого уровня, то есть функция принимает другие функции в качестве аргументов и возвращает функцию как результат своей работы. Таким образом код ФП нельзя описать как блоки со связями между ними. Он будет выглядеть как матрешка где функции вставляются в в другие функции и в результате всего получается третья функция.
@Илья Прусаков суть не в этом. разница в том, как достигается конечный результат: описанием результата, который необходимо получить, или описанием как его получить. Например разные функции фильтров массивов являются декларативными, потому что вызывая их, в аргументы передаётся не алгоритм отсеивания лишних элементов, а правило, которому должны соответствовать оставшиеся/отсеянные элементы.
Само происхождение слов говорит о том, что один метод описательный, а второй повелительный. И все эти примеры "принеси мне мяска" это выдумка тех, кто не понял в чём прикол. На самом деле в примере с официантом декларативный метод был бы "мне нужно мясо", в то время как императивный высокого уровня звучал бы как раз "принеси мне мясо". Или если подняться на уровень выше,чтобы была понятнее разница, то декларативно мы бы сказали "проголодавшись я буду нуждаться в мясе", а императивно "если я голоден, принеси мне мясо". Ну или как-то приблизительно так... надеюсь основная идея понятна.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще)))
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще!
P.S. спасибо тому, у кого все скопировали этот текст.
Полный подрыв пацанов .... Автору респект! )
БРАТАН ХАРОШ ДАВАЙ ДАВАЙ ВПЕРЕД КОНТЕНТ В КАЙФ МОЖНО ЕЩЕ ВООБЩЕ КРАСАВЧИК
можно вот этого вот почаще? давайте, пока
Я считаю что автор - гений. Ходит в кафе без меню.
Эхтримцоде: хтмл-верстальщики пишут код на css...
Тем временем я: Тильда, грузи мои бесплатные шаблоны!
Вот она - декларативность! 😂
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф, ваще огонь. Можно ещё? Вообще красавчик! Можно вот этого вот почаще?
На самом деле, нет ничего плохого, если юзать мультипарадигменные языки, совмещая императивный и декларативный стили там, где это удобнее и понятнее. Например, в каком-нибудь Котлине, если нужно найти в коллекции объектов какие-то объекты по определённым условиям, гораздо удобнее вызвать на коллекции функцию-расширение find, передав ей лямбда-выражение, по которому будет производиться отбор. Как итог, вместо этажей из for-ов и if-ов, элегантное решение в одну строку, причём гораздо более удобочитаемое. Хуже, когда, имея возможность использовать разные подходы, человек тупо упирается во что-то одно и, как сектант, юзает это везде (только ООП или только функциональщина). Примерно так же, как и с языками программирования.
Это ты своими ебучими лямбдами не шерстил нормальный объём данных, с серьёзным условием. Они по итогу вообще перестают быть читабельными после четвёртой точки, когда ты собираешь вновь отфильтрованные данные. Ибо человеческому мозгу уже сложно удержать всю ту херову гору операций которые произошли изначальной коллекцией. Добавь сюда ещё специй из «нейминга» разных промежуточных значений типо i, map, list и т.д В итоге элегантное выражение в три точки превращается в нечитаемый отрывок, назначение которого забудут через полгода, а следующему копателю говна мамонта придётся это разбирать значительно дольше чем старые добрые, но уже «не красивые» вермишели if/else
@@ProGuitarUA если "шерстить нормальный объём данных, с серьёзным условием" при помощи for/if/else, то кода станет гораздо больше и читать его будет сложнее. Про "специи нейминга разных промежуточных значений" вообще не понял к чему это здесь; если у тебя одна коллекция вложена в другую, внутри лямбды ты можешь так же на вложенной коллекции вызвать функцию-расширение find или filter (или любую другую подходящую под ситуацию, ибо в том же Котлине их дохуя на все случаи жизни). С точки зрения читабельности в коде всё понятно что и откуда вызывается, поскольку для читающего код скрыты все сложные реализации коллекций и фильтров, а видна только сама бизнес-логика. А вот если это делать в имеративном стиле, получится хуева гора условий и циклов, "i", "j", write-only код, где как раз таки хуй разберёшься через пол года.
Братан - хорош! Давай-давай вперёд! Контент в кайф. Можно ещё? Ваще красавчик.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.💪💪
Логика видео: *_Я - человек, состою из атомов и палка состоит из атомов, значит палочка и человек это одно и тоже, выходит надо уравнять права человека и палки._*
А разве тру-мэйжор-программиты на всех эти свистопердельных фреймворк обмазанных языках лучше палки?
@@werwolfwaffen3657 Ой, а ты прям гига chad разработчик - пишешь интернет-магазин на assembler?
Специалист подобен флюсу, а программист - палке.
@@awwarez я пишу на самом пиздатом яп.
@@werwolfwaffen3657 Elixir?
Насколько я понимаю, в функциональных языках декларативность - это всего лишь побочный эффект фокуса на композиции. Идея не в том, чтобы писать "декларативно", а в том, чтобы писать максимально переиспользуемые компоненты. При этом оказывается, что, когда композируемость стоит во главе, код сам становится декларативным. При этом современное ООП точно также одобряет композицию, и у тебя точно также получается хороший декларативный код.
P.S. на самом деле я fan-boy функционального программирования, но у меня такое ощущение, что некоторые не замечают насколько у ФП и ООП много общего, фокусируясь исключительно на различиях.
Очередной набор общих фраз ни о чем)
Императивная парадигма: монолитный набор команд.
Процедурная парадигма: набор команд, направленных на выполнение определенной задачи, объединяется в именованные блоки кода.
ООП: программные сущности конструируются по образу объектов реального мира, данные объединяются в блоки с методами (функциями), изменяющими эти данные.
Функциональная парадигма: ну... эээ... декларативность, ну, или, эээ... композиционность, ну, или, эээ... буковки и цыфэрки, потому что когда буковки и цыфэрки во главе угла код переиспользуемый и декларативный, в ООП буковки и цыфэрки тоже есть.
Убедительно.
А на различиях концентрируются, чтобы отличать одно от другого, если бы концентрировались только на общем, то ФП бы не существовало.
@@ergo_____3491 Видимо мы с тобой совершенно по-разному мыслим, потому что твой коммент я тоже абсолютно не понял.
А по поводу различий я с тобой не согласен, из статей которые я читал видно только одно: евангелисты ФП, как автор канала и сказал, хвастаются тем как у них все офигительно и как ФП - это "совершенно другой мир", и нужно "забыть всё, что ты знал про программирование до этого", когда это совершенно не так и фундамент у обоих подходов один.
"Если бы концентрировались только на общем, то ФП бы не существовало" - тоже не ясно откуда такие выводы взялись, как концентрация на различиях привела к появлению ФП? Alonzo Church же параллельно с Turing'ом этот вопрос изучал, они даже не знали, что одно и то же изучают..
@@ergo_____3491 вы смешали в кучу "парадигмы в большом" (вычислительные модели) и "парадигмы в малом" подходы к организации программного кода. Хотя, если это был сарказм, то он не следует из ответа того, кому вы оппонируете.
Сейчас и в ООП-языках, в той же джаве - полно разных функциональных штук - редьюсы, фильтры и иже с ними. Уж для перекладывания массива в мапу никто нормальный в 2022 не будет циклы использовать).
@@pavelchurlyaev257 редьюсы, фильтры это все же капля в море в сравнении с Хаскеллем
Спасибо, Братан, что такую тему поднял!
Почитав Википедию, я так понимаю, что преимуществом Функционального ЯП является то, что выполнение его кода может быть в некоторой степени оптимизировано, ценой большей траты времени программиста.
Ибо писать чистые функции сложнее, чем дергать глобальные переменные внутри любого метода)
Я прав?
Как раз наоборот, функциональные языки во многих местах медленнее как раз из-за того, что они дают куеву тучу абстракций, которые помогают писать код намного быстрее. Например, тот же Сlojure, быстрее чем на нем писать практически невозможно.
На самом деле прикол функциональщины в архитектуре, ее нет) В смысле буквально нет, если у тебя нет ничего кроме функций, то и городить сраные clean architecture и прочие VIPER не из чего, а это приводит к единственному решение - реши блядскую задачу, возьми данные А из источника Б, и перебери их в данные В, потом засунь в источник Г.
@@aether-quinque спасибо за подробный ответ! Можете показать характерный пример на таком языке?
@@aether-quinque источник Г - это прекрасно )))) И насколько точно описывает решенную задачу )))
Смотря какой код и какая оптимизация.
1. Функциональный код достаточно просто распараллелить без лишних усилий практически в любом месте, потому что все функции чистые и один поток физически неспособен обосрать малину другому.
2. Функциональность абстрагируется над такими вещами как память, поэтому байтошаманством заниматься не получится, и перегонка туда-сюда больших кусков данных может сожрать очень много рантайма.
P.S. выполнение любого кода может быть оптимизировано ценой траты времени программиста. Это и есть смысл оптимизации - трахаться дополнительное время с кодом, чтобы он потом эффективнее выполнялся.
наоборот. программист куда меньше тратит времени на ФП код - потому что там нету кучи неявных зависимостей между мутирующими стейтами. суть в том что чтобы к этому прийти нужно изучить ФП и заложить в голову навыки написания такого кода.
вы наверное пишете ООП код..? вот смотрите. вы же моежете всю программу одной портянкой в одну функцию написать. верно? это проще чем создавать объекты и выделять код в методы? с одной стороны да, как вы говорите - нужно думать куда что положить и в целом конструкций становится больше. с другой стороны поддерживать второй вариант куда проще, то же самое с ФП
Да, редко на просторах ютуба встретишь более хайпово-бэйтный бред, чем у автора этого видоса. Он там ответить на вопрос просил ещё в конце. Ну что же, тогда по пунктам:
1. Видео начинается с кучи тезисов с отрицательными коннотациями в адрес неких абстрактных функциональщиков в вакууме, которые автор даже не пытается доказать. Просто поток сознания: "хитрые и беспринципные байтеры", "нагло всех обманывают", "коварно и лживо завлекают людей перейти в свою веру"
2. Продолжает автор неизвестно откуда взятыми якобы высказываниями неких абстрактных функциональщиков в вакууме: "у нас всё декларативно", "мы флексим".
3. Дальше идёт одна довольно трезвая мысль, но тоже не без недостатка: "декларативность - это абстракция поверх императивности", при этом абстракция у автора, почему-то в кавычках, хотя они тут и не нужны. Декларативность - это действительно абстракция поверх императивности, но ценность у ней от этого не исчезает. Автор врядли программирует в машинных кодах, а всё что выше, включая ассемблер - уже абстракция поверх языка, который понимает машина. Да и сами машинные коды - абстракция поверх физических процессов, происходящих в компьютере.
4. Затем идёт ещё один малопонятный тезис про некоего функциональщика, который начал автору рассказывать про SQL после того, как автор "продавил ему петрушку". Интересно бы узнать уровень навыков знаний этого самого функциональщика.
5. Далее идёт тезис про мёртвость пролога. Видимо автору не приходилось сталкиваться с решением проблемы авторизации в сложных распределённых системах, иначе он бы был в курсе существования rego - современного языка описания политик доступа, который является диалектом datalog/prolog
6. Следом, на примере того же пролога, автор оскорбляет всех учёных, занимающихся академическим программированием, сказав что порлоги придуман задротами для задротов. То есть учёные - задроты, к тому же ненормальные, так как, опять же со слов автора, нормальным людям туда (в пролог) вход строго запрещён.
7. Ну и в финале автор требует ответа на вопрос, который он сам сформулировал на основе того, что некие абстрактные функциональщики в вакууме , реализуя функции императивно, называют это декларативностью. При этом ещё что-то невнятное про лицо приплёл.
Это всё к тому, что у автора 0-5% полезного познавательного контента в видео и где-то 95-100% безграмотного высера ни на чём не основанного.
Теперь же про ФП: основное отличие от той же процедурной парадигмы вовсе не в декларативности, а в том, что функции в ФП могут быть аргументами других функций и результатами работы других функций. Если же говорить про "чистое" ФП, то там ещё вводится понятие чистой (ссылочно прозрачной) функции, и это подмножество ФП, хотя и менее удобно на практике, имеет под собой строгое математическое основание в виде лямбда исчисления.
Надеюсь, после этого короткого экскурса, автора стало яснее, чем же ФП отличается от других парадигм.
Так же очень надеюсь, что автор примет критику к сведению, и будущие видео окажутся более информативными и менее хайпожорными.
Долго мотал коменты, и был в шоке - неужто тут нет ни одного адекватного человека? Слава Богу хоть один нашелся! Спасибо вам за здравые мысли с которыми полностью согласен! Жаль остальных адептов этого блогера. Их уровень нагляден - большинство постов тут начинается с почти гопницкого - "Братан, хорош!/красавчик/молодец/..." и жаль, что с таким "гуру" им не суждено подняться выше, лишь совсем им мозги засрет.
По теме лишь добавлю, что поскольку ФП в идеале оперирует неизменяемыми данными, то оно очень хорошо распараллеливается, снимается проблема организации общего доступа к данным, race condition, блокировки... Более того, это распараллеливание может автоматом делать компилятор, благо ФП это фактически чистая математика (чистые математические функции) и в computer science тут все очень хорошо исследовано, доказана куча теорем... и все это компилятор может использовать для вывода наиболее эффективного и распараллеленого вычислительного потока (вернее потоков).
Как известно, тактовая частота процессоров почти уперлась в свой физический предел и дальнейшее повышение производительности уже давно идет за счет увеличения числа ядер. И это одна из важных причин почему ФП сейчас становится все популярнее. Функциональные фишки по моему наблюдению это то как сейчас эволюционируют языки - их добавление основной тренд эволюции старых языком и обязательный стиль для новых.
Честно говоря, даже не верится что автор ролика настолько тупой. Возможно он специально делает такие провокационные ролики, чтобы собрать реакцию от аудитории, раскрутиться и как конечная цель - получить побольше гешефта. Это первый и последний ролик, что у него посмотрел.
Боже. ФункциАНАЛщики не декларативностью флексят, а монадками с эндофунктороми😎. У вас у императивщиков только пародии на них типо Optional в джаве🤭
Просто дополнительная абстракция, не более
@@nikolay7658 доооо. Это же не так, что монады позволяют ясно с эффектами манипулировать и комбинировать, без всяких костылей в виде эксэпшэнов и налов🤢
@@aslack5422 все костыли под этой абстракцией как бэ, к тому же, все абстракции рано или поздно протекают
@@nikolay7658 ну тогда вперёд в жизнь без абстракций. В структурное программирование! А те дураки кто хочет не страдать от налов, эксэпшэнов пусть дальше свои монады используют
@@aslack5422 все языки программирования - абстракция. Я не писал о том, что их не нужно использовать. Я о культе ФП, монад и дальше по списку
Интерфейсы JPA - вафлеративнось в Java
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф, ваще огонь. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Давай пока
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Давай пока
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф, ваще огонь. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф, ваще огонь. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Давай пока
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан харош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Давай пока
Ливни отсюда
@@онет-ю4с Братан плох!!! Давай, давай назад!!! Контент в грусть. Можно ненадо? Вообще дурак! Можно вот этого вот пореже.
Плюсую братка, контент топчик, даёшь ещё!!
ок
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Давай пока
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай, давай вперёд!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще