Гайд - как стать спикером на JUGе 1) Берем этот доклад 2) Заменяем слово "объекты" на "рекурсивые функции" 3) В ответ на вопросы пикаем одну из фраз ниже после "Я с вами согласен. Но" - "Объекты не нужны. Стек рекурсивных функций тоже имеет состояние" - "Стандартную библиотеку делали идиоты - зачем делать целый класс Scanner, когда можно было просто написать статик рекурсивную функцию" - "StackOverflowException? Понятный код важнее! Непонятный? А я мыслю по другому!"

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

Ну этож Бугаенко :) У него всегда темы для срача, мне нравится Бугаенко. Если становится скучно на работе я иду в бложик Егора и нахожу срач по душе :)

На самом деле, вещи говорит. Это сложно, по сравнению с привычным мышлением, но очень логично.

Трудно, конечно осознать всю программу, особенно если он будет большая

Аж ностальгия накрыла при виде листинга Basic.

А мне нравится, интуитивно близко

А почему в Лиспе нет инкапсуляции? Через замыкание легонько реализуется. Или тут категорический подход, что инкапсуляция - она только в ООП, потому что кто-то сказал что должно быть именно так? А ООП может называться ООП только если оно "классическое"? Причем не в смысле каноничности, а потому что реализовано через классы - и снова потому что кто-то сказал, что должно быть именно так? Если у нас есть объект - в смысле контейнера состояния, и какая-то логика для данных таких контейнеров, то мы и на чистом С можем написать drive(car) - и будет так же понятно, как если на "классическом ООП" написать car.drive(). И это будет ООП на чистом С. Некоторые задачи лучше - то есть проще - решать в императивном стиле. Некоторые - в декларативном. Собственно, с этой целью и создают новые языки программирования - чтобы облегчить использование какого-то стиля или парадигмы; тех, что больше подходят под определенный класс задач, для которых и создавался язык. Остальные парадигмы просто остаются в тени выбранных для языка архитектурных решений - но не запрещены. Обилие паратигм программирования дает отличную вариативность - и можно взять именно то, что лучше подходит под задачу, пускай в каком-то случае это и просто пачка процедур.С другой стороны, любая идея, возведенная в абсолют, выхолащивается в бессмыслицу. Это все равно, как "а давайте молотком забивать только гвозди, и только одной стороной - потому что так в учебнике труда сказано". Хотя вариативность применения даже столь простого инструмента просто безгранична.

19:50 если хочется по солиду иметь маленькие объекты которые имеют только один метод, то зачем вообще нужны объекты. Можно убрать лишнее и реализовать всё функциями. Добавить туда функции высшего порядка.

Спасибо, Егор, теперь и 1С: Предприятие выходит объектоориентированный)

Джокер от мира Java разработки

А как по мне очень даже интуитивно.

2023 год. Scala. ZIO. Все так и пишут. Мужик опережал время

Очень понравилось выступление. Особенно аргументы всех сторон. Поддерживаю подход Егора, вижу в этом много смысла. И Android действительно трэш.

Интересная мысль

Егор просто приколоться решил над местной аудиторией. А они ему и противопоставить толком ничего не могут. Это лишь показывает некомпетентность слушателей

завидую прям коллегам, которые удостоились чести работать с таким классным инженером. И на самом деле, спринг не нужОн нам. Главное Евгению Борисову об этом не рассказывать )

Напомнило иерархию виджетов во Flutter

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

А потом GC тормозит приложение на сутки чтобы очистить эти все объекты 😀

Опоздал с комментарием на три года, но... Лесенка в ООП - это пережиток порграммирования текстом, объекты надо композировать в пространстве, возможно даже в трёхмерном (а то и больше, но зачем?). Тогда и программа будет не текстовая, а объектная. Видео оставляет некоторые вопросы, тема раскрыта недостаточно. Замечательно, всё скомпозировалось. Теперь, как внутри всего этого великолепия описываются условные конструкции, циклы и рекурсия? Построением, по сути, аналога AST в явном виде, как в блок-схемах? Какие примитивы делают чистый ООП язык тьюринг-полным? Чистое ООП не предполагает параметрический полиморфизм (это заимствование из мира ФП) - что предлагается в статическом стротипизированном ООП-чистом языке на замену?

Все проблемы начинаются со слова "должен". Статиков не ДОЛЖНО быть, классы ДОЛЖНЫ быть маленькими, все ДОЛЖНО быть объектом и так далее.

23:38 Crystal lang!

В итоге lisp/clojure получается :-)

После этого ролика, становится понятно, почему Егора Бугаенко так тролят.

14:40 вопрос задал Тагир?)

Вся шутка в том что код на Бейсике короче и лучше читается.

все проблемы решены в котлины экстеншинами =)

у нас такой говнокод не прошел бы стадии ревью

Удачи с дебагом этой матрёшки

Боже храни питон!

Видео обрывается неожиданно. Все таки дошло до мордобоя?

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

Народ хочет процедурного программирования, он на нем и пишет. А ООП для них просто звучит солидно, вот они этот термин и используют

На самом деле когда видишь цель может даже и проще... Но вот тут-же вспомнился Magento который использует именно такой подход, это просто убойный удар по любому CPU... Заканчивается это обычно тем что есть дохрена классов и вместо 100 строчек кода тебе надо искать какой-то там класс...

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

Человек открыт к диалогу и это подкупает, но собеседников явно не хватает.

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

Функция принимающая на вход данные и возвращающая данные не изменяя состояние - плохо o_0 С каких это пор использование pure functions стало дурным тоном?)

почему вы говорите, что надеетесь, "... что появляться будут языки и платформы..." так уже есть декларативные языки Lisp, Prolog

автор решает задачу написать полностью на ООП а не написать понятный читаемый код. Не всегда эти 2 задачи совпадают.

Тут ничего нового нет. Фреймворки автоматизируют сборку "матрешки" посредством паттернов Dependency Injection, IoC или ServiceLocator. Это единственное отличие от того, что предлагает Егор. Для более сложных приложений, особенно клиентских, "матрешка" Егора превратится в месиво.

У погромистов подгорает! :) Я бы только программу оформил иначе: с промежуточными переменными, которые бы передавал для создания новых объектов и шел бы с конца (а то получилось в функциональном стиле). Тогда программа была бы плоской, но ООП.

Название переменных - топчик. Integer - final class. Тут парень его реализует как интерфейс. После фразы: "Сейчас я пишу на java" - это очень странное поведение.

что-то в этом есть

Не хотел бы я дебажить код этого товарища))

Согласен полностью с тем, что основное это человекопонятныйкод, но х3 будет ли с этой концепцией ясность и простота это вопрос

Хочется выкинуть эту объектную дрянь и оставить простой и понятный бейсик ) А если серьезно, то тут лукавство во всем: и код на объектах не короче (если добавить все классы, получится втрое длиннее), и поддерживать такое сложнее, чтобы понять что происходит, надо просмотреть все классы. Да и вообще выглядит как троллинг.

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

Самый странный доклад, который я видел...

А вот как код выглядит при наличии set-еров и get-еров: kzfaq.info/get/bejne/gdhdYMd4r6fZmWg.html

imho: из одной крайности в другую. Видимо автор довго кодил на C и в какой-то момент решил перевернуть все с ног на голову. p.s. вместо тысячи слов - "show me the code"

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

даже на it конференции должен быть городской сумасшедший

Старый доклад

И вот из-за таких фанатиков Скайп пол дня открывается

У Егора ООП головного мозга.

В жаве есть метки, практически гото.

ооп головного мозга (с)

Знаете что самое страшное? На этом видео 2/3 лайков...

абсурд

Прогер, обиженный на весь мир. Ему всё не нравится... Только посмотрите заголовки его видео "utility нас убивают", "обьектно-ориентированное враньё", "ORM - это обитно"... Противно слушать все его недовольства. Не нравится ЯП - не пиши.