Всё чаще наблюдаю такую закономерность: люди, любящие IDE и мощные отладчики, производят самый адов говноокод. А самый чистый код у тех, кто пользуется отладочной печатью, логами и тестами. ЛОР, а ты что думаешь? Допустимо ли debugger-driven development?
Цоперайт © 2010-2016 @stiletto.
@heroin я это прочитал как намёк комара, что если ты пользуешься таким языком[/компилятором/инфраструктурой/экосистемой...], который вместо предотвращения ошибок их автоматически выявляет — то это плохие новости (потому что в общем это удлиняет feedback loop при разработке, и ты кодишь в целом медленнее и менее коректно).
По факту, учитывая отстойность и немощность многих и многих линтеров, я с этим даже соглашусь. У них крайне поверхностный анализ; плохо сделано. Но.
В теории, есть возражение. Верифицировать и перепроверять код программиста — не единственный юзкейс и назначение компиляторов. Им ещё нужно, все-таки, делать кодген (будь то нативные байтики, или байткод — похуй). Причём быстро.
А многие виды (алгоритмы) статического анализа несовместимы с «генерировать код быстро». Пример: тот же data flow analysis, помогающий находить/проверять NPE (Null Pointer Exception) в языках с универсальным
nil(где любой юзерский тип ∈Nullable) без ADT и патерн-матчинга — такой анализ NP-полон. Значит, очень легко даже ненарочно написать такой код, где этот анализ работает очень медленно. Такое просто нельзя делать в компиляторе. Даже если рассуждать в модальной логике со статистическими кванторами «скорее всего»/«в 95% случаев»/этц.Поэтому, в теории, статический анализ необходим как класс софта (чтобы удовлетворять запросы тех, кого устраивает крайняя позиция трейдоффа «скорость сборки ↔ глубина анализа корректности кода»). Но, на практике, все эти линтеры — адов шлак, и лучше бы язык просто не позволял писать хуйню изначально.
@komar попизди мне тут сука, я мысль передать хочу — а комар выебывается
я хочу передать другую мысль — а комар снова выебывается. Вот нахуй так жить?