LINUX.ORG.RU
ФорумTalks

О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

 


3

2

Здравия всем!

Я редко пишу на этом форуме, никого здесь не знаю… Но всё-таки решил попробовать. Удалят - и ладно.

Хочу лишь обратиться к молодому поколению программистов: в университете вам будут впаривать ООП - не ведитесь. Я много лет жизни потерял пытаясь понять что это за зверь. Это настоящая религия. Тебя убеждают что это хорошо, а когда ты понимаешь что это плохо - тебе говорят: ну ты просто ещё не знаешь паттернов, 5 принципов дяди Боба и т.д.

Много лет спустя, я поизучал эти паттерны, принципы и пришёл к выводу. Всё это демагогия. Это реально секта. Создана парадигма, которая не работает из-за противоречия в самой своей сути. И чтобы оправдать её существование была создана куча теорий, которые добавляют сложность в систему.

Есть много статей, разбирающих по косточкам различные аспекты ООП. Это тяжелое чтиво и мало кто из студентов сможет понять о чём речь. Тут сессии, курсовые, языки, вечеринки. Не до философии. Но всё сводится именно к философии:

информация ничего не значит без контекста.

В классическом примере ООП используется для пользовательского интерфейса. ООП объект хочет быть самостоятельным, «знать» как себя отобразить. Но это зависит от размера экрана, а если вывод в документ PDF, то предпочтительнее вектор, а не растр и так далее. Рано или поздно работа с ООП постоянно натыкается на конфликт: как передать контекст объекту.

Об этом много сказано, есть много примеров и разборов. Я уверен что студентам некогда читать длинные статьи где много буков. Они легко гуглятся и вот одна из наиболее кратких со ссылками на более подробные https://habr.com/ru/post/451982/

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

Перемещено xaizek из development

Ответ на: комментарий от monk

Да, сделаю в Development. На новости оно, по правилам, не тянет.

aist1 ★★★
()
Ответ на: комментарий от monk

Стало в 10 раз медленнее.

Ну ОК. Я кейс принимаю) По-хорошему, там надо смотреть, что было с оптимизациями. Но тут, как раз, компетенций у программистов 1С должно было хватать.

aist1 ★★★
()
Ответ на: комментарий от Psilocybe

Очень смешно

Можно заменить на HTTP, чтобы было модно и молодёжно. Но сетевые файловые системы в любом случае не годятся, если нужна скорость. Потому что в этом случае у тех, кто открыл файл, нет общей оперативной памяти.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от aist1

По-хорошему, там надо смотреть, что было с оптимизациями.

Данные DBF фактически лежат в оперативной памяти, а данные SQL в соседнем процессе. Плюс объекты, прочитанные из DBF (закэшированные) уже имеют явные ссылки на объекты по своим полям. В SQL надо при каждом доступе к объекту в поле проходить по индексу. Ну и всякие мелочи типа того, что для получения последнего значения в истории в DBF просто получаешь данные по порядку и берёшь первое, а в SQL надо делать дополнительный запрос на максимальные даты сгруппированные по ключам.

monk ★★★★★
()
Ответ на: комментарий от monk

Но сетевые файловые системы в любом случае не годятся, если нужна скорость.

Зависит от. Для сценария операционных БД точно не годятся, это будет лютый антипаттерн — тащить данные к коду, а не код к данным. Для сценария аналитических БД, где данные иммутабельны — без разницы. Они эффективно кэшируются на воркерах. Все так и делают: хранят данные в S3.

aist1 ★★★
()
Ответ на: комментарий от monk

... а данные SQL в соседнем процессе. Плюс объекты, прочитанные из DBF (закэшированные) уже имеют явные ссылки на объекты по своим полям.

Тыж говорил, что там все на запросы переписали? Тогда все в том же процессе будет. И закэшировано как надо. MSSQL не лаптем делался, это вполне годная БД. В отличие от Windows Server ))

В SQL надо при каждом доступе к объекту в поле проходить по индексу. Ну и всякие мелочи типа того, что для получения последнего значения в истории в DBF просто получаешь данные по порядку и берёшь первое, а в SQL надо делать дополнительный запрос на максимальные даты сгруппированные по ключам.

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

Я, кстати, тоже на эту фишку упираю, называя это всё «индексами» — дополнительными структурами для ускорения операций доступа. В Мемории, кстати, есть один прикольный режим, который много чего сильно упрощает. Там можно ходить к записям контейнеров по их номеру, как в массиве. В результате скроллинг/пейджинг на клиенте делается тривиально и без оверхеда даже для очень больших контейнеров.

aist1 ★★★
()
Ответ на: комментарий от aist1

И из-за чего DBF оказывался, в конечном итоге, быстрее.

Сейчас подумал. В SQL можно было сделать такую же скорость как в DBF, но пришлось бы весь алгоритм утрамбовать в хранимую процедуру.

monk ★★★★★
()
Ответ на: комментарий от aist1

Тогда все в том же процессе будет.

Результат обработки, как минимум, в другой процесс перебрасывать. А это не число, а таблица. Хотя объём на фоне минуты работы ничтожный (1000 строк на 20 колонок).

monk ★★★★★
()
Ответ на: комментарий от aist1

тащить данные к коду, а не код к данным.

Раньше только так и работали.

Psilocybe ★★★★
()
Ответ на: комментарий от aist1

Зависит от СУБД. SQLite клянется, что он быстрее. LMDB-подобные схемы тоже будут, как минимум, не медленнее (если не на mmap делать). Особенно, если AIO задействовать.

Любой СУБД нужно делать тоже, что и при файловом доступе, плюс некий довесок, оправдывающий её гордое именование СУБД. Так что про быстрее это заливай кому-нибудь другому.

Psilocybe ★★★★
()
Ответ на: комментарий от aist1

Для сценария аналитических БД, где данные иммутабельны — без разницы. Они эффективно кэшируются на воркерах.

На каждую операцию чтения сетевая файловая система должна опросить сервер на наличие изменений. Разве что весь раздел подключать в режиме только чтения.

monk ★★★★★
()
Ответ на: комментарий от monk

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

aist1 ★★★
()
Ответ на: комментарий от Psilocybe

У SQLite есть бенчмарк на эту тему. Так что «не всё так однозначно». Я думаю, что на большом IO они за счет WAL будут фундаментально медленнее, всё же. А вот на небольшом всё зависит от...

Что касается LMDB, то за вычетом mmap там будет кольцевой лог-структурированный буфер и append-only btree, и данные никогда не перезаписываются между транзакциями. И двойной записи там нет, так как там нет WAL или журнала. Такая схема будет плохо работать на HDD, из-за возникающей при мелкоблочной записи фрагментации линейных структур. Но на SSD она работает хорошо. Кэширование так же снимает часть проблем.

Если такую схему реализовать над io_uring/epoll и высокоскоростными NVMe SSD, то такая БД зарулит любую ФС с хорошим запасом в подавляющем большинстве сценариев.

В Мемории сейчас SWMRStore, который внутри тоже использует лог-структурированный кольцевой буфер, сделан над mmap (так мне сейчас проще), но будет и io_uring/epoll с блочными устройствами. Можно будет погонять бенчмарки и посмотреть.

Для io_uring/epoll нужно файберы делать. Они у меня есть, на основе Boost Fibers, просто не все приложения с ними смогут работать. Особенно, языки типа Python или Java.

aist1 ★★★
()
Ответ на: комментарий от Psilocybe

Дело в том, что для режима Single Writer Multiple Readers (SWMR), как в LMDB и SWMRStore, существует очень эффективный алгоритм атомарного сброса состояния RAM на внешнюю NVmem. Без какого-либо оверхеда и всего лишь с одной блокировкой (писателей упорядочивать). Так что теоретически можно иметь и атомарность/MVCC-транзакционность (гордое имя СУБД), и высокую скорость IO.

aist1 ★★★
()
Ответ на: комментарий от aist1

И закэшировано как надо. MSSQL не лаптем делался, это вполне годная БД.

С SQL есть ещё одна засада: надо ублажить оптимизатор.

Сейчас делал выгрузку из Oracle в 1С. Два запроса во временные таблицы и итоговый из временных таблиц. Полчаса на всё. Выяснилось, что на рабочем сервере права на создание временных таблиц не дают. Втыкаю эти же тексты вложенными запросами и вместо получаса отрабатывает не меньше пяти часов. В DBF хоть точно понятно, как именно алгоритм отрабатывает. В SQL сплошная «магия».

monk ★★★★★
()
Ответ на: комментарий от monk

В SQL сплошная «магия».

Explain analyze же + hints (если есть). Но, в целом, таки да. Там мало на что реально повлиять можно.

Почему я и считаю «монолитные» СУБД, которые не дают возможности строить свой, потимизированный под приложение, стек storage + typesystem + query engine морально устаревшими. Сейчас БД уже активно идут в этом направлении (кастомные стеки) в рамках микросервисного подхода. Но пока что у них еще всё слишком кустарно (на мой взгляд).

Что качается твоего кейса, то обход граблей Оракула делают использованием либо внешней ETL-тулзы, либо внешней ELT-тулзы. Последнее — это, например, тот же PG, внутри которого ты можешь трансформировать данные как тебе надо и потом выгрузить в Oracle.

aist1 ★★★
()
Ответ на: комментарий от monk

Насчет ETL/ELT, ты это всё можешь уже знать, но я в свое время нашел очень удобным CREATE TABLE AS STATEMENT. Там можно делать dataflow из таких операторов, и у меня на PG оно очень борзо работало как трансформатор. Я остался доволен.

aist1 ★★★
()
Ответ на: комментарий от aist1

обход граблей Оракула делают использованием либо внешней ETL-тулзы, либо внешней ELT-тулзы.

Вот я сам 1С (который по скорости кода медленней, чем Java) так и использую. Выгружаю данные через примитивные SELECT’ы без объединений, а потом делаю объединения через ассоциативные массивы на стороне 1С. Часто получается намного быстрее.

трансформировать данные как тебе надо и потом выгрузить в Oracle.

Мне выгрузить не надо. Мне надо получить данные с нужными отборами, соединениями и вычислениями. И SQL иногда тупит, если ему не в том порядке напишешь условия или не вытащишь подзапрос во временную таблицу.

monk ★★★★★
()

Вот ведь хрень, бессознательно пользовался «цель -> архитектура данных -> код» пока ЛОР не нашёл.

saufesma
()
Последнее исправление: saufesma (всего исправлений: 1)
Ответ на: комментарий от saufesma

Тебя на LOR-е ждет еще много дивных открытий)

aist1 ★★★
()
Ответ на: комментарий от crutch_master

Привет. Ты передумал делать тред?)

Это норм, если ты сейчас занят и некогда. Вопросы вечные и вечно будут обсуждаться.

aist1 ★★★
()
Ответ на: комментарий от aist1

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

saufesma
()
Ответ на: комментарий от saufesma

Я про использование ЛОР как рабочей площадки под проекты

Надо переделывать лор, чтобы можно было им пользоваться как площадкой под проекты, но тогда это будет уже не ЛОР. Максимум что тут можно сделать - это анонс.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Надо переделывать лор

Или просто создать новое отличное от ЛОР, у тебя есть идеи? Когда-то я был под впечатлением ЛОР и у меня сложилось видение такой рабочей площадки как коллективный разум, может это и бредятина. Но в моём проекте это как-то сработало.

saufesma
()
Ответ на: комментарий от saufesma

Или просто создать новое отличное от ЛОР, у тебя есть идеи?

Короче, надо чтобы любой контент (треды, юзеры, вики, код, etc) были отдельной единицей, раздавались p2p + были доступны на какой-то хттп морде. Доставка через клиенты, вебчик, мыло, dht (да хоть чёртову матерь) по подписке. Интеграция со всем и всё такое. Нужен тебе проект x? Подписываешься на его рассылку, а там тебе всё приходит в структурированном виде. Не нужно серверов, ничего модерировать (разрабы сами себе модераторы), ничего не просрётся (данных столько же, сколько юзеров), никто не похакает, заддосит, зароскомнадзорит тебе форум. Для замены трекера - такой же проект с проектами, который будет модерировать какой-то чел или коллегиально. Хттп сервак - просто клиент с подписками, который лепит стат. хттп странички из того, что пришло.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от saufesma

Дело в том, что еще один форум/конфочка в телеге/борда - это просто увеличение фрагменации, а нужен наоборот инструмент, который её уменьшит и соберёт всех в кучу.

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

zeronet Git Center подходит почти по всем критериям. хз правда что там сейчас с приватными репами

Morin ★★★★
()
Ответ на: комментарий от crutch_master

Я подразумевал машиностроение. А там поделку надо делать из железа, а делать её токарь будет, а ему надо платить. Как тут быть?

saufesma
()
Ответ на: комментарий от crutch_master

Я привёл пример с квадратом только для того, чтобы показать что логика наследования в ООП весьма неочевидна и неоднозначна. И так понятно что квадрат не может наследовать прямоугольник.

И причина тому - тот факт что изменение ширины квадрата должно давать побочный эффект - изменение его длины, что недопустимо с точки зрения пользователя интерфейса «прямоугольник».

И это просто пример, на практике всё гораздо сложнее и вырвиглазнее: добавляют переменную «сторона» и методы, которые с ней работают. Переменные «длина» и «ширина» в квадрате уже ни на что не влияют. И так далее. Я насмотрелся такого безобразия в коде игры Unreal Tournament.

svyatozar ★★
() автор топика
Последнее исправление: svyatozar (всего исправлений: 2)
Ответ на: комментарий от saufesma

Я про использование ЛОР как рабочей площадки под проекты

Функция ЛОРа — это отдых, развлечения, психологической разгрузка, нетворкинг и иногда хобби (я тут не про троллинг). Т.е. это всё же entertainment. Вот под такие проекты ЛОР может стать отличной площадкой. Тем более, что пока тут еще сохраняется уникальная атмосфера интернетов, какими они были когда-то.

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

В этом и состоит проблема площадок под рабочие проекты. В US много бабла в OSS вливается через разные нонпрофиты, но сейчас вместе с денюжкой приходит требование внедрять и строго соблюдать code of conduct. А теперь представь LOR в таком окружении)))

aist1 ★★★
()
Ответ на: комментарий от crutch_master

который её уменьшит и соберёт всех в кучу

Учитывая, что ЦА — славяне, то тут нужен не инструмент, а Властелин. Славяне очень индивидуалистичны и к кучкованию не склонны. Нужен лидер.

aist1 ★★★
()
Ответ на: комментарий от saufesma

Тут пусть PR-отдел ЛОРа креативит, кого Павкой Корчагиным назначить)

aist1 ★★★
()
Ответ на: комментарий от crutch_master

Да какая разница, каких спецов собирать.

А может, Властелин это Идея вокруг которой и собираются спецы увлечённые этой Идеей. С денежкой только как?

saufesma
()
Ответ на: комментарий от saufesma

Я между делом занимаюсь вопросами «программирования человека», так как «программирование компьютеров» — это уже пройденный этап. Так что тема организации сообществ мне близка, но в практическом плане я тут пока ничего не делаю. Но скоро придется. Я, может быть даже, продюссерскую компанию создам.

До «программирования фабрики реальности» я еще не дошел)

aist1 ★★★
()
27 сентября 2021 г.

https://habr.com/ru/post/451982/

Внутреннее противоречие и наглая ложь в 10-м абзаце. Дальше читать бессмысленно. Очередной наполеон воюет с голосами в своей голове.

olegd ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.