Торвальдс и не должен предлагать решение. Представьте, что в вашу работу постоянно лезут с идиотскими "оптимизациями", не зная, как это всё работает. А на ваши аргументы предлагают вам самим решить проблему.
Вообще-то Торвальдс прав и вполне внятно обосновал свою точку зрения. Если делаете инструмент, то от него должно быть больше пользы, чем вреда. Он даже расписал, в каких конкретных случаях переполнение используется осмысленно.
Существуют всяческие анализаторы кода, которые становятся умнее и умнее. Я не вижу какой-то принципиальной проблемы, чтобы научить анализатор правильно обрабатывать намеренные переполнения, имея перед собой паттерны их применения.
В таких разработках, как разработка компилятора, в первую очередь заботятся об обратной совместимости, потому что никому не надо переписывать то, на что потрачены тысячи человеко-лет. Я так понял, что Кис предлагает сломать совместимость. Вот только за это я бы его подальше ещё послал.
Может быть действительно, не стоит трогать компилятор и добавить статический анализатор в воркфлоу.
Вот удивляюсь с людей, которые ноут приравнивают к компьютеру. Я вот привык к десктопу, к его полноценным мониторам, клавиатурам, мышам. Можно, конечно, это всё подключить и к ноуту. Но он же будет выть как зараза, сводя на нет все преимущества бесшумности.
Ну и плоская клавиатура на мой вкус фу. Я такое не ем.
А зачем тогда корпус переделывать? Просто отпиливаем дисплей и получаем готовый системный блок. Жёсткость уже за нас инженеры рассчитали и применили нужные материалы. Бонусом имеем встроенный бесперебойник, встроенную клавиатуру и тачпад.
Был бы экран, вообще можно было бы пользоваться автономно...
Лень ещё как существует. Мы миллионами лет были рептилиями и каких-то 10 тыс лет назад у нас появилась перфронтальная кора головного мозга, что по меркам эволюции - секунды. Именно она отвечает за долгосрочное планирование жизни и дела, которые помогут в будущем. Если она рептилию победит, конечно. Рептилия хочет жрат и спат.
Вот когда побеждает рептилия, это и называется лень. Мы делаем то, что делают рептилии - экономим силы и запасаем жиры и делаем это в ущерб своему будущему, прекрасно об этом зная.
При рассмотрении приложения в комплексе, внезапно оказывается, что функционально неполная абстракция - это именно что SQL. Именно SQL ограничен декларативной парадигмой, а сверхсложную логику пишут на языках общего назначения.
ORM в следствии своей парадигмы, толкает на написание работы с данными внутри кода, что приводит цельности логики и его дальнейшему рефакторингу.
Про безопасность - это вообще не к орм. Просто потому что орм - маппер. То, что он умеет генерировать sql, не накладывает на него обязанность следить за уязвимостями протоколов. И вообще обычно канал orm-db защищён по умолчанию.
ролевые модели в БД умеют генерировать
Кхм. С этого места пожалуйста поподробнее. Мне кажется, что мне вас есть чем приятно удивить.
Да ладно. А MyBatis какие данные маппит? Случайно не реляционные? Может оно XML парсит?
Я же загуглить успел. MyBatis вполне себе ORM, на хабре статьи про неё есть. Внезапно с тегом ORM. Я не разобрался, умеет ли оно в джоин. Скорее всего нет. Там концепция "сам напиши свои джойны, я только маплю".
Язык SQL декларативный. В том порядке, в котором захочет СУБД. Проще её саму спросить. Индексы БД не обязана использовать, но обычно использует. Если данных много - крутите кэши под ваш сценарий. Может у вас хэви инсерт, а для селекта можно подождать - тогда кэши не спасут.
Сомневайтесь, это полезно. Проясню ремарку: сегодняшние orm, пока в них не внедрили нейросети, очень сильно ограничены по функционалу. В сгенерированных запросах нет ничего сложного. Нет латерал джойнов, в юнионы по-моему ни одна не умеет. Даже group by с having умеют единицы. Про CTE вообще молчу. Человек намного изощрённее любой ORM. Естественная нейросеть способна нагородить куда более ужасную и изощрённую конструкцию, чем самый продвинутый фреймворк
In theory, theory and practice are the same.In practice, they are not.
После переписывания на какой-нибудь шарп огромная хранимка начинает работать в разы быстрее. Почему? Просто потому, что стала понятнее и программист начал понимать, что запрашивать, что нет. Попробовал несколько вариантов построения. Просто думал на другом уровне, абстрагируясь от нагромождения sql.
p.s. триггеры, юники, ключи и прочие констрейнты работают не только для встроенного языка
Если вам сложно не нагородить десятиэтажных конструкций, может вам не надо в айти? Айти всё-таки про огромное количество вариантов, как сделать одно и то же. Здесь нет точного рецепта, как правильнее. Тут самому приходится выбирать пути, ошибаться и пробовать снова. И ещё нести ответственность за выбранные решения.
Специально сконструированный язык базы данных действительно быстрее за счёт быстрого доступа. В теории.
На практике эта скорость никому не нужна, пока приложение не умеет делать то, что оно должно делать. Быстро, но фигню - это не надо.
На практике получается парадоксальная ситуация: переписанная логика pl/sql в сишарп начинает работать быстрее в разы. Как такое возможно? Теоретически никак. Доступ к данным у шарпа по определению медленнее.
Это одно из самых распространённых заблуждений об ORM, которые я встречал. Делать сложные запросы - это не задача ORM. ORM в первую очередь - маппер. ORM и SQL вообще ортогональны в этом вопросе.
Тут так: если хотите читаемый и поддерживаемый код: пишете на орм. Хотите любить гусей - пишете на чистом sql. Как-то одно другому мешает? На практике оказывается, что сложные запросы нужны, мягко скажем, не в критичном количестве. А ежедневная рутина делается проще на орм.
Некоторые ORM вообще могут работать с raw sql. Просто позволяют писать запросы, и после делают маппинг на объекты.
Специфика ORM в том, что он сам по себе накидывает сложности проекту. И это оправдано там, где сложность проекта стала проблемой. Собственно, об этом и статья.
SELECT * FROM db.Orders a WHERE a.IsCompleted = 1 AND YEAR(a.CreatedDate) > 2020 ORDER BY a.ID
Разница невелика на первый взгляд. Просто чистый sql ещё предстоит отправить через коннекшен, получить результат и распихать по полям объектов. ORM сам всё делает, строка самодостаточна.
Проблема всех этих синтетических примеров, когда собака наследуюется от животного в том, что не даётся полного контекста, как эти классы будут использоваться в будущем. Пока нет контекста, как используется квадрат и прямоугольник, всё, что мы предполагаем о правильности или неправильности - гадание на кофейной гуще.
Мы просто не знаем, зачем добавили прямоугольник в приложение. Это область детектирования номерных знаков автомобиля? Это баундбокс текстовой строки? Это примитив рисования?
Наследование квадрата от прямоугольника может быть правильным. Как и наследования прямоугольника от квадрата. Смотря чего хотите.
С одной стороны соглашусь. Команда должна быть сильная, чтобы понимать, что она делает и зачем. Конечно, без базовых знаний SQL заниматься разработкой приложения с ORM прямо противопоказано. Архитектурой тем более должен заниматься сильный программист, а внедрение ORM - это архитектура приложения.
С другой стороны, ORM умеет генерить селекты c where и некоторые умеют в left join. У EF правда есть linq to entities, где можно совращать гусей, но тут синтаксис максимально близок к sql. Если честно, совсем не понимаю, что в этих запросах может быть сложного.
Простите, а когда это "потом" начнётся? Один проект у меня уже 13 лет на ORM, пока всё хорошо. Или имеется в виду, что падает скорость разработки? Тогда тем более непонятно. ORM как раз нужен, чтобы снизив сложность, её повысить. И это работает.
Торвальдс и не должен предлагать решение. Представьте, что в вашу работу постоянно лезут с идиотскими "оптимизациями", не зная, как это всё работает. А на ваши аргументы предлагают вам самим решить проблему.
Вообще-то Торвальдс прав и вполне внятно обосновал свою точку зрения. Если делаете инструмент, то от него должно быть больше пользы, чем вреда. Он даже расписал, в каких конкретных случаях переполнение используется осмысленно.
Существуют всяческие анализаторы кода, которые становятся умнее и умнее. Я не вижу какой-то принципиальной проблемы, чтобы научить анализатор правильно обрабатывать намеренные переполнения, имея перед собой паттерны их применения.
В таких разработках, как разработка компилятора, в первую очередь заботятся об обратной совместимости, потому что никому не надо переписывать то, на что потрачены тысячи человеко-лет. Я так понял, что Кис предлагает сломать совместимость. Вот только за это я бы его подальше ещё послал.
Может быть действительно, не стоит трогать компилятор и добавить статический анализатор в воркфлоу.
Вот удивляюсь с людей, которые ноут приравнивают к компьютеру. Я вот привык к десктопу, к его полноценным мониторам, клавиатурам, мышам. Можно, конечно, это всё подключить и к ноуту. Но он же будет выть как зараза, сводя на нет все преимущества бесшумности.
Ну и плоская клавиатура на мой вкус фу. Я такое не ем.
Главное, чтобы Nvidia не поставила пробел куда не надо )
А зачем тогда корпус переделывать? Просто отпиливаем дисплей и получаем готовый системный блок. Жёсткость уже за нас инженеры рассчитали и применили нужные материалы. Бонусом имеем встроенный бесперебойник, встроенную клавиатуру и тачпад.
Был бы экран, вообще можно было бы пользоваться автономно...
Лень ещё как существует. Мы миллионами лет были рептилиями и каких-то 10 тыс лет назад у нас появилась перфронтальная кора головного мозга, что по меркам эволюции - секунды. Именно она отвечает за долгосрочное планирование жизни и дела, которые помогут в будущем. Если она рептилию победит, конечно. Рептилия хочет жрат и спат.
Вот когда побеждает рептилия, это и называется лень. Мы делаем то, что делают рептилии - экономим силы и запасаем жиры и делаем это в ущерб своему будущему, прекрасно об этом зная.
Вот это вот лень, а не то, что у вас в статье.
При рассмотрении приложения в комплексе, внезапно оказывается, что функционально неполная абстракция - это именно что SQL. Именно SQL ограничен декларативной парадигмой, а сверхсложную логику пишут на языках общего назначения.
ORM в следствии своей парадигмы, толкает на написание работы с данными внутри кода, что приводит цельности логики и его дальнейшему рефакторингу.
Про безопасность - это вообще не к орм. Просто потому что орм - маппер. То, что он умеет генерировать sql, не накладывает на него обязанность следить за уязвимостями протоколов. И вообще обычно канал orm-db защищён по умолчанию.
Кхм. С этого места пожалуйста поподробнее. Мне кажется, что мне вас есть чем приятно удивить.
Да ладно. А MyBatis какие данные маппит? Случайно не реляционные? Может оно XML парсит?
Я же загуглить успел. MyBatis вполне себе ORM, на хабре статьи про неё есть. Внезапно с тегом ORM. Я не разобрался, умеет ли оно в джоин. Скорее всего нет. Там концепция "сам напиши свои джойны, я только маплю".
Дружище, определись уже. Либо оно мапит данные на класс, то тогда оно ORM, либо не маппит, тогда оно не ORM.
Язык SQL декларативный. В том порядке, в котором захочет СУБД. Проще её саму спросить. Индексы БД не обязана использовать, но обычно использует. Если данных много - крутите кэши под ваш сценарий. Может у вас хэви инсерт, а для селекта можно подождать - тогда кэши не спасут.
Сомневайтесь, это полезно. Проясню ремарку: сегодняшние orm, пока в них не внедрили нейросети, очень сильно ограничены по функционалу. В сгенерированных запросах нет ничего сложного. Нет латерал джойнов, в юнионы по-моему ни одна не умеет. Даже group by с having умеют единицы. Про CTE вообще молчу. Человек намного изощрённее любой ORM. Естественная нейросеть способна нагородить куда более ужасную и изощрённую конструкцию, чем самый продвинутый фреймворк
В теории всё так. But.
In theory, theory and practice are the same. In practice, they are not.
После переписывания на какой-нибудь шарп огромная хранимка начинает работать в разы быстрее. Почему? Просто потому, что стала понятнее и программист начал понимать, что запрашивать, что нет. Попробовал несколько вариантов построения. Просто думал на другом уровне, абстрагируясь от нагромождения sql.
p.s. триггеры, юники, ключи и прочие констрейнты работают не только для встроенного языка
Если вам сложно не нагородить десятиэтажных конструкций, может вам не надо в айти? Айти всё-таки про огромное количество вариантов, как сделать одно и то же. Здесь нет точного рецепта, как правильнее. Тут самому приходится выбирать пути, ошибаться и пробовать снова. И ещё нести ответственность за выбранные решения.
И кто вам запретит писать сложные тяжёлые запросы? У вас кто-то насильно отбирает SQL?
Специально сконструированный язык базы данных действительно быстрее за счёт быстрого доступа. В теории.
На практике эта скорость никому не нужна, пока приложение не умеет делать то, что оно должно делать. Быстро, но фигню - это не надо.
На практике получается парадоксальная ситуация: переписанная логика pl/sql в сишарп начинает работать быстрее в разы. Как такое возможно? Теоретически никак. Доступ к данным у шарпа по определению медленнее.
Это ORM. По определению.
Заманчиво. Орм без недостатков орм. Как это?
Собственно, меня огорчает, что люди противопоставляют ORM чистому SQL. Одно другому не мешает. ОРМ - маппинг. SQL - язык запросов.
Простите, а зачем вам база данных в контроллере с 16кб памяти?
Это одно из самых распространённых заблуждений об ORM, которые я встречал. Делать сложные запросы - это не задача ORM. ORM в первую очередь - маппер. ORM и SQL вообще ортогональны в этом вопросе.
Тут так: если хотите читаемый и поддерживаемый код: пишете на орм. Хотите любить гусей - пишете на чистом sql. Как-то одно другому мешает? На практике оказывается, что сложные запросы нужны, мягко скажем, не в критичном количестве. А ежедневная рутина делается проще на орм.
Некоторые ORM вообще могут работать с raw sql. Просто позволяют писать запросы, и после делают маппинг на объекты.
Специфика ORM в том, что он сам по себе накидывает сложности проекту. И это оправдано там, где сложность проекта стала проблемой. Собственно, об этом и статья.
Я уже однажды приводил пример:
Трансформируется в:
Разница невелика на первый взгляд. Просто чистый sql ещё предстоит отправить через коннекшен, получить результат и распихать по полям объектов. ORM сам всё делает, строка самодостаточна.
Проблема всех этих синтетических примеров, когда собака наследуюется от животного в том, что не даётся полного контекста, как эти классы будут использоваться в будущем. Пока нет контекста, как используется квадрат и прямоугольник, всё, что мы предполагаем о правильности или неправильности - гадание на кофейной гуще.
Мы просто не знаем, зачем добавили прямоугольник в приложение. Это область детектирования номерных знаков автомобиля? Это баундбокс текстовой строки? Это примитив рисования?
Наследование квадрата от прямоугольника может быть правильным. Как и наследования прямоугольника от квадрата. Смотря чего хотите.
С одной стороны соглашусь. Команда должна быть сильная, чтобы понимать, что она делает и зачем. Конечно, без базовых знаний SQL заниматься разработкой приложения с ORM прямо противопоказано. Архитектурой тем более должен заниматься сильный программист, а внедрение ORM - это архитектура приложения.
С другой стороны, ORM умеет генерить селекты c where и некоторые умеют в left join. У EF правда есть linq to entities, где можно совращать гусей, но тут синтаксис максимально близок к sql. Если честно, совсем не понимаю, что в этих запросах может быть сложного.
Простите, а когда это "потом" начнётся? Один проект у меня уже 13 лет на ORM, пока всё хорошо. Или имеется в виду, что падает скорость разработки? Тогда тем более непонятно. ORM как раз нужен, чтобы снизив сложность, её повысить. И это работает.