а для скл как-то не очень

Но это все держится на доверии, потому что в тсп мы можем переслать произвольное количество байтиков, сконкатенировать байтики с байтиками, в итоге мы делаем обьекты одни байтики с другими байтиками, а если надо переслать меньше байтиков мы делаем обьекты "меньше байтиков", а если нужно это по разному комбинировать вообще туши свет, Это я все к тому что ТСР плохо ложится на ООП

ок, но вокруг тцп либ не делают, программисты ваще не знают он есть под капотом

а с скл каждые два года перепридумывают как жить

ну вокруг sql либ не делают, программисты ваще не знают что там jdbc под капотом

ага, тут у 5 человек в чате спроси как они работают с бд и у всех будет разный стек

ну скажем не про tcp а про json такая же ведь фигня будет

ой, это какая-то "потребительская семантика" пошла

в ЯП вы оперируете огромным количеством разных понятий

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

Column[X,Y,U]

В ОРМ не надо никаких AuthorWithBook, если у вас на уровне БД нет каких-то дополнительных свойств связей, которые нужны в бизнес логике. Например в EF можно в конфиге прописать какая таблица с какой связана через третью, все проверится после компиляции и запросы неявно будут использовать эту таблицу. И у вас будет просто автор с массивом книг, который может быть пустым + книги с массивом авторов. Ну а если там связь 1:n то еще проще, даже конфиг не надо зачастую.

Разные модели тоже необязательно делать, те же EF/слик мапят на кортежи/анонимные типы спокойно.

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

Слушайте, а в дотти что в итоге с вацтбокс макросами?

Tasty reflection?

Ну то есть что-то есть?

Да, есть

Норм

в ограниченной форме

Называется whitebox inline