У меня тоже лежит рабочий (только кнопка в ручке сломана, приходится железным штырьком нажимать). И, кажется, это было первое моё личное вычислительное устройство (а МК-61 появился только через пару лет).
Без конкретной структуры 1С, без конкретных запросов, конфигурации оборудования и настроек SQL Server можно долго гадать, но на самом деле умеренно прошаренные 1С-ники и DBA вполне могли уткнуться примерно в такие цифры (там где-то 126 мс на запрос в статье фигурировало по конкретной строке и 15 мс у тарантула).
Запрос по остаткам, если не приложить особых усилий, это соединение 3 таблиц (справочник с фильтром, остатки и движения). Если действовать по рекомендациям 1С (т.е. фильтр по справочнику в параметрах виртуальной таблицы), то четырёх (фильтр отдельно джойнится к остаткам и движениям). Но MS SQL отлично (лучше других СУБД, применимых к 1С) умеет прокидывать фильтр в отдельные таблицы подзапроса.
В любом случае без дополнительных приседаний это в SQL будет что-то типа
SELECT Ref.ref, Reg2.s
FROM Ref
JOIN
(SELECT SUM(Reg1.s) s, Reg1.ref
FROM
(SELECT ref, -s FROM Reg WHERE DateCodition1
UNION ALL
SELECT ref, s FROM RegTotals WHERE DateCodition2) Reg1
GROUP BY Reg1.ref
HAVING SUM(Reg1.s)<>0
) Reg2
ON Ref.Descr like '1293%'
(это очень упрощённо! И если писать "как рекомендует 1С", то джойны будут к Reg и RegTotals — так SQL Server работает хуже в данном кейсе)
А каждое изменение остатков это изменение конечного остатка в RegTotals и движений в Reg (и, если обмен данными, то ещё регистрация изменений)
Дальше можно заставить 1С:
Не брать движения вообще, а брать только из итогов. Для этого, как минимум, не должно быть движений "в будущем"
Вести отдельный регистр остатков с строкой поиска (если правильно делать, то с индексами там будет правильно)
Тогда запрос станет примерно таким:
SELECT Reg2.ref, Reg2.s
FROM
(SELECT SUM(Reg1.s) s, ref
FROM
(SELECT ref, s
FROM RegTotalsWithDescr
WHERE DateCodition2 AND RegTotals.Descr like '1293%') Reg1
GROUP BY ref
HAVING SUM(Reg1.s)<>0
) Reg2
Но кроме банальных планов запросов и индексов там надо ещё смотреть:
Работает ли RCSI (он может работать) в 1С.
Если не работает, то не фигню ли показывают остатки (т.к. тогда запросы с readuncommitted)
Если не работает, то не уприраемся ли в блокировки?
Если работает, то не упираемся ли в tempdb
Не упираемся ли в журнал транзакций (если да, то планируем диски правильно)
Не упираемся ли в компиляцию запросов (если временные таблицы используем, то легко, у 1С временные таблицы всё время с новыми именами)
Не упираемся ли в какие-то другие изменения (регистрация в план обмена, например)
Не упираемся ли вообще в другие механизмы.
Короче, там много всего еще надо посмотреть. 15 мс в тарантуле это в общем-то тоже дофига.
То есть если много людей оценили вашу работу как «хорошо», то «вы нам не подходите» (WHAT???!!).
Так это простое следствие теории игр. Не имеет смысла ставить оценки в системе, кроме лучшей и худшей. Пусть у нас есть большое количество голосующих N и 10-бальная шкала. Пусть сейчас оценка Х. Голосующий считает, что справедливая оценка Y. Если он поставит Y, то приблизит оценку на величину порядка abs((X-Y)/N). Если он поставит экстремальную оценку, то приблизит гораздо сильнее. Шах и мат.
Кстати, про выдержку и ночную съёмку. Для северного сияния не очень критично (потому что чаще холодно), но всё же. Длинная выдержка -> нагрев матрицы -> больше шумов. Если выдержка уходит за 10 с, то это может быть уже важно. Тогда либо сознательно недоэкспонировать и тянуть (прощай детализация цветов и динамический диапазон), либо повысить ISO (но часто результат почти идентичен предыдущему). Или активно охлаждать тушку между кадрами. Ну или срочно сбегать в магазин и купить фотоаппарат с лучшей чувствительностью (ага, зимой в 3 ночи в поле, где поменьше засветки).
Помните: аврал можно сделать в любом проекте, если быстро и без шума уволить половину разработчиков.
Ф. Брукс еще 40+ лет назад сказал, что с тем же (и даже большим) успехом можно и нанять. А то вдруг без половины разработчиков станет проще и быстрее согласовывать и писать. А если нанять ещё 2n программистов, то можно и себе денег больше попросить, и программистов постоянно укорять: "сколько же вас надо нанять, чтобы хоть что-то делалось".
Проще всего подписать меня на все рассылки Jira, все публичные каналы Slack и другие доступные уведомления (без права на обжалования).
А важную информацию, наоборот надо обсуждать только в ветвящейся переписке с постоянно меняемым списком адресатов.
Заставьте оправдываться за каждый обнаруженный на тестировании баг
Это работает только с джунами. Опытный знает, что он допускает баги. И даже уже гордится некоторыми. Продуктивнее запрещать элементы TDD и максимально усложнить процесс регистрации багов (KPI по количеству, согласование с QA на заведение багов, массовое внесение инцидентов, как багов — тут много приёмов)
Отличная встряска — задержка зарплаты.
На нынешнем рынке труда — слишком одноразовый приём. Лучше намекать на премию, но не платить. Главное — премия должна быть максимально непредсказуемой.
формулируйте ТЗ как можно короче.
С тем же успехом — как можно длиннее. Круто кинуть в разработчика 400-страничной спекой: "Оцени наши доработки в проекте". Наши доработки — это изменение XML схемы, которое следует из требований одного абзаца на странице 324.
Если вы хотите обновить технологический стек, подумайте: чем новее технология, тем она сомнительнее
С тем же успехом можно менять стек каждые полгода-год.
Рекомендации очень аккуратные, систематичные, детальные и разумные, фотки классные. Фотографией занимаюсь 30+ лет, поэтому нового для себя в части техники фото не открыл, но оценил, а в части ссылок на тематические и вспомогательные ресурсы — сокровищница.
Я одновременно согласен с вами — у вас весьма аккуратные формулировки "невероятная сложность изменений и вывода новых методов лечения и препаратов", "Скорость вывода инноваций в ИТ несоизмеримо больше, чем в медицине, цена риска (...) ниже" и "Каждый подход имеет свои ограничений и хорош для своей области". Это всё так. Но есть момент, в котором хочу возразить. Медицина очень консервативна. Это в определённой мере так. От идеи до врача проходит немало времени, особенно в методах лечения и выводе новых препаратов. Но на самом деле медицина быстро меняется. Не в смысле, что меняется скорость внедрения, а в том смысле, что диагностика, методы лечения и препараты очень быстро меняются. На уровне условного "участкового терапевта" это не так заметно, но все специализированные и технологичные направления меняются очень быстро. В диагностике МРТ, анализ ДНК ещё лет 10 назад были в целом экзотикой. Сейчас это мейнстрим. Стали применяться технологии ИТ для обработки данных в несравнимом объёме. Офтальмологическая хирургия, ЭКО, лечение опухолей, протезирование конечностей, нейрохирургия — всё это тоже за 10-15 лет тоже изменилось очень существенно. Да, в диагностике изменения быстрее, чем лечении — для диагностики обычно проще убедиться, что она безопасна. В программировании, за исключением нескольких областей (типа веб-фреймворки, облачные технологии, да всякие "блокчейны"), скорость прогресса сопоставима, если не меньше. А в проектировании реляционных БД вообще можно смело брать книгу Дейта 20-летней давности.
Да, у нас, в ИТ есть возможность попробовать новые технологии хоть вчера придуманные в прямо проме (только чувакам из core banking processing этот секрет не говорите :) ) — это так. Не везде, но можно. У медиков так не получится. Но это latency. А вот throughput изменений в целом вполне сопоставим. И устаревают у них, у медиков, знания — только в путь (регуляторно обязательные обучения не на пустом месте возникли).
Интересно, что 1С с списками в экранных формах работает именно так — не через offset, а через top N where "записи ниже последней". Это и по причинам прозводительности и по причинам того, что 1С работает с 5 разными СУБД (часто используется общий функциональный минимум).
При этом, кстати, корректно обрабатывается сортировка по нескольким полям при том что первые поля (и комбинации левого "подкортежа" сортировки) не являются уникальными. Там, правда, нюанс — "корректно" не всегда значит "эффективно" — в некоторых пограничных случаях идёт жёсткий пролёт мимо удачного плана, к счастью, это достаточно редкие случаи, которых можно/нужно избегать (а в SQL Server 2005 c SP до четвёртого приводил к падению SQL Server, но это именно бага SQL Server).
В MS SQL часто по подходящему уникальному полю есть кластеризованный индекс, а значит его значения есть в каждом некластеризованном. В этом случае на самом деле индекс (sort_column) и (sort_column, unique_column) на уровне движка БД тупо одинаковый.
PS: Для Oracle и PostgeSQL это не так.
Для получения номера последней страницы нужно выбрать и посчитать все записи. Уже при миллионах записей это работает никак. Для современных СУБД миллиард записей — нормальная ситуация. Даже для того, чтобы убедиться что страниц "очень много" (и можно забить на нумерацию) нужен достаточно тяжёлый запрос.
Содержимое N-й страницы зависит от всех предыдущих и потенциально разное при каждом селекте.
Ну и как правильно указали в статье — для номерной страницы часто используют offset, который в лучшем случае линейно зависит от номера страницы.
А бывает наоборот. Я как-то несколько лет назад находил багу в .NET, когда неудачный алгоритм инлайна в релизном режиме приводил к экспоненциально долгому и также экспоненциально прожорливому потреблению памяти JIT. Сейчас (после моего репорта в core, но проявлялось и в framework) багу уже пофиксили. Хотя, на мой взгляд и неидеально пофиксили, но всяко лучше, чем было.
С параметром Разделитель я никаких модификаций не произвожу, поэтому и без Знач.
Тут в другом дело. Я уже лет 15 убеждён, что 1С сделала ошибку, не сделав Знач по умолчанию (как поступили авторы C# c ref). По-хорошему почти-почти всё, кроме того, что явно модифицируется и отдаётся обратно должно быть знач.
Я вот не определился, читерство это или нет :) Но в одном определился: ваш КоннекторHTTP — крутейшая вещь. Спасибо за наводку, я, как архитектор уже начал обсуждение использование этой библиотеки у нас.
Собственно, мне кажется, что это то, как должна была выглядеть работа с HTTP в платформе.
И написана прям добротно-добротно:
Код структурирован, даже области используются — уважуха.
Методы небольшие, всё как надо. Декомпозиция на функции очень разумная.
Экспортные функции выделены в отдельный блоки и каждая экспортная функция со стандартным комментом
Код стандартно отформатирован, без грязноты практически, комменты по делу, нет широченных строк. Ну это же читается, как поэма!
Даже есть какой-никакой CI, статанализ и тесты.
Не скажу, что это нельзя улучшить, но на пару уровней выше кода, который я вижу в среднем.
Что показалось спорным
Я сначала хотел умилиться использованию Знач, но потом понял, что то ли я не понимаю ваших принципов использования Знач, то ли они полуслучайные. Первый попавшийся пример РазбитьСтрокуПоСтроке(Знач Строка, Разделитель) — почему первый параметр с Знач, а второй без?
Тесты. Хардкод в тестах это лучше, чем хардкод в коде, но всё равно плохо. Если модуль собирается без доступа к Интернет, например, то тесты в текущем виде можно выкинуть. По-хорошему, параметры тестов нужно вынести отдельно. Вариантов тут масса, можно, например, вынести их в форму, можно макет, можно в какие-нибудь предопределённые данные. Лично я выносил в макет.
Тесты. Нет раздельного запуска тестов, но это лучше решать не локально для данной библиотеки, а делать фреймворк, а это задача сразу гораздо больше.
Тесты. Отчёт по тестам не для автоматизации. Но это тоже скорее вопрос к отсутствию фреймворка.
По коду тоже есть что сказать, но такие вещи проще и правильнее через PR делать.
И вообще, README.md почти готовая статья на хабр. Ну как "почти" — процентов на 40-60, но это самые важные проценты — скелет и мясо статьи. Не хватает по сути только описания контекста, в котором возникла задача и почему именно так решена, плюс какие-то нюансы поясняющие. Добейте, опубликуйте. Я штук 3-5 голосов-плюсиков точно подгоню, если кинете ссылку (да и EvilBeaver, думаю тоже).
А можно пример где работа с бинарными файлами сделана на порядок лучше?
C, C++, C#, Java, Python, Rust, Go (и ещё несколько сотен языков)
В 1С методы работы с чтением двоичных данных (которые появились в 8.3.9-8.3.10 в 2016 и 2017 годах — совершенно недавно по энтерпрайз меркам) предоставляют весьма низкоуровневые возможности: чтение примитивных числовых и строковых данных. Нет удобных инструментов чтения сразу в структуры данных. Да что там! Даже банально float прочитать — уже изголяться. Да что там float! Даже отдельных методов для знаковых/беззнаковых нет.
А так как с модульностью и переиспользованием кода в 1С задница и юнит-тесты писать заколебёшься, то даже относительно простые потоки данных читать — боль-боль-боль.
А конкретней можно чего вам не хватает при работе c HTTP?
Я не говорю "не хватает". Я говорю "низкоуровневые". То есть сделать можно всё, как можно всё написать на ассемблере. Теоретически — да. Практически даже обращение к простому сервису с аутентификацией и последующий разбор результатов это какие-то невменяемые портянки кода по сравнению, например, с JS. В качестве примера попробуйте какой-нибудь список тикетов из Jira или GitLab по фильтру вытащить, только по-честному с правильной не-basic аутентификацией, без хранения пароля пользователя.
Вроде и делается всё, но уж так это многословно.
Привет вселенной розовых пони! В нашей вселенной во всех российских банках в Java-коде и в базах данных творится совершенно другое. Там идентификаторы в лучшем случае через гугл-транслейт написаны. Плюс ещё терминология бизнеса не совпадает с обратным переводом. И именно поэтому в банках трудятся тысячи аналитиков — если по-честному, то половина их работы разбараться в этой мешанине из идентификаторов.
Потому что механизмы убогие и начинаются не там. Нахера, извините, сценарное тестирование форм, когда нет модульных и интеграционных тестов? А их нет, потому что модульность не завезли, DI не завезли, мокать невозможно, в IDE поддержки нет.
У меня тоже лежит рабочий (только кнопка в ручке сломана, приходится железным штырьком нажимать). И, кажется, это было первое моё личное вычислительное устройство (а МК-61 появился только через пару лет).
Боюсь, мнение с другой стороны баррикад будет существенно отличаться от вашего.
Без конкретной структуры 1С, без конкретных запросов, конфигурации оборудования и настроек SQL Server можно долго гадать, но на самом деле умеренно прошаренные 1С-ники и DBA вполне могли уткнуться примерно в такие цифры (там где-то 126 мс на запрос в статье фигурировало по конкретной строке и 15 мс у тарантула).
Запрос по остаткам, если не приложить особых усилий, это соединение 3 таблиц (справочник с фильтром, остатки и движения). Если действовать по рекомендациям 1С (т.е. фильтр по справочнику в параметрах виртуальной таблицы), то четырёх (фильтр отдельно джойнится к остаткам и движениям). Но MS SQL отлично (лучше других СУБД, применимых к 1С) умеет прокидывать фильтр в отдельные таблицы подзапроса.
В любом случае без дополнительных приседаний это в SQL будет что-то типа
(это очень упрощённо! И если писать "как рекомендует 1С", то джойны будут к Reg и RegTotals — так SQL Server работает хуже в данном кейсе)
А каждое изменение остатков это изменение конечного остатка в RegTotals и движений в Reg (и, если обмен данными, то ещё регистрация изменений)
Дальше можно заставить 1С:
Тогда запрос станет примерно таким:
Но кроме банальных планов запросов и индексов там надо ещё смотреть:
Короче, там много всего еще надо посмотреть. 15 мс в тарантуле это в общем-то тоже дофига.
Так это простое следствие теории игр. Не имеет смысла ставить оценки в системе, кроме лучшей и худшей. Пусть у нас есть большое количество голосующих N и 10-бальная шкала. Пусть сейчас оценка Х. Голосующий считает, что справедливая оценка Y. Если он поставит Y, то приблизит оценку на величину порядка
abs((X-Y)/N). Если он поставит экстремальную оценку, то приблизит гораздо сильнее. Шах и мат.Кстати, про выдержку и ночную съёмку. Для северного сияния не очень критично (потому что чаще холодно), но всё же. Длинная выдержка -> нагрев матрицы -> больше шумов. Если выдержка уходит за 10 с, то это может быть уже важно. Тогда либо сознательно недоэкспонировать и тянуть (прощай детализация цветов и динамический диапазон), либо повысить ISO (но часто результат почти идентичен предыдущему). Или активно охлаждать тушку между кадрами. Ну или срочно сбегать в магазин и купить фотоаппарат с лучшей чувствительностью (ага, зимой в 3 ночи в поле, где поменьше засветки).
Продвинутый уровень:
Ф. Брукс еще 40+ лет назад сказал, что с тем же (и даже большим) успехом можно и нанять. А то вдруг без половины разработчиков станет проще и быстрее согласовывать и писать. А если нанять ещё 2n программистов, то можно и себе денег больше попросить, и программистов постоянно укорять: "сколько же вас надо нанять, чтобы хоть что-то делалось".
А важную информацию, наоборот надо обсуждать только в ветвящейся переписке с постоянно меняемым списком адресатов.
Это работает только с джунами. Опытный знает, что он допускает баги. И даже уже гордится некоторыми. Продуктивнее запрещать элементы TDD и максимально усложнить процесс регистрации багов (KPI по количеству, согласование с QA на заведение багов, массовое внесение инцидентов, как багов — тут много приёмов)
На нынешнем рынке труда — слишком одноразовый приём. Лучше намекать на премию, но не платить. Главное — премия должна быть максимально непредсказуемой.
С тем же успехом — как можно длиннее. Круто кинуть в разработчика 400-страничной спекой: "Оцени наши доработки в проекте". Наши доработки — это изменение XML схемы, которое следует из требований одного абзаца на странице 324.
С тем же успехом можно менять стек каждые полгода-год.
Рекомендации очень аккуратные, систематичные, детальные и разумные, фотки классные. Фотографией занимаюсь 30+ лет, поэтому нового для себя в части техники фото не открыл, но оценил, а в части ссылок на тематические и вспомогательные ресурсы — сокровищница.
Вроде как и знал всё это, и deflate реализовывал из любопытства, а всё равно прочитал на одном дыхании.
Я одновременно согласен с вами — у вас весьма аккуратные формулировки "невероятная сложность изменений и вывода новых методов лечения и препаратов", "Скорость вывода инноваций в ИТ несоизмеримо больше, чем в медицине, цена риска (...) ниже" и "Каждый подход имеет свои ограничений и хорош для своей области". Это всё так. Но есть момент, в котором хочу возразить.
Медицина очень консервативна. Это в определённой мере так. От идеи до врача проходит немало времени, особенно в методах лечения и выводе новых препаратов. Но на самом деле медицина быстро меняется. Не в смысле, что меняется скорость внедрения, а в том смысле, что диагностика, методы лечения и препараты очень быстро меняются. На уровне условного "участкового терапевта" это не так заметно, но все специализированные и технологичные направления меняются очень быстро. В диагностике МРТ, анализ ДНК ещё лет 10 назад были в целом экзотикой. Сейчас это мейнстрим. Стали применяться технологии ИТ для обработки данных в несравнимом объёме. Офтальмологическая хирургия, ЭКО, лечение опухолей, протезирование конечностей, нейрохирургия — всё это тоже за 10-15 лет тоже изменилось очень существенно. Да, в диагностике изменения быстрее, чем лечении — для диагностики обычно проще убедиться, что она безопасна. В программировании, за исключением нескольких областей (типа веб-фреймворки, облачные технологии, да всякие "блокчейны"), скорость прогресса сопоставима, если не меньше. А в проектировании реляционных БД вообще можно смело брать книгу Дейта 20-летней давности.
Да, у нас, в ИТ есть возможность попробовать новые технологии хоть вчера придуманные в прямо проме (только чувакам из core banking processing этот секрет не говорите :) ) — это так. Не везде, но можно. У медиков так не получится. Но это latency. А вот throughput изменений в целом вполне сопоставим. И устаревают у них, у медиков, знания — только в путь (регуляторно обязательные обучения не на пустом месте возникли).
Тяжеловато читается (как ни странно, оригинал читается проще, хотя и тоже стена текста). Но спасибо за интересный перевод.
Интересно, что 1С с списками в экранных формах работает именно так — не через
offset, а черезtop N where "записи ниже последней". Это и по причинам прозводительности и по причинам того, что 1С работает с 5 разными СУБД (часто используется общий функциональный минимум).При этом, кстати, корректно обрабатывается сортировка по нескольким полям при том что первые поля (и комбинации левого "подкортежа" сортировки) не являются уникальными. Там, правда, нюанс — "корректно" не всегда значит "эффективно" — в некоторых пограничных случаях идёт жёсткий пролёт мимо удачного плана, к счастью, это достаточно редкие случаи, которых можно/нужно избегать (а в SQL Server 2005 c SP до четвёртого приводил к падению SQL Server, но это именно бага SQL Server).
В MS SQL часто по подходящему уникальному полю есть кластеризованный индекс, а значит его значения есть в каждом некластеризованном. В этом случае на самом деле индекс (sort_column) и (sort_column, unique_column) на уровне движка БД тупо одинаковый.
PS: Для Oracle и PostgeSQL это не так.
А бывает наоборот. Я как-то несколько лет назад находил багу в .NET, когда неудачный алгоритм инлайна в релизном режиме приводил к экспоненциально долгому и также экспоненциально прожорливому потреблению памяти JIT. Сейчас (после моего репорта в core, но проявлялось и в framework) багу уже пофиксили. Хотя, на мой взгляд и неидеально пофиксили, но всяко лучше, чем было.
Тут в другом дело. Я уже лет 15 убеждён, что 1С сделала ошибку, не сделав
Значпо умолчанию (как поступили авторы C# cref). По-хорошему почти-почти всё, кроме того, что явно модифицируется и отдаётся обратно должно бытьзнач.Я вот не определился, читерство это или нет :) Но в одном определился: ваш
КоннекторHTTP— крутейшая вещь. Спасибо за наводку, я, как архитектор уже начал обсуждение использование этой библиотеки у нас.Собственно, мне кажется, что это то, как должна была выглядеть работа с HTTP в платформе.
И написана прям добротно-добротно:
Не скажу, что это нельзя улучшить, но на пару уровней выше кода, который я вижу в среднем.
Знач, но потом понял, что то ли я не понимаю ваших принципов использованияЗнач, то ли они полуслучайные. Первый попавшийся примерРазбитьСтрокуПоСтроке(Знач Строка, Разделитель)— почему первый параметр сЗнач, а второй без?И вообще, README.md почти готовая статья на хабр. Ну как "почти" — процентов на 40-60, но это самые важные проценты — скелет и мясо статьи. Не хватает по сути только описания контекста, в котором возникла задача и почему именно так решена, плюс какие-то нюансы поясняющие. Добейте, опубликуйте. Я штук 3-5 голосов-плюсиков точно подгоню, если кинете ссылку (да и EvilBeaver, думаю тоже).
C, C++, C#, Java, Python, Rust, Go (и ещё несколько сотен языков)
В 1С методы работы с чтением двоичных данных (которые появились в 8.3.9-8.3.10 в 2016 и 2017 годах — совершенно недавно по энтерпрайз меркам) предоставляют весьма низкоуровневые возможности: чтение примитивных числовых и строковых данных. Нет удобных инструментов чтения сразу в структуры данных. Да что там! Даже банально float прочитать — уже изголяться. Да что там float! Даже отдельных методов для знаковых/беззнаковых нет.
А так как с модульностью и переиспользованием кода в 1С задница и юнит-тесты писать заколебёшься, то даже относительно простые потоки данных читать — боль-боль-боль.
Я не говорю "не хватает". Я говорю "низкоуровневые". То есть сделать можно всё, как можно всё написать на ассемблере. Теоретически — да. Практически даже обращение к простому сервису с аутентификацией и последующий разбор результатов это какие-то невменяемые портянки кода по сравнению, например, с JS. В качестве примера попробуйте какой-нибудь список тикетов из Jira или GitLab по фильтру вытащить, только по-честному с правильной не-basic аутентификацией, без хранения пароля пользователя.
Вроде и делается всё, но уж так это многословно.
Ну сравните с Python — там сам интерпретатор такой же "Однопоточный синхронный медленный". Асинхронность и быстрость снаружи интерпретатора.
И у Python тоже! :) тот же самый refcount (о, кстати, в Kotlin Native, если ничего за год не изменилось — тоже).
Привет вселенной розовых пони! В нашей вселенной во всех российских банках в Java-коде и в базах данных творится совершенно другое. Там идентификаторы в лучшем случае через гугл-транслейт написаны. Плюс ещё терминология бизнеса не совпадает с обратным переводом. И именно поэтому в банках трудятся тысячи аналитиков — если по-честному, то половина их работы разбараться в этой мешанине из идентификаторов.
Потому что механизмы убогие и начинаются не там. Нахера, извините, сценарное тестирование форм, когда нет модульных и интеграционных тестов? А их нет, потому что модульность не завезли, DI не завезли, мокать невозможно, в IDE поддержки нет.