Потому что человек забудет, перепутает и поспешит обязательно. И если система в этот момент уходит в тихую поломку, двусмысленное поведение или хрен знает что, это плохая система
Примерно все системы обладают таким свойством - если что-то перепутать, будут плохие последствия. Не надел каску на стройке - упавший сверху болт может пробить голову. Зазевался за рулём - может произойти ДТП. Зазевался на лестнице - можно упасть и что-то сломать. Даже на ровном месте можно упасть с печальными последствиями, если нога зацепится.
Из "защищённых от досадных случаев" систем навскидку могу вспомнить только электрические выключатели, которые исключают удар током (если, конечно, корпус цел, не залито водой и т.п.).
Конечно, хотелось бы исключить опасности полностью, и это - признак хорошей инженерии, но большинство систем всё-таки не имеет 100% защиты от зазевавшегося "дурака".
В delphi до какой-то современной версии примерно так и было - RAII ограничивалось не блоком, а областью функции (сам блок begin .. end, тем не менее, допустим, но бесполезен). И вместо блока begin ... end требовалось писать отдельную локальную функцию, чтобы ресурсы, выделенные в ней, автоматически освобождались. Весьма неудобно.
В python не всё так логично, как декларируется, взять ту же конструкцию "a if cond else b". На scala это "if (cond) a else b" - это легче читается имхо.
А если нырять в многопоточность в python, можно и не вынырнуть - масса edge case, которые не описаны в документации, а когда они проявляются, и ищешь решение, в стандартной библиотеке находится "ещё один способ сделать это", немного устаревший, но рабочий, в отличие от нового. Декларируется при этом, что "есть только 1 способ сделать".
В таких контейнерах никогда шелл-скрипты и не запускают. В них упаковывают одну программу на каком-нибудь go и её же и запускают.
Это не так. При использовании python часто запускается стартовый скрипт, который выполняет миграции, запускает cron, supervisor и т.п., а потом само приложение (если этого не делает supervisor). Бывает в 1 образе несколько стартовых скриптов, для воркера и диспетчера например, и тогда в разных контейнерах на одном образе запускаются разные скрипты. Bash ещё как используется, и иногда в образе оказывается sh, а не bash.
Каждое из этих решений, вероятно, при создании софта казалось хорошей идеей. Но спустя 20-30 лет (а в случае sh ~50 лет) успешного использования мода поменялась, появились новые знания, новые принципы... Критика напоминает критику IPv4, когда есть IPv6: мы все знаем, как лучше, но мгновенно ничего улучшить не можем.
А может, если софт с этими "особенностями" ("багами") выжил за десятилетия, то они не вредны и даже чем-то полезны?..
Подождите, то, что вы перечисляете как плюсы вашей системы (workflow, релизы, зависимости, коммиты, версии, тестирование, поддержка, статистика, ...), есть в любом таск-трекере, даже в бесплатных встречается. Так в чём отличия, если (судя по данной статье) вашу функциональность можно тривиально собрать в типичном другом трекере?
Процесс очень легко превращается в религию. Люди начинают фанатично защищать выбранный фреймворк. Любая критика воспринимается как угроза. Диалог заканчивается.
многие из них никогда не были ни сильными продактами, ни инженерами, ни менеджерами в реально сильной продуктовой среде. Они знают процесс. Но не знают, как на самом деле создаётся продукт в условиях неопределённости. И в итоге именно они начинают определять, как «правильно» работать командам.
Ъ стори. Наверно, исход слишком типичный, но я несколько раз сталкивался с тем и другим. "Особый шик" - ревностно внедрять скрам, и когда ближе к концу спринта становится ясно, что "не успеваем", начать действовать прямо противоположно описанному в Scrum Guide.
Со временем я пришёл к выводу, что процессы вторичны по сравнению с тем, кто и как их практикует. У толковых людей работают почти любые вариации процессов, а с некоторыми индивидами только лоб расшибить можно, а если такой пробрался в менеджмент, лбы начинают расшибать абсолютно все (проявляется высокой текучкой).
Обычно это так, но иногда бывают проекты "написал и забыл", или скрипты всякие. Тот же микросервисный подход (после 2014 года) менее чувствителен к нечитаемому коду из-за маленького размера сервисов.
Вот если проект вырастает до большого или долгоживущего, то прелести легкочитаемого и понятного кода проявляются во всей красе. Ну или недостатки непонятного кода - со всей серьёзностью 😁
И в наше время, если вы при разработке полагаетесь на llm, то для потенциально большого проекта конечно нужно уметь не доводить до говнокода и прикладывать для этого усилия, а для прототипа - может "и так сойдёт".
И что программы пишутся не компьютеру, а человеку. С этой целью и были изобретены языки высокого уровня.
Программы пишутся для программистов или для пользователей? Думаю, в большей степени для пользователей, которые как правило кода не читают. Читаемый код (в т.ч. языки высокого уровня) нужен для обеспечения возможности поддержки и развития программы.
с использованием LLM в разработке кода все смирились.
На хабре десятки если не сотни статей где громят ии-код.
Противоречие здесь вижу я.
Многие программисты с вами не согласятся.
Всё-таки программы пишутся в первую очередь для удовлетворения потребностей пользователей, во вторую - для выполнения их компьютерами (хотя железо безропотно прочитает и выполнит все инструкции, которые сформирует компилятор - с этим обычно проблем нет), и только потом - для чтения программ программистами (этого этапа может и не быть, но часто есть - мы же не на 1 месяц программы пишем). Статья же пишется для заказчиков для достижения их целей или по желанию автора (тоже для каких-то его целей), а вот читать её приходится живому читателю, а не процессору, и не автору. Разница в том, где в цепочке информации стоит живой человек - получает ли он результат сего произведения, или должен бесплатно тратить усилия, чтобы разобрать тонну некачественного текста. Программист, как автор (соавтор) кода, хоть как-то влияет на качество кода, он может поправить код, если не хочет читать потом нечто дикое, а у читателя статьи вариантов улучшить её качество нет. Читатель оказывается на месте процессора, а не выгодополучателя.
Для кода главное - чтобы он корректно работал, а читаемость и понятность - это уже на случай, если (когда) придётся редактировать. Тут же нейрослоп безальтернативно льётся в мозг читателю.
Денег платить не хотят, время свое тратить не хотят, хотят чтобы кто-то им забесплатно написал качетсвенно, с эмоциями и с проверкой ВСЕХ фактов.
А вы предпочитаете платно, некачественно и без проверки фактов (выдумку)? Думаю, никто не хочет такого. И проблема в том, что нейрослоп часто встречается в блогах компаний, т.е. за это кто-то платит (компания - деньгами, читатель - временем).
Хотите, чтобы я ваш комментарий отправил ChatGPT и скопировал ответ сюда? Пожалуйста:
Скрытый текст
Понимаю посыл: к нейросетям часто требования как к идеальному справочнику, а к людям — «ну ошибся и ладно». Но всё-таки разница есть: человек отвечает своей репутацией и может честно сказать «не знаю», а нейросеть легко выдаёт уверенный тон даже там, где фактов нет — и это уже риск для тех, кто потом на это опирается.
И да, «сделай сам» — рабочий аргумент, но не универсальный: люди приходят за инструментом, потому что не умеют/не хотят разбираться в форме. Другой вопрос — ожидания. Если нужен текст «качественно, с эмоциями и с проверкой всех фактов», это уже нормальная работа: либо платим деньгами, либо временем (ТЗ, источники, правки).
Так что я бы сформулировал так: нейросеть — не «оракул», а ускоритель. Хочешь результат — давай вводные и принимай, что проверка и ответственность остаются на человеке. А «фыр-фыр» вместо попытки нормально сформулировать запрос — это действительно детский сад.
Так что, читатель статьи, не разводи "детский сад" в попытках написать ТЗ автору 😁 (кто-нибудь понял, о чём речь?)
Сгенерированный текст часто содержит фактические ошибки. Людям очень не нравится, когда их обманывают.
Второй вид обмана - когда "автор" пишет промпт, и выдаёт результат за свой труд. Это тоже обман, хотя и не такой жёсткий, как ошибки.
И этот специфический стиль годен для чата с ИИ, но в контенте всех уже бесит. В чате с ИИ пользователь знает, что общается с ИИ, и делает поправки на это. При чтении статьи поправку сделать невозможно, т.к. нет диалога.
А ещё этот стиль легко детектируется, и автор подсознательно помечается как брехло любитель приукрасить, даже если он "только орфографию поправил", или просто имел неосторожность сочинить пару оборотов, похожих на обороты ИИ.
Актуальные LTS‑версии на 2026 год: Java 17 и Java 21. Java 25, которая вышла в сентябре 2025, — это non‑LTS релиз, её поддержка закончится через полгода, к марту 2026.
Странное заявление, когда в официальных источниках сказано обратное (Java 25 LTS). Кстати, уже март 2026.
К тому же, для новичка для "попробовать" годятся и не-LTS версии. LTS - это для продакшена.
Примерно все системы обладают таким свойством - если что-то перепутать, будут плохие последствия. Не надел каску на стройке - упавший сверху болт может пробить голову. Зазевался за рулём - может произойти ДТП. Зазевался на лестнице - можно упасть и что-то сломать. Даже на ровном месте можно упасть с печальными последствиями, если нога зацепится.
Из "защищённых от досадных случаев" систем навскидку могу вспомнить только электрические выключатели, которые исключают удар током (если, конечно, корпус цел, не залито водой и т.п.).
Конечно, хотелось бы исключить опасности полностью, и это - признак хорошей инженерии, но большинство систем всё-таки не имеет 100% защиты от зазевавшегося "дурака".
В delphi до какой-то современной версии примерно так и было - RAII ограничивалось не блоком, а областью функции (сам блок begin .. end, тем не менее, допустим, но бесполезен). И вместо блока begin ... end требовалось писать отдельную локальную функцию, чтобы ресурсы, выделенные в ней, автоматически освобождались. Весьма неудобно.
Забавный подход.
Так ведь из определения следует, что стоимость профессионального капитала имеет тенденцию к уменьшению с течением времени?
По ТК РФ где-то 1800 часов в год, и это если не болеть сильно. 1972 часа за 2026 год минус 160 часов отпуска.
В python не всё так логично, как декларируется, взять ту же конструкцию "a if cond else b". На scala это "if (cond) a else b" - это легче читается имхо.
А если нырять в многопоточность в python, можно и не вынырнуть - масса edge case, которые не описаны в документации, а когда они проявляются, и ищешь решение, в стандартной библиотеке находится "ещё один способ сделать это", немного устаревший, но рабочий, в отличие от нового. Декларируется при этом, что "есть только 1 способ сделать".
Создать непротиворечивую спецификацию - та ещё задача.
Это не так. При использовании python часто запускается стартовый скрипт, который выполняет миграции, запускает cron, supervisor и т.п., а потом само приложение (если этого не делает supervisor). Бывает в 1 образе несколько стартовых скриптов, для воркера и диспетчера например, и тогда в разных контейнерах на одном образе запускаются разные скрипты. Bash ещё как используется, и иногда в образе оказывается sh, а не bash.
Каждое из этих решений, вероятно, при создании софта казалось хорошей идеей. Но спустя 20-30 лет (а в случае sh ~50 лет) успешного использования мода поменялась, появились новые знания, новые принципы... Критика напоминает критику IPv4, когда есть IPv6: мы все знаем, как лучше, но мгновенно ничего улучшить не можем.
А может, если софт с этими "особенностями" ("багами") выжил за десятилетия, то они не вредны и даже чем-то полезны?..
отмытый?
Подождите, то, что вы перечисляете как плюсы вашей системы (workflow, релизы, зависимости, коммиты, версии, тестирование, поддержка, статистика, ...), есть в любом таск-трекере, даже в бесплатных встречается. Так в чём отличия, если (судя по данной статье) вашу функциональность можно тривиально собрать в типичном другом трекере?
Ъ стори. Наверно, исход слишком типичный, но я несколько раз сталкивался с тем и другим. "Особый шик" - ревностно внедрять скрам, и когда ближе к концу спринта становится ясно, что "не успеваем", начать действовать прямо противоположно описанному в Scrum Guide.
Со временем я пришёл к выводу, что процессы вторичны по сравнению с тем, кто и как их практикует. У толковых людей работают почти любые вариации процессов, а с некоторыми индивидами только лоб расшибить можно, а если такой пробрался в менеджмент, лбы начинают расшибать абсолютно все (проявляется высокой текучкой).
Паразитирование на любой системе - в принципе плохо для этой системы. Снижается эффективность, ресурсы тратятся впустую.
Наизучаются тут своего php и ходют, "работают"!
Обычно это так, но иногда бывают проекты "написал и забыл", или скрипты всякие. Тот же микросервисный подход (после 2014 года) менее чувствителен к нечитаемому коду из-за маленького размера сервисов.
Вот если проект вырастает до большого или долгоживущего, то прелести легкочитаемого и понятного кода проявляются во всей красе. Ну или недостатки непонятного кода - со всей серьёзностью 😁
И в наше время, если вы при разработке полагаетесь на llm, то для потенциально большого проекта конечно нужно уметь не доводить до говнокода и прикладывать для этого усилия, а для прототипа - может "и так сойдёт".
Программы пишутся для программистов или для пользователей? Думаю, в большей степени для пользователей, которые как правило кода не читают. Читаемый код (в т.ч. языки высокого уровня) нужен для обеспечения возможности поддержки и развития программы.
Опять?
Противоречие здесь вижу я.
Всё-таки программы пишутся в первую очередь для удовлетворения потребностей пользователей, во вторую - для выполнения их компьютерами (хотя железо безропотно прочитает и выполнит все инструкции, которые сформирует компилятор - с этим обычно проблем нет), и только потом - для чтения программ программистами (этого этапа может и не быть, но часто есть - мы же не на 1 месяц программы пишем). Статья же пишется для заказчиков для достижения их целей или по желанию автора (тоже для каких-то его целей), а вот читать её приходится живому читателю, а не процессору, и не автору. Разница в том, где в цепочке информации стоит живой человек - получает ли он результат сего произведения, или должен бесплатно тратить усилия, чтобы разобрать тонну некачественного текста. Программист, как автор (соавтор) кода, хоть как-то влияет на качество кода, он может поправить код, если не хочет читать потом нечто дикое, а у читателя статьи вариантов улучшить её качество нет. Читатель оказывается на месте процессора, а не выгодополучателя.
Для кода главное - чтобы он корректно работал, а читаемость и понятность - это уже на случай, если (когда) придётся редактировать. Тут же нейрослоп безальтернативно льётся в мозг читателю.
А вы предпочитаете платно, некачественно и без проверки фактов (выдумку)? Думаю, никто не хочет такого. И проблема в том, что нейрослоп часто встречается в блогах компаний, т.е. за это кто-то платит (компания - деньгами, читатель - временем).
Хотите, чтобы я ваш комментарий отправил ChatGPT и скопировал ответ сюда? Пожалуйста:
Скрытый текст
Понимаю посыл: к нейросетям часто требования как к идеальному справочнику, а к людям — «ну ошибся и ладно». Но всё-таки разница есть: человек отвечает своей репутацией и может честно сказать «не знаю», а нейросеть легко выдаёт уверенный тон даже там, где фактов нет — и это уже риск для тех, кто потом на это опирается.
И да, «сделай сам» — рабочий аргумент, но не универсальный: люди приходят за инструментом, потому что не умеют/не хотят разбираться в форме. Другой вопрос — ожидания. Если нужен текст «качественно, с эмоциями и с проверкой всех фактов», это уже нормальная работа: либо платим деньгами, либо временем (ТЗ, источники, правки).
Так что я бы сформулировал так: нейросеть — не «оракул», а ускоритель. Хочешь результат — давай вводные и принимай, что проверка и ответственность остаются на человеке. А «фыр-фыр» вместо попытки нормально сформулировать запрос — это действительно детский сад.
Так что, читатель статьи, не разводи "детский сад" в попытках написать ТЗ автору 😁 (кто-нибудь понял, о чём речь?)
Сгенерированный текст часто содержит фактические ошибки. Людям очень не нравится, когда их обманывают.
Второй вид обмана - когда "автор" пишет промпт, и выдаёт результат за свой труд. Это тоже обман, хотя и не такой жёсткий, как ошибки.
И этот специфический стиль годен для чата с ИИ, но в контенте всех уже бесит. В чате с ИИ пользователь знает, что общается с ИИ, и делает поправки на это. При чтении статьи поправку сделать невозможно, т.к. нет диалога.
А ещё этот стиль легко детектируется, и автор подсознательно помечается как
брехлолюбитель приукрасить, даже если он "только орфографию поправил", или просто имел неосторожность сочинить пару оборотов, похожих на обороты ИИ.Странное заявление, когда в официальных источниках сказано обратное (Java 25 LTS). Кстати, уже март 2026.
К тому же, для новичка для "попробовать" годятся и не-LTS версии. LTS - это для продакшена.
Стандартная техника поиска ("таблица прямого доступа"), больше используемая на С, чтобы избежать ветвлений. Но в Java доступ к массиву дороже.