и… собственным самодельным ORM, к которому я неизбежно приду в попытках решить те же задачи
Собственно, да. Проблема реляционных данных в том, что они напрямую на экран пользователя не попадают. Они проходят через промежуточный слой - слой приложения. Которое, как правило, объектно-ориентированное. И в нём удобно работать со строкой из таблицы, как с объектом. Поэтому, как ни крути, а объекто-реляционный маппинг данных будет.
Для тех времён дисковод был непозволительной роскошью в этом сегменте. AY8912 конечно - это неплохо, но вот с экраном просто беда.
Поясню: 240х200 - это 6000 байт монохрома, плюс по 40 байт цвета на строку, ещё 8000 байт. Когда процессор 1мГц, то получается при 50гц развёртки бюджет 1,42 такта на байт экрана в кадр. Это очень мало. У спектрума 10,12 тактов на байт экрана (3,5 мГц 256х192).
DDD не для вас и репозитории вам в принципе не нужны
Я бы не стал так категорично придираться к терминологии. Есть устоявшийся термин - "бизнес-логика". Это логика обработки данных в терминах бизнеса. По сути это логика домена. И что значит "репозитории в принципе не нужны"? Если я, допустим, не следую DDD, то мне репозитории не пригодятся?
Далее, вот этот вот набор фильтров имеет какой-то смысл с точки зрения доменной логики?
В данном случае нет, но в реальном коде у меня есть ещё более всратые примеры. Их много. Их сложно назвать и их незачем выносить в отдельный именованый тип. Потому что когда условие заинлайнено в логику, то логика хорошо читается. Она легко правится.
Ваша позиция мне понятна, но неприятна. Я не считаю необходимым условием именовать каждый фильтр. Это уже крайность.
Каждый из этих этапов выполняется в один такт. В CISC процессорах пока одна инструкция проходит эти 5 этапов, вторая ждёт полного исполнения инструкции, чтобы начинать первый этап
Нет, в CISC вполне себе конвеер c i486 и какие-то команды могут исполняться в один и тот же такт на разных блоках (с пентиума про). Вот старая статья про них.
Облака не так уж и высоко находятся в небе, чтобы прямо на порядки больше излучения в них попадало. Даже те, которые на уровне 6-8 км. Мы прямо здесь на земле могли бы заряжать пар этими космическими лучами, хоть и чуть медленнее.
И плюс ещё я что-то слышал про какое-то магнитное поле земли, которое отклоняет частицы.
Так если заинлайнить критерии отбора в логику доменной сущности или какого-нибудь репорта, разве это станет меньше DDD? Я думаю нет. Не всегда и не везде нужно такое мелкое дробление. Вынос критериев в отдельные методы хоть и уменьшает основной метод, но заставляет прерывать контекст при чтении кода.
В любом случае, если рассматривать IQueryable как инструмент (коим он и является), то с ним у меня есть возможность писать в логике условия, а без него - нет.
А давайте вы сначала покажете, где в этой "виртуальной машине" находится резолв методов и всё прочее, о чём мы спорили.
Потому что сейчас вы пытаетесь натянуть сову на глобус, цепляетесь к терминологии.
Да называйте чем хотите. Я с первого сообщения пытаюсь донести мысль, что в дотнете код запускается точно также, как и нативный. Там нет никакой песочницы. Это нативно скомпилированный код, а не какая-то интерпретационная машина. И даже не виртуальная машина, потому что там нет виртуализации.
Давайте, покажите, какие издержки у этой "виртуальной машины". Что там "тормозит". По какой причине код шарпа в принципе не может быть быстрее c++/rust.
И очень забавно, что у @FFS_Studiosбыл только один коммент и только под вашей статьёй. Совпадение? И один плюс в карму при одном комменте. Вот же везунчик, а?
Мне всё равно, что там написано. Clr не является виртуальной машиной в том смысле, в котором мы спорим. Там нет накладных расходов на работу кода. Это рантайм-библиотека вроде stdlib, только с GC, JIT и другими вещами. Этот вопрос ещё 2009 году обсуждался на SO
Вы разберитесь сначала, что за накладные расходы виртуальной машины такие, потом говорите. Для начала узнайте, что такое JIT-компилятор. И почему он называется "компилятор".
JIT который секретные оптимизации делает в рантайме
Если для вас векторные инструкции вроде AVX - это секретные оптимизации, то я вас слегка огорчу. Они ни для кого не секретные.
Вы мне на вопрос не ответили. Какой-то газ, какая-то вода. Работу человека кто считать будет? Зря что-ли такая разница в стоимости между приготовленной едой и продуктами в магазине.
И ещё вопрос вдогонку: будете головой работать за миску риса в день? Я - нет.
он будет сливать С++, Rust etc хоть с AOT хоть без него.
Вообще не факт. JIT-компилятор ориентируется на платформу, на которой запущен и может оптимизировать код под фичи процессора. А классическая картина для скомпилированных крестами бинарей - заточка под все процы, включая говно мамонта. И да, Native AOT работает медленнее IL кода с JIT. Но зато запускается моментально.
Поэтому вместо необоснованного повсеместного отказа от ORM я бы предложил скорее решать проблемы точечно: настраивать ORM под свою задачу и использовать обычные запросы там, где эффективности ORM вам не достаточно.
Да ладно! Вы решили, что ORM - это не религия, а всего лишь инструмент управления сложностью, он не всегда подходит и надо им пользоваться там, где его применение оправдано?
Собственно, да. Проблема реляционных данных в том, что они напрямую на экран пользователя не попадают. Они проходят через промежуточный слой - слой приложения. Которое, как правило, объектно-ориентированное. И в нём удобно работать со строкой из таблицы, как с объектом. Поэтому, как ни крути, а объекто-реляционный маппинг данных будет.
Для тех времён дисковод был непозволительной роскошью в этом сегменте. AY8912 конечно - это неплохо, но вот с экраном просто беда.
Поясню: 240х200 - это 6000 байт монохрома, плюс по 40 байт цвета на строку, ещё 8000 байт. Когда процессор 1мГц, то получается при 50гц развёртки бюджет 1,42 такта на байт экрана в кадр. Это очень мало. У спектрума 10,12 тактов на байт экрана (3,5 мГц 256х192).
Про "The Day Before" надеюсь сарказм. А Ведьмак, который великий, он на Red Engine. А тот, который на UE, тот не великий и даже ещё не вышел.
окей
Я бы не стал так категорично придираться к терминологии. Есть устоявшийся термин - "бизнес-логика". Это логика обработки данных в терминах бизнеса. По сути это логика домена. И что значит "репозитории в принципе не нужны"? Если я, допустим, не следую DDD, то мне репозитории не пригодятся?
В данном случае нет, но в реальном коде у меня есть ещё более всратые примеры. Их много. Их сложно назвать и их незачем выносить в отдельный именованый тип. Потому что когда условие заинлайнено в логику, то логика хорошо читается. Она легко правится.
Ваша позиция мне понятна, но неприятна. Я не считаю необходимым условием именовать каждый фильтр. Это уже крайность.
Гибридом RISC и CISC был Cyrix 6x86 (M1) намного позже. У него было рисковое ядро и транслятор x86 в команды ядра. Вот статья.
Нет, в CISC вполне себе конвеер c i486 и какие-то команды могут исполняться в один и тот же такт на разных блоках (с пентиума про). Вот старая статья про них.
Облака не так уж и высоко находятся в небе, чтобы прямо на порядки больше излучения в них попадало. Даже те, которые на уровне 6-8 км. Мы прямо здесь на земле могли бы заряжать пар этими космическими лучами, хоть и чуть медленнее.
И плюс ещё я что-то слышал про какое-то магнитное поле земли, которое отклоняет частицы.
Так если заинлайнить критерии отбора в логику доменной сущности или какого-нибудь репорта, разве это станет меньше DDD? Я думаю нет. Не всегда и не везде нужно такое мелкое дробление. Вынос критериев в отдельные методы хоть и уменьшает основной метод, но заставляет прерывать контекст при чтении кода.
В любом случае, если рассматривать IQueryable как инструмент (коим он и является), то с ним у меня есть возможность писать в логике условия, а без него - нет.
Вот зачем
Чтобы у меня бизнес-логика хорошо читалась, когда в различных местах нужны совершенно разные выборки по фазе луны и др начальника.
Я понял, что если кто-то в интернете не прав, то это не мои проблемы, а его.
Так что всего хорошего. Это вам с такими убеждениями жить дальше.
А давайте вы сначала покажете, где в этой "виртуальной машине" находится резолв методов и всё прочее, о чём мы спорили.
Потому что сейчас вы пытаетесь натянуть сову на глобус, цепляетесь к терминологии.
Да называйте чем хотите. Я с первого сообщения пытаюсь донести мысль, что в дотнете код запускается точно также, как и нативный. Там нет никакой песочницы. Это нативно скомпилированный код, а не какая-то интерпретационная машина. И даже не виртуальная машина, потому что там нет виртуализации.
Давайте, покажите, какие издержки у этой "виртуальной машины". Что там "тормозит". По какой причине код шарпа в принципе не может быть быстрее c++/rust.
И очень забавно, что у @FFS_Studiosбыл только один коммент и только под вашей статьёй. Совпадение? И один плюс в карму при одном комменте. Вот же везунчик, а?
Мне всё равно, что там написано. Clr не является виртуальной машиной в том смысле, в котором мы спорим. Там нет накладных расходов на работу кода. Это рантайм-библиотека вроде stdlib, только с GC, JIT и другими вещами. Этот вопрос ещё 2009 году обсуждался на SO
https://stackoverflow.com/questions/1564348/is-the-clr-a-virtual-machine
CLR - это не виртуальная машина. Это рантайм. Там нет никакой прослойки между исполняемым кодом и ОС.
MissingMethodException срабатывает только на typeof(App).InvokeMember(), что является частью рефлекшена.
Про ссылку на RyuJIT не понял ничего. Тоже компилер. Он не виртуальная машина. Интерфейс его - это рантайм компиляция IL кода из рефлекшена.
И картинка здесь зря. Не разбираетесь - не лезьте.
Нет в дотнете виртуальной машины.
Бред. Это компилируемый язык. Если метода нет, код не скомпилируется.
Нет.
Это вы сейчас с джавовым хотспотом путаете. Впрочем там тоже не так всё просто.
Лол
Лол нет. Во время компиляции. Виртуальной машины не существует.
Всё вышеперечисленное просто не существует.
Именно. Потому что для поддержки инструкций нужно компилить с поддержкой инструкций. Дотнет это может делать на целевой машине, а кресты - нет.
Вы разберитесь сначала, что за накладные расходы виртуальной машины такие, потом говорите. Для начала узнайте, что такое JIT-компилятор. И почему он называется "компилятор".
Если для вас векторные инструкции вроде AVX - это секретные оптимизации, то я вас слегка огорчу. Они ни для кого не секретные.
Вы мне на вопрос не ответили. Какой-то газ, какая-то вода. Работу человека кто считать будет? Зря что-ли такая разница в стоимости между приготовленной едой и продуктами в магазине.
И ещё вопрос вдогонку: будете головой работать за миску риса в день? Я - нет.
Вообще не факт. JIT-компилятор ориентируется на платформу, на которой запущен и может оптимизировать код под фичи процессора. А классическая картина для скомпилированных крестами бинарей - заточка под все процы, включая говно мамонта. И да, Native AOT работает медленнее IL кода с JIT. Но зато запускается моментально.
А почему вы сравниваете еду, которую ещё нужно пойти купить и приготовить с электричеством, которое приготовили и доставили ко мне в дом?
Давайте сравним с перегретым радиоактивным паром первого контура ВВЭР тогда уж. Вот там будет дёшево. Но нужно самому прийти и приготовить.
Да ладно! Вы решили, что ORM - это не религия, а всего лишь инструмент управления сложностью, он не всегда подходит и надо им пользоваться там, где его применение оправдано?