Очередной раз на меня напал информационный голод, началось все с того, что изучил OpenID, потрясающая, на мой взгляд, технология. Но дело пошло дальше и теперь я сижу усиленно разбираюсь в фичах Питона! Собстна вопрос -- зачем мне Питон, если я знаю Перл? Ну, эээ, для разнообразия :)
Сразу оговорюсь, что Питон я знаю очень поверхностно, с Перлом же все чуть-чуть лучше :)
Недостатки Перла:
1. Куча проблем с UTF8. Разобрались, как победить UTF8 в своем коде, протестировали и успокоились? А теперь готовьтесь к тому, что почти каждый модуль на Цпане будет глючить с UTF8. Когда у вас 10 модулей, это можно пережить, а если 100 или, скажем, 200 (в нашей системе где-то в районе того) ? Проще повесится, вы правы.
2. Нет нормальной системы Thread`ов. До сих пор под многие проблемы Перл собирается бех их поддержки, впрочем, и правильно: нет соблазна юзать заведомо кривую технологию. Этот факт ограничивает использование Перла для разработки различных серверов, работающих без фронтэндов.
3. Много полезных модулей не введены с стандартную библиотеку (например, JSON, некоторые XML парсеры и проч.), а выбор на CPAN модулей велик настолько, что существует вероятность так и остаться на тестах, не дойдя до самой разработки :)
4. Отсутствие нормальных ORM.
5. Неудобное развертывание тяжелых систем, включающих сотни модулей. Почти всегда приходится ставить модули с force, т.к. кто-то да и вольет багавую версию либы, от которой зависит пол CPAN
6. Сложность синтаксиса, почти всегда требуется весьма продолжительная подготовка, чтобы понимать почти любой код. Питон же читается также легко как и технический английский
7. Поддержка исключений, нэтивная, без хаков и извратов.
Таким образом, как я вижу, Перл идеален для "тяжелых и старых монолитных", которые ранее появились как "десяток модулей", а потом выросли в монстров. Т.к. у девелоперов есть опыт сожительства со всеми модулями и проблемы с выбором не часто встают, т.к. функционал добавляется достаточно редко.
Для молодых и новых проектов идеален как раз Питон. Тут вам ORM, UTF8, легкая работа с почтой, стандартные быстрые HTTP сервера, удобное и очень быстрое развертывание через easy_install, которое не тащит за собой половину репозитория, куча отличных фреймворков, а также почти нету проблем с "выбором модулей", модули часто довольно хороши и не имеют полутора сотен подверсий, что сильно положительно сказывается на времени разработки. Кстати, о Питоновском ООП: он очень хорош и выглядит "как влитой", никакого маразма как в С++/Java, где ради этого ООПе надо писать тонны обязательного кода. Да, кстати, от Питона у меня руки не болят :)) Символов набивается даже меньше чем в Перле!
А следующий хейт-спич будет по священ РСУБД.
1. С UTF-8 всё пучком.
ReplyDelete2. use AnyEvent;
3 и 5. Системы деплоя (это как раз то, про что Ты писал на тему подгрузки модулей с CPAN) - это интересная задача, но под каждый проект лучше писать свою. Ну и на самом CPAN-е есть уже инструменты именно для деплоя.
4. DBIx::Class, DBI, и МОРЕ других орм-ок.
6. Я бы посомневался, но видимо это дело вкуса.
7. Поройся по CPAN - там для exception-ов немало решений.
Резюме:
- Мне не нравятся кошки!
- Вы просто не умеет их готовить :)
1. С UTF-8 всё пучком. -- сколько модулей в системе?
ReplyDelete2. Это никоим образом не заменяет нормальные триды, хотя решение и правда красивое, но вовсе не от хорошей жизни оно.
3. У нас деплой сейчас сделан на use CPAN; / CPAN::Shell, оно умеет и просто ставить модули и ставить с force. Но тут все равно куча проблем, особенно когда дело доходит до XS модулей, которые просто валятся при сборке ничего не говоря, для обычных юзеров это смерть. Также без мини хака PERL_MM_USE_DEFAULT=1 руки отваливаются щелкать Энтер при установке модулей
4. Рекомендую все же посмотреть на СклАлчеми, оно правда очень удобное и аналогов ему в Перле нету. ПЫСЫ: DBI не ORM, полагаю, просто описка.
6. Это смотря как писать :)
7. В том и дело, что там нужно рыться и выбирать (мы это уже с год делаем и довольно безрезультатно), а тут стандартно и надежно :)
Все пучком с утф - это, когда взял, и работаешь с ним.
ReplyDeleteА не когда разработчик (даже не начинающий) убивает полдня на избавление от козябр в базе данных.
И когда не надо помнить, где надо сделать encode, а где decode, а где оно сделается самостоятельно.
И когда не надо знать, что такое BOM.
И да:
Wide character in print at ...
Модулей в системе ОЧЕНЬ много. У нас каталистовский проект агрегатор. Но у нас в общем тоже есть минихак - та часть, которая всасывает в себя данные, пишется парнем, который на UTF-8 собаку съел ;)
ReplyDelete"Все пучком с утф - это, когда взял, и работаешь с ним." -- вот в том и проблема, что это "помнить" -- не более чем растрата полезной энергии :)
ReplyDelete"пишется парнем, который на UTF-8 собаку съел" -- случаем не Mons`ом ? ))
ReplyDelete2. fork :) Coro, POE, Event (интерфейс к libevent).
ReplyDelete4. Чем не нравится DBIx::Class?
5. yum/apt-get/... или PAR::Packer или ShipWright.
7. eval или TryCatch.pm (я использую Error.pm - очень удобный).
Работа с почтой - MIME::Lite. Никогда не имел проблем с ним.
ООП в Perl взято из Python. Сейчас луче использовать Moose/MooseX::Declare.
> Кстати, о Питоновском ООП: он очень хорош и выглядит "как влитой", никакого маразма как в С++/Java, где ради этого ООПе надо писать тонны обязательного кода.
ReplyDeleteможно поподробнее - насчет "маразма в Java" и "тонны обязательного кода"?
Java:
ReplyDeletepublic class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}
vs
Python:
class HelloWorld:
def main(self):
return 'hello world'
еще вопросы? :)
Автор явно не понимает, что такое Perl VM.
ReplyDeletePerl VM, Вы имеете в виду Parrot? Какое он имеет отношение к Перл 5?
ReplyDelete1. Если не тянуть в рот всякую каку, которой лет 10, то всё нормально.
ReplyDelete2. "нет соблазна юзать заведомо кривую технологию." Сам сказал, сам возразил. Вот так и надо! В
3. Вы так говорите, как будто это что-то плохое. В стандартных модулях Python есть не всё, что нужно, а искать в PyPI гораздо тяжелее, чем на CPAN. В CPAN можно воспользоваться поиском и получить отсортированный по рейтингу список модулей, у которых прямо на сайте можно почитать документацию и выбрать наиболее подходящий. Ну и культура документирования в Perl гораздо выше. Вполне возможно именно из-за того, что документацию так легко увидеть прямо на сайте.
4. DBIx::Class лучше джанговского ORM. Есть ещё SQLAlchemy, но он мне кажется более сложным в использовании, даже чем DBIx::Class.
5. Неудобно отстреливать себе ногу. Тесты для модулей придумали не для того, чтобы их игнорировать. И это, кстати, опять можно считать достоинством CPAN. Там хотя бы ясно, что с модулем может быть что-то не так, с PyPI это совсем не очевидно - можно поставить модуль, который на деле не работает (и такие случаи действительно бывали в моей практике).
6. Синтаксис Python'а слишком неоднозначен.
Сравните:
a.b.c() или a::b->c()
a[b][c] или $a->{$b}->[$c] (или $a{$b}->[$c])
a + b или $a . $b (или $a + $b)
a > b или $a gt $b (или $a > $b)
Ещё одно преимущество Perl в том, что при использовании прагмы strict можно поймать очевидные ошибки ещё на этапе компиляции. То же самое и с прагмой fields.
Другое преимущество - в менее строгой типизации. Строку с числом можно использовать без преобразования в числовом контексте, как число. Полезно, когда из регулярного выражения нужно выделить число - не приходится вспоминать о необходимости преобразования строки в число.
7. Исключения Python особенно достают в сочетании с той самой строгой типизацией, когда много дней стабильно работавшая программа вдруг вылетает с исключением, когда в первый раз за всё это время заходит в какой-нибудь кусок кода, где забыли привести переменную к правильному типу.
Perl в таких случаях выдаёт предупреждения и работает вполне логично - вместо undef использует пустую строку в строковом контексте или 0 - в числовом.
Для себя я решил, что Python больше годится для идеальной реальности, в которой не бывает ошибок и не нужно заботиться о производительности: веб-приложения, математические расчёты. Как нужно разгрести авгиевы конюшни, то тут Perl вне конкуренции.
Проблем с UTF8 в Python больше - нужно постоянно не забывать прописывать -*- coding: utf8 -*- в начале файла, приписывать префикс u к строковым литералам и не забывать указывать флаг re.U в регулярных выражениях и не забывать указывать кодировку файла при открытии на чтение или запись. (В Perl обычно достаточно указать или не указать прагму utf8, а кодировки он умеет подхватывать из переменных окружения). И то, опять-таки, далеко не факт, что Python не выкинет исключения, когда обнаружит, что не может преобразовать очередную неюникодную строку в юникодную (иногда бывает не понятно, зачем он пытается это сделать, потому что на следующем этапе ему опять придётся преобразовать её в неюникодную).
В Python больше ценю не ООП, а функциональное программирование, итераторы, генераторы, сопрограммы, "волшебные" операторы with и for, возможность перегрузки операций типа +, -, / и т.п.
сисадмин?
DeleteПолностью согласен, за исключением научных расчётов Perl на порядок лучше и проще Python
DeleteДа, согласен :) Go рулит вообще!
Delete