Я видел достаточное количество производственных версий Python, чтобы знать, что самая большая проблема с языком заключается не в языке. Дело в том, что Python слишком хорош для 90% людей, которые зарабатывают на жизнь написанием кода. Я годами слушал скептиков и противников Дебби, но продолжаю видеть, как хулители Python снова и снова приводят одни и те же избитые аргументы. Обычно какой-то бессмысленный комментарий о синтаксисе пробелов или утиной печати. Как программист Python, я верю, что у языка есть обоснованные опасения, но моя точка зрения такова, что сообщество программистов больше озабочено близорукими спорами об относительных проблемах, чем об эффективном использовании языка.

Когда вы спрашиваете заядлого ненавистника Python, какой язык, по их мнению, лучше, вы, как правило, сталкиваетесь с самыми заурядными ответами: C, C++, Java. Иногда праведный фанатик из храма функционального программирования ответит какой-нибудь разновидностью ML или Haskell, или какой-нибудь объектно-ориентированный пуританин воспользуется этим как возможностью проповедовать элегантность SmallTalk. Независимо от того, какие языки разработчики считают «лучшими», аргументы, как правило, в лучшем случае расплывчаты и обычно сводятся к одному: Python не «язык_я_уже_знаю». Причина, по которой разработчики предпочитают такие языки, достаточно проста: все эти языки более строгие, чем Python. Программистам нравятся ограничительные языки, потому что их подходы с одной парадигмой поддаются набору идеологически обоснованных передовых практик, к которым разработчики могут легко вернуться. Функции этих языков были разработаны (в основном) с одной парадигмой (я видел функциональную Java в производстве, и это не очень приятное зрелище). В этих языках, которые более четко соответствуют единому видению, разработчик избавлен от мучений, связанных с размышлениями о том, что именно является лучшей практикой, и больше времени может быть использовано для написания кода; идиомы языка и парадигмы направляют процесс, а не вдумчивое намерение.

PEP8 может решить проблему стандартизации формата, но на самом деле он ничего не может сделать для решения более крупной проблемы Python: обычно существует множество кратких способов сделать любую конкретную вещь. Гибкость решений поразительна, если у разработчиков действительно есть возможность проявлять сдержанность и последовательно выбирать хорошо продуманные решения проблем, но основная проблема здесь заключается в том, что разработчики не обучены выбирать хорошие решения проблем, с которыми они сталкиваются: они обучены реализовывать решения проблем, которые уже были решены. Это усугубляется мультипарадигмой Python: вместо того, чтобы кодовые базы Python представляли собой элегантную смесь ООП, функционального и императивного подходов, большинство проектов превращаются в некую бестолковую попытку заставить Python вести себя в точности как Haskell, или точно как C, или точно как Java. Похоже, что многие разработчики скорее предпочтут ограничительно злоупотреблять Python до такой степени, что он начнет напоминать другой, более знакомый язык, чем на самом деле сесть и подумать о прагматике кода, который они пишут.

Вся эта проблема привела к тому, что сообщество Python создало одно из самых неприятных слов, когда-либо приносивших несчастье английскому языку: Pythonic. Не то чтобы я думал, что великий Python не может существовать: он определенно может существовать. Точно так же я не верю, что совершенный код существует только как некий платоновский метафизический идеал. Я действительно думаю, что то, что разработчики часто называют Pythonic, обычно больше вредит качеству, чем приносит пользу. Идея кода Pythonic обычно представляется как некая попытка систематизировать прагматическое использование языка: таким образом область применения Pythonic выходит далеко за рамки C- как или подобно Java. Структура, с помощью которой люди решают, хорош ли код Python, больше связана с прагматикой удобочитаемости, простоты и туманной концепции элегантности. Между тем, код, написанный на C, обычно оценивается по более объективным показателям, таким как эффективность, модульность и, в некоторых случаях, безопасность. Это позволило тем, кто пишет на C, быстро и эффективно достичь консенсуса относительно того, что делает код хорошим, в то время как те, кто пишет на Python, обречены на бесконечные споры о гораздо более субъективных проблемах.

Причина, по которой люди не любят Python, не в том, что Python плохой. Потому что программисты плохие. Похоже, они забыли, что программирование не всегда заключается в том, чтобы всегда следовать блок-схеме лучших практик, поскольку, если бы все было так просто, в первую очередь не было бы особой потребности в компетентных программистах. Сообщество программистов в значительной степени не смогло осознать, что наличие языка, разжигающего споры о прагматике, на самом деле является большим шагом вперед для программирования в целом. Полезно спорить о более абстрактных и расплывчатых концепциях, которые Python выводит на поверхность; или, может быть, было бы неплохо провести еще 50 лет, споря о том, хорош ли синтаксис пробелов?