Важно ли меньше букв в коде

Одна из скучных (об этом отдельное эссе, пожалуй) тем для споров — “язык X лучше языка Y потому, что меньше букв писать”. Обычно это Java (много букв) vs Python (мало букв). Давайте подумаем о том, насколько это важно.

Во-первых, это важно не программе и не пользователю, но разработчику. От того, что ваш код вдвое меньше, приложение не становится быстрее или удобнее. Потому сразу надо брать этот пункт в фон и постоянно держать, всякий раз обрубая поползновения объём кода переместить в другую плоскость.
Во-вторых, это субъективно. Вася с трудом осиливает ленту из десяти твитов за сутки, Петя за час пролистывает любой том БСЭ. Безусловно, есть какая-то граница, за которой слишком много букв уже для любого разработчика, да и в целом таки хочется меньше рутины, но насколько это действительно напрягает и проблема — оно таки от Петь и Вась зависит.
В-третьих, IDE. Если вы фигачите код в vim’е, который ещё и не настроили, кажется очевидной и огромной разницей разница между вашим отношением к объёму кода и отношением к оному бойца, у которого какая-нибудь IntelliJ IDEA, да ещё и с заточкой под конкретные руки. Все эти скобочки, переносы, ключевые слова и длинные имена исключений — они давно уже автоматически или из всплывашек долбятся. Субъективно мне кажется, что целиком я не набираю и половину Java-кода.
В-четвёртых, снова IDE. Исходный код — это давно уже не портянка, которую читать от первой строки до последней. Это граф из функций и данных. Современные IDE умеют помогать читателю бегать из узла в узел, подкрашивают, схлопывают, расхлопывают, а иногда ещё и картиночки генерируют для особо упоротых случаев. Когда вы видите на GitHub’е 1000’строчное полотно Java-кода… короче, в IDE это выглядит не так. И изучение чужого исходника у вас будет выглядеть иначе. При этом гораздо бОльшую роль будут играть имена, типы и прозрачность кода, а не его количество (крайний случай лаконичности — regular expression на половину экрана, очень понятно и клёво?).
В-пятых, а какую долю рабочего времени у вас занимает набор кода? Ну правда. Приходит задача. Обсуждается. Осмысляется. Чертится на бумажках. Исследуются библиотеки, если надо. Читается и пробуется документация / учебники. Пишутся какие-то наброски. Потом первый пристрелочный код. Если понятная текучка, то сразу что-нибудь исправляется. Если непонятная, то читаются логи. И вот во всей этой чехарде физический набор исходника занимает… ну… блин. У меня в лучшем случае 20% (с потолка) времени от общего времени задачи. Также в процессе написания думаю о том, что писать-то конкретно. В итоге сам набор ещё меньше.

В общем… если сравнивать языки по этому показателю, то после того, как всё остальное взвесили. Фишка тут в том, что всё остальное сознательно можно взвесить токмо при годном знании матчасти.
Сборка мусора, работа с памятью, многопоточность, оптимальность стандартных библиотек, скорострельность интерпретации, всё такое. Тут-то как-то спорщикам скучно становится. Мало того, что действительно надо знать, что и как работает, так ещё и доказать собеседнику, что это работает плохо или неправильно, да ещё и в каких-нибудь условиях. И доказывать не “бабушкой клянусь!” и не “я в 1917 году семь ошибок сделал из-за этого! я! Карл! семь!”, конечно же.
Синтаксис? В вопросах синтаксиса, знаете ли, субъективное Васино “фу, пакость какая” тоже не особо рулит, если нужен серьёзный конструктивный разговор. Примеры таких разговоров (хоть в какой степени) вот тут, например: Swift Programming Language Evolution
Если посмотреть на процесс зрелого (на уровне комитетов и острых переписок во всяких изданиях ACM) суждения про языки… послушайте, размер исходника вообще никого не волнует. Разве что на заре сетей задумывались глубоко о том, хватит ли каналов для передачи того и сего. А нынче не задумываются.
Хорошо бы и нам как-то из этого выйти.

Добавить комментарий