🎄T
Я считаю, что излишняя абстракция идёт в разрез с реальной задачей
/
Size: a a a
2020 September 20
🎄T
Твоё железо не думает объектами, ты работаешь с конкретными пакованными данными, эта несостыковка приводит к реальным проблемам
🎄T
Например когда при обновлении объектов раз в n миллисекунд ты теряешь иногда до 150% времени на миссах кэша процессора
🎄T
Который не был создан для объектной модели
Y
Т.е. ты хочешь отказаться от структуризации и чтобы код был хаотичным,где хрен разберёшься?
🎄T
Интел регулярно пытались достучаться до разработчиков и объясняли как правильно структурировать свой код, чтоб это не был трэш
🎄T
Т.е. ты хочешь отказаться от структуризации и чтобы код был хаотичным,где хрен разберёшься?
Нет, ты путаешь
🎄T
ООП не синоним структуризации
🎄T
Можно структурировать все прекрасно в чисто императивном стиле на си
🎄T
Без каких либо объектов, просто правильно давать команды своему железу
🎄T
И понимать что ты хочешь от него, а не вбрасывать абстрактные концепты, которые по идее за тебя должна решить виртуальная машина или компилятор
🎄T
Это не правильный подход
Y
Можно структурировать все прекрасно в чисто императивном стиле на си
Например?
🎄T
Ты должен использовать свой компилятор как инструмент для эффективной генерации команд, а не как чёрный ящик в который ты вбрасываешь своё абстрактное решение
🎄T
Если посмотреть внимательно, то большую часть времени ребята, работающие с ооп, пытаются максимально абстрагироваться от железа, а не наоборот дать правильную команду
🎄T
Например?
Что например? Я привёл пример последствий с кэш миссами
Y
Если посмотреть внимательно, то большую часть времени ребята, работающие с ооп, пытаются максимально абстрагироваться от железа, а не наоборот дать правильную команду
данная претензия логична с C++,где там надо работать с памятью
Б[
Сейчас понимание кода > производительности железа
Б[
В узких местах да, имеет смысл пожертвовать ооп в пользу первоманса
Y
Вот скажи,это по-твоему плохо и так нельзя писать?