Отрисовку в OpenGL делает видеокарта исходя из массивов мешей, параметров и текстур, которые хранятся в памяти видеокарты. Растеризация описывается вообще отдельно, программой на glsl. При чём тут вообще функции объекта???

Ага, усвоение информации через пересказ и спор. Прямо как я. Блин, ну я тогда не буду вываливать свои соображения, потому что получится срач не по теме, а мое мнение на форуме уже все примерно знают.

Как вы предлагаете например кнопку в GUI делать? Код в студию.

Тут даже спора нет. Автор просто отрицает не предлагая ничего взамен. Делая это из браузера написанного в соответствии с ООП.

Давайте уже на примерах, раз уж до этого дошло…

Это от вас ждём примеров как делать без ООП.

Тупого включил?

https://github.com/ocornut/imgui

ImGui::Text(«Hello, world %d», 123); if (ImGui::Button(«Save»)) MySaveFunction(); ImGui::InputText(«string», buf, IM_ARRAYSIZE(buf)); ImGui::SliderFloat(«float», &f, 0.0f, 1.0f);

Делая это из браузера написанного в соответствии с ООП

Он делает это из браузера, написанного в соответствии с желанием размножаться.

Нет, это значит что надо просто понять почему люди тогда использовали данные подходы. Уважать их иди нет - личное дело каждого, как и следовать этим устаревшим стандартам или нет. Вместо закидывать говен лучше пытаться сделать альтернативу тому что не нравится.

Shaman007 alpha Pinkbyte maxcom

У вас время поломалось?

https://ibb.co/ySvNLhh

Нет, это значит что надо просто понять почему люди тогда использовали данные подходы

Во-о-от, потому я последние года полтора здесь именно этим и занимаюсь.

Вместо закидывать говен лучше пытаться сделать альтернативу тому что не нравится

И этим я тоже занимаюсь, очень скоро релизну прототип, а то уже люди заждались.

Каждый кадр заново все контролы создавать? Чтобы была постоянная нагрузка на процессор даже если ничего не происходит и впустую тратить заряд батареи? Спасибо, не надо.

Нет, это ты просто не научился пользоваться сайтом.

Удалят - и ладно.

Удалять техсрач с ЛОРа - это святотатство! Не так уж и часто тут бывает техсрач.

Это настоящая религия.

А что? Вы не знали, что программирование - это такое набор религиозный движений?

Создана парадигма, которая не работает из-за противоречия в самой своей сути.

Да, я тоже не в восторге, когда делают ООП ради ООП и решают возникшие из-за этого ООП проблемы, да и вообще дрочат на ООП архитектуру (которая в итоге всё равно сосёт), вместо того, чтобы решать, собственно, саму задачу. Но тут проблема даже не в ООП, а том, что ты декларируешь какую-то там модель, а на деле и в перспективе всё оказывается далеко не так, как проектировали. Потом идут в ход всякие костыли, подборки, приседания и бредовые абстракции. Умножь это все на тупорылый карго-культ и получить типичный ооп проект, где одну миркосущность будут добавлять 2 месяца, а потом год тестить. Но тут дело не сколько в самом ООП, оно просто проявляет другую, общую для программирования в целом проблему.
Глядя с другой стороны, если начать упарываться по функциональщие, получится всё равно упорото. То есть проблема в упарывании и типичных для кодерков попытках вообще всё делать исключительно одной отвёрткой, а не в парадигме.

Удачи в этом деле. Будет интересно глянуть.

Удалять техсрач с ЛОРа - это святотатство! Не так уж и часто тут бывает техсрач

Техсрач? Где? Дай ссылку, я хочу поучаствовать.

Вон в расте недоношенный ООП и сколько боли из-за этого при написании ГУЙ библиотек. При том, что динамическая диспечеризация и vtables присутствуют - кажется еще чуть-чуть и родится class

Я аноним а значит сверхчеловек. Мне можно и не учиться (хочется роскомнадзорнутся от того что так тупанул)

Эммм. Прямо тут. Нет?

Где технические аргументы? В чём вред ООП? Автор не раскрыл тему.

Ядро Линукса хоть и на расово верной сишечке, но там ООП во все поля, классы драйверов и их наследование, виртуальные методы и все дела.

Автор пока не определился. Ищет свой путь. Какой может быть вред от абстракции. А в чем тогда вред туплов? Или генериков? Давайте пообсуждаем

Вот когда абстракций мало это действительно плохо. Холодок по спине пробегает как вспомню тип table в lua, который там отдувается за все структурные типы, от массивов до классов

Где технические аргументы?

Ну ты раскатал губу. Да и вообще. Когда для срача нужны были аргументы? Один говори - «Говно!», остальные доказывают, что всё норм. В процессе иногда всплывает что-нибудь интересное.

Потом идут в ход всякие костыли, подборки, приседания и бредовые абстракции. Умножь это все на тупорылый карго-культ и получить типичный ооп проект, где одну миркосущность будут добавлять 2 месяца, а потом год тестить. Но тут дело не сколько в самом ООП, оно просто проявляет другую, общую для программирования в целом проблему

Ты знаешь, я тут сижу, думаю «да, и правда ведь, я даже сам могу раскрыть, как это происходит и почему» — а у самого тихонько пердак тлеет от мысли «и что дальше? Знаю, и что?». Это как знать имена всех покемонов — для общего развития... или чтобы распознавать новые названия Big Data проектов. Вот батя в детстве меня дрючил, чтобы я писал красиво — прошло эн лет, а я уже года два кроме подписи ничего не писал от руки. И какой был смысл? Правильный ответ — весело провести время. А вот теперь и думай, кто весело провел время, а кто провел его так, будто сидел срок в тюрьме.

Один говори - «Говно!», остальные доказывают, что всё норм. В процессе иногда всплывает что-нибудь интересное

Всплывает говно!

Тот же JS который самый популярный язык умеет ООП

Только в ЖС ООП считается дурным тоном. Просто потому что какой-то чудак однажды написал брошюрку «Javascript. The Good Parts» и раскритиковал ООП

Теперь принести в js чатик код со словом class значит непременно вызвать бурю эмоция. Эти дурни создают объекты функциями. Например createEvent. При этом внутри объекта может быть жирнющая реализация, десятки методов, миксированные поля. А таких объектов может быть сотни тысяч. Достаточно переписать со словом class и добавить щипотку наследования, и такой объект в оперативке похудеет на порядки, благодаря прототипам

Если так судить, то паттерны «херак-херак и в продакшон», crutch driven developnent и production driven testing, вполне оправданы.

Да. Но ведь уже другого качества!

Если так судить, то паттерны «херак-херак и в продакшон», crutch driven developnent и production driven testing, вполне оправданы

Да. Знаешь почему? Потому что они успешно выполняют самую главную и наиболее тонкую технологическую задачу — оправдать полученные от инвесторов деньги. Неужели ты не понимаешь, что Сам Илон Маск слепил на скорую руку груду металолома из китая, налепил туда букву «Т», повесил китайский планшет в салоне — и это покупают, и под это несут деньги. Чем ты хуже? Это как производство микросхем в России — его никак не могут толком организовать, потому что на копеечных отечественных микросхемах не распилишь бюджет. Делать долго, дорого, и плохо выгодно всем: работнику, потому что у него есть работа; руководителю этих работников, потому что он попал в солидный проект, где сможет проявить себя и получить хороший имидж для построения будущей карьеры; инвестору, потому что стоимость проекта растет, а вместе с ней растет и капитализация (привет Тесле); и потребителю, потому что он знает, что приобретает продукт, который будут исправлять и дорабатывать еще не один год — а значит поддержку, обновления, новые модели можно будет получать еще много лет без страха «а что же будет завтра». Все счастливы и радуются жизни — один ты отравляешь воздух, мол «а как же китайцы, которые по 16 часов 7 дней в неделю вкалывают на заводах?». Ну не ты же вкалываешь!

В ядре применяется ООП, VFS как самое очевидное.

Где технические аргументы? В чём вред ООП? Автор не раскрыл тему.

Их и в статье нету)

Там описаны проблемы с которыми сталкиваются новички в программировании и решение которых описано в книгах того самого дяди Боба.

А в качестве альтернативы предлагается создать DataStore, объект, парам парам пам. Понимайте это как хотите, лол.

Такая статья подошла бы для первого апреля как шутка.

статью не читал. Но можно ли узнать, кто здесь идиот?

Индустрия с начала 90х очень даже ООП пользует во все щели, даже там, где не нужно.

Но можно ли узнать, кто здесь идиот?
Индустрия с начала 90х очень даже ООП пользует во все щели, даже там, где не нужно

Идиот здесь я, потому что индустрия с начала 90-х годов очень даже неплохо зарабатывает на ООП. А я — нет.

это как призывать заклеймить спирт

всё можно использовать с головой и к месту

С алкоголем всё намного понятнее. Его вред для организма человека многократно подтверждается в статистике и разных исследованиях. Пользы никакой.

антисептик же

Для наружного применения, не внутреннего.

ООП объект хочет быть самостоятельным, «знать» как себя отобразить

Не слышал про паттерн «делегат», а стоишь из себя умного.

ну так да, нужно правильно применять) не внутрь а снаружи)

По поводу объекта, который хочет быть самостоятельным … ТС, а тебя в институтах не учили, что объектом может быть не один и даже не два класса, в хорошо спроектированном коде это вообще может быть целый пакет? Я так понимаю, что нет! Думаю, что и абстрактному мышлению тоже не учили, так как путать данные в ОЗУ или на физическом уровне модели OSI с данными инкапсулированными в вышестоящих объектах - это как раз зло! Вот, за подобное меня с первой работы уволили, а сейчас за это уже я увольняю.

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

тут лучше паттерн Bridge подойдет

Все гораздо проще

Если посмотреть на определение OOP как его дал человек который придумал этот термин (Alan Kay), то становится очевидно, что современные проблемы OOP в том что языки реализуют хорошо если половину условий:

1. EverythingIsAnObject.
2. Objects communicate by sending and receiving messages (in terms of objects).
3. Objects have their own memory (in terms of objects).
4. Every object is an instance of a class (which must be an object).
5. The class holds the shared behavior for its instances (in the form of objects in a program list)
6. To eval a program list, control is passed to the first object and the remainder is treated as its message.

Таким образом современные языки OOP выполняя в лучшем случае пункты 1, 4 и 5 являются только попыткой быть OOP.

Я бы хотел привести пример, который провоцирует делать такие выводы: класс DataGridView из Windows.Forms.

Чем примечателен данный класс? Тем, что имеет такие особенности:

1. Очень много свойств и методов. Из них многие помечены «Является устаревшей» и «не применим к этому классу». Ну первое ещё простительно, а второе связано с непродуманным наследованием конкретных классов.
2. В классе есть как свойства, так и сеттеры с геттерами. При этом свойства могут быть только для чтения, или только для записи.
3. Как следствие пункта 2, становится не очевидно, через какое свойство или метод провести определённую операцию. Например, если я хочу поменять значение в какой-то ячейке таблицы, то окажется, что среди множества методов и свойств этого класса нет ни одного, который позволяет это сделать. Надо хитрым образом получить агрегированный объект, который отвечает за эту операцию.

Можно сказать, что виновато не ООП, а «индус», реализующий конкретный класс. Но ведь большинство людей как раз и является такими «индусами». Соответственно, в большой системе с ООП всегда будут такие монстры.

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

Много лет изучаю и использую ООП. Это удобно, и нужно. Не нравится - не используй. А вот писать эдакие разоблачения, больше похожие на чисто субъективные предпочтения, - так это выглядит как «мне не зашло, и вы не используйте, не хочу, не хочу, не хочу!!!».

Bridge про разделение интефейса и реализации. Чем он тут лучше?

Ахахаха, ну молодец. Вообще вы*боны в коде, применение любых подъемов с переворотом ни к чему хорошему не приведут.

я имел ввиду про отображение объекта будь-то на экран,в pdf или сериализация в какой-нить проприетарный DTO

Библиотеку Qt раздувает не ООП, а то, сколько библиотек используется под капотом.