Привет! Представляю вашему вниманию перевод статьи «Your statement is 100% correct but misses the entire point».
Представьте, что где-то в Интернете обсуждают языки программирования. Один из архитектурных вопросов, который могут обсуждать, это сборщик мусора. Один участник дискуссии упоминает преимущества сборки мусора как-то так:
Сборщики мусора классные и экономят много сил. Если у вашего приложения нет строгих требований к времени отклика, то отсутствие необходимости заботиться об управлении памятью освобождает разработчика и может значительно повысить его эффективноcть.
Это довольно нейтральное утверждение, с которым согласилось бы большинство людей, даже если бы они работали над кодом, к которому предъявляются строгие требования ко времени отклика. И все же, неизбежно кто-то представит такой контраргумент:
Нет! Если у вас есть висячие указатели, то память никогда не освободится и вам в любом случае придется исправлять это, выполняя ручное управление памятью. Сборщики мусора волшебным образом не исправляют все ошибки.
Если вы внимательно прочитаете эти предложения, то заметите, что каждое утверждение в них является правдой. Вот почему так неприятно это оспаривать. Большинство людей с инженерным образованием в целом готовы признать свои ошибки, когда им предъявляют доказательства того, что их утверждения неверны. Это, конечно, не распространяется на всех, поскольку некоторые люди готовы намеренно не соглашаться с любыми фактами, которые противоречат их предубеждениям. Мы проигнорируем таких людей в этой статье.
Будучи правдой, эти утверждения игнорируют весь более широкий контекст вопроса, в котором содержатся следующие моменты:
- висячие указатели в программе — это редкость (может быть, в 1 из 10 программ?), в то время как обычные ошибки с памятью, такие как использование указателя после его освобождения, двойное освобождение, ошибка неучтённой единицы и т. д. — это очень частое явление (100-1000 в каждой программе);
- современные сборщики мусора имеют очень хорошие профилировщики, найти висячие указатели гораздо проще, чем отлаживать повреждения стека;
- возможность создавать объекты одним щелчком пальца и просто забывать о них делает разработчиков намного продуктивнее, чем требование от них скрупулезно управлять полным жизненным циклом каждого ресурса в отдельности;
- даже если вы столкнетесь с проблемой висячих указателей, то её решение, вероятно, займет меньше времени, чем решение проблемы повреждения памяти в таком же приложении, но без сборщика мусора.
Вкратце, аргументы фактически правильны, но они упускают всю суть комментария, на который они отвечают. Это, к сожалению, часто встречается в обсуждениях в Интернете. Давайте посмотрим несколько примеров.
Компьютерная безопасность
Такое утверждение:
Использование HTTPS для всего трафика полезно для безопасности и анонимности.
можно контраргументировать, например, так:
Это не обеспечивает никакой реальной безопасности, если АНБ захочет получить ваши данные, то они ворвутся в вашу квартиру и получат их.
Опять же, это утверждение абсолютно верно. С другой стороны, если вы не являетесь лидером государства или не имеете дело с международными наркокартелями, вы вряд ли станете прямой мишенью АНБ.
Если вы думаете, что это глупый контраргумент, который никто никогда не сделает, то я полностью с вами согласен. Я также видел, как его использовали в реальном мире. Хотел бы я этого не видеть.
Ошибки вызваны некомпетентностью
Языки программирования высокого уровня удобны в использовании:
Языки программирования, защищающие от переполнения буфера, отлично подходят для разработки с точки зрения безопасности и простоты.
Но не для всех:
Вы можете достичь того же самого в Си, просто будьте осторожны.
Это снова правда. Если каждый разработчик, работая над кодовой базой, будет на 100% сконцентрирован и на 100% осторожен 100% времени, то написание безошибочного кода возможно. Реальность снова и снова показывала, что это невозможно, человек просто не способен безупречно работать в течение длительного времени.
YAGNI? Какой еще YAGNI?
Всё просто:
Обработка текстовых файлов с помощью Python — это действительно здорово и просто.
И не так просто:
Python — это полная ерунда, он не справится с задачей, когда вам нужно будет обрабатывать десять миллионов файлов в секунду на встроенном микроконтроллере, используя максимум 2 KB оперативной памяти.
Да. Да, это так. В таком случае, это был бы неправильный выбор. Вы абсолютно правы. Спасибо за вашу проницательность, добрый сэр, вот блестящая золотая медаль в память о вашем важном вкладе в эту дискуссию.
Что может быть причиной этого?
Единственное, к чему вас готовит школа, это то, что важно быть правым. Если вы дадите правильные ответы в тесте, то получите хорошую оценку. А если не дадите — плохую. Может быть, это «прилипает» после того, как вы закончите школу, особенно если учесть, что большинство людей, которые размещают такого рода комментарии, кажется, находятся на «более умном» конце спектра (личное мнение, не основанное на каком-либо фактическом исследовании). В реальном мире быть правым, само по себе, не является заслугой. Конечно, в любых дискуссиях быть правым важно, но гораздо более важная черта — это быть уместным. Это требует понимания более широкого контекста и, возможно, признания того, что то, что является самым важным в мире для вас лично, может быть совершенно неактуальным для рассматриваемого вопроса.
Быть правым легко. Быть релевантным чрезвычайно трудно.
Автор: hjarvard
