On Wednesday 03 February 2010 18:35:33 Dmitry Arsentiev wrote:
> >> Питон проще, порог вхождения как минимум вдвое ниже,
> >> для экспериментов идеален.
> >
> > Было бы здорово услышать аргументацию. Не флейма ради, а чтобы
> > понимать и упоминать.
>
> Спросил у коллеги, который пробовал сам выучить Пёрл,
> а потом стал программировать на Питоне.
>
> Во-первых, отступы. Не так страшны. как их малюют.
+1. Одна строчка настроек для vim позволяет ставить их автоматически и стирать
одним нажатием на backspace. А то, что даже в чужом коде визуально
видно, какой оператор к блоку какой вложенности относится - это вообще супер.
> В-пятых. Ссылки, разыменование ссылок.
> Я спросил у коллеги, он сказал, что такого разнообразия игр со сслыками,
> как в перле, в питоне нету.
> Т.е. всякие \() , \&funcfoo, %{ $refhash } и т.д. - нету их.
Точнее, всё это есть, но доступно через функции с длинными названиями. Быстро,
как в перле создать копию хеша, имея ссылку на него, дописать туда пару
ключей, не получается - это превращается в колбасу из трех функций из
стандартной библиотеки вместо { %$orig_hash, key1 => 1, key2 => 1 }, Код не
получается писать так же быстро, как на Перле. Кстати, в литературе отмечают,
что питонячий синтаксис специально задумывался для быстрой разработки.
Убрать лишние скобки, лишние символы, лишние ключевые слова для объявления
переменных и т.д. Это все помогает, но без перловых всяких \() не
получается такого удобства.
> Правда, в питоне нету автовивификации, насколько я знаю..
> И это единственный крупный минус питона перед перлом в моих глазах.
Справедливости ради, это часто бывает и причиной ошибок. Ошибся в названии поля
вместо $self->{field}->[$i] написал $self->{fieid}->[$i] - и
разбирайся потом, откуда баг растет. Ни одного ворнинга при этом.
> В-шестых. Объекты перла слизаны с объектов питона.
> Поэтому здесь питон не хуже перла.
Уу, они совсем разные. Совсем. В перле объекты мне нравятся в сто раз больше. У
меня довольно специфичная задача - онлайн-игрушка. Запускаются
толстенные демоны, которые хранят в себе игровое состояние, и управляются
событиями от игроков. В код постоянно вносятся изменения - от мелких фиксов
до крупных нововведений.
И сложность в том, что нужно, не прерывая работу сервера, не останавливая
процесс, на лету перезагружать код. В перле благословение объекта - это
просто присвоение строчки с названием класса. А в питоне каждый класс - это сам
по себе объект, и экземпляры этого класса знают то, что они
принадлежат к этому классу, храня в себе ссылку на объект класса, а не просто
строчку с его названием.
При перезагрузке файла с исходником программы перл замещает все функции в
пакете на новые скомпилированные, и при вызове методов старых объектов будут
вызываться уже новые функции. А в питоне создается новый объект класса, в него
компилируется новый код. А старые объекты как ссылались на старый
объект класса, так и продолжают ссылаться. И не пересоздав объект, изменить его
класс невозможно. Это порождает необходимость использования костылей
для перезагрузки питонячьих классов - вручную смотреть таблицы методов,
переписывать их из нового объекта класса в старый и т.д.
> В-седьмых, сопровождать чужой код на питоне
> проще, чем сопровождать чужой код на перле.
> Последнее иногда просто невозможно.
> Т.е. уход крутого разработчика означает сперва "обожествление",
> а потом и омертвение оставленного разработчиком кода.
100%. Я нуб в питоне, но легко читаю его библиотечный код, чтобы разобраться в
особенностях работы. В перле это намного сложнее - подменяются функции,
переопределяются всякие autoload'ы - пока разберешься в особенностях
реализации, уже забудешь, как это все вместе работать должно.
PS. Вот за что я люблю moscow.pm - все-таки классная тут аудитория собралась.
Можно спокойно без флейма обсуждать оффтопиковые технологии. Видно, что
пишут люди, для которых язык программирования - не религия, а инструмент для
решения задач.
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
