Возможно, ваш опыт работы с C ++ (и, следовательно, ваши сверстники) затуманивает ваше восприятие этого (то есть выборочной выборки), но, по моему опыту, реакция на мем «пустое пространство - намерение» в Python где угодно - от амбивалентной до им абсолютно нравится . Причина, по которой он нравится многим, заключается в том, что он заставляет людей форматировать свой код.
Я не могу сказать, что когда-либо встречал кого-нибудь, кто «ненавидит» это, потому что ненавидеть это очень похоже на ненависть к идее хорошо отформатированного кода.
Редактировать: позвольте мне взглянуть на это в некоторой перспективе.
В мире Java существует два основных метода упаковки и развертывания веб-приложений: Ant и Maven.
Ant - это, по сути, средство Make на основе XML, у которого есть задачи для обычных вещей, которые вы делаете. Это чистый лист, что очень важно, но это также означает, что вы должны сами написать много общих вещей, и каждая установка может делать что-то немного по-другому. Все это сделано из лучших побуждений, но может затруднить понимание чьих-либо сценариев Ant.
Maven имеет гораздо более широкие возможности. У него есть архетипы, которые в основном являются типами проектов. В зависимости от того, какой архетип (ы) вы используете, вам не нужно будет писать какие-либо задачи для запуска, остановки, очистки, сборки и т. Д., Но у вас будет обязательная структура каталогов, которая является довольно глубокой.
Преимущество этого в том, что если вы видели одно веб-приложение Maven, вы видели их все. Вы знаете команды. Вы знаете структуру. Это чрезвычайно полезно.
Но есть люди, которые абсолютно ненавидят Maven, и я думаю, что все сводится к следующему: им не нравится отказываться от контроля, даже когда это в конечном итоге в их интересах.Кроме того, вы найдете людей определенной категории, которые думают, что их вариант использования является оправданным исключением. Вы часто видите эту черту характера. Например, я думаю, что в старом сообщении Джоэла упоминалась история, в которой кто-то хотел использовать "ввод" для перехода от имени пользователя к полям формы пароля, хотя соглашение заключалось в том, что ввод выполнял действие по умолчанию (обычно "ОК"), поэтому им пришлось напишите для этого специальный класс диалога для Windows.
В основном некоторые люди просто не любят, когда им говорят, что им делать, а другие совершенно упрямы в своей вере в свою правоту, даже когда все свидетельства указывают на обратное.
Это, вероятно, объясняет, почему некоторые якобы ненавидят пустое пространство Python: им не нравится, когда им говорят, как форматировать их код. Им нравится свобода C / C ++.
Существует несколько различных типов пробелов (пробелы, табуляции, странные символы Юникода, возврат каретки, разрывы строк и т. Д.), Они не обязательно визуально различимы, а языки и редакторы могут относиться к ним капризно. Это не аргумент против хорошо спроектированной семантики пробелов, но многие люди против всех ее форм просто из-за возможности плохого дизайна.
У некоторых выработались привычки (например: глубоко вложенные циклы, излишне большие функции), которые, по их мнению, было бы трудно поддерживать в языке, чувствительном к пробелам. У некоторых возникла эстетическая неприязнь к висячим отступам.
Единственная веская причина, с которой я столкнулся, заключается в том, что рефакторинг с использованием вырезания и вставки (не копирования) без инструментов рефакторинга (или вырезания и вставки с учетом синтаксиса ), может привести к изменению семантики, если будет допущена простая ошибка.
Потому что перемены страшны. И, возможно, среди некоторых разработчиков есть некоторые смутные воспоминания о языках с капризными правилами относительно пробелов, которые были трудно запоминаемыми и произвольными, предназначенными больше для удобства компилятора, чем для выразительности.
Скорее всего, настоящая причина заключается в том, чтобы не встряхнуть пустое значение перед тем, как отклонить его. Попросите кого-нибудь исправить ошибку в достаточно сложной, но хорошо написанной программе Python, затем попросите его исправить ошибку в системе 20-летней давности на C, VB или Cobol и спросите, что они предпочитают.
Что касается меня, у меня столько же проблем с пробелами в Python или Boo, как и с круглыми скобками в Lisp. То есть нет.
Некоторые люди думают, что пробелы не должны иметь синтаксического значения. Они написали это.
Им придется к этому привыкнуть. Изначально у меня была проблема с самим собой, пытаясь прочитать несколько примеров, но после некоторого использования языка мне он начал нравиться.
Я считаю, что это привычка, которую нужно преодолеть.
Это нарушает Принцип наименьшего удивления , потому что мы укоренились в нас самих (хорошо или плохо), что пробелы не Дело в языке программирования. Пробелы - одна из тех проблем, которые оставлены на усмотрение личного стиля.
У меня до сих пор плохие воспоминания о том, что я был студентом, который усердно усвоил, что 8 пробелов не эквивалентно вкладке в Makefile ... Ах, сон, который я потерял ...
Единственные жалобы на Python, которые я слышал (в том числе в отношении C ++), - от людей, которым не нравится использовать параметр «Заменить табуляцию пробелом» в их IDE.
Потому что они используются в таких языках, как C и JavaScript, где они могут выравнивать элементы по своему усмотрению.
Когда дело доходит до Python, вы должны делать отступ в коде в зависимости от его контекста:
def Print():
ManyArgumentFunction(LongParam1,LongParam2,LongParam3,LongParam4...
В C вы могли бы сделать:
void Print()
{
ManyArgumentFunction(LongParam1,
LongParam2,
LongParam3,...
}