FastNetMon

Monday 27 July 2009

Perl vs Python

Очередной раз на меня напал информационный голод, началось все с того, что изучил 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, где ради этого ООПе надо писать тонны обязательного кода. Да, кстати, от Питона у меня руки не болят :)) Символов набивается даже меньше чем в Перле!

А следующий хейт-спич будет по священ РСУБД.

15 comments :

  1. 1. С UTF-8 всё пучком.

    2. use AnyEvent;

    3 и 5. Системы деплоя (это как раз то, про что Ты писал на тему подгрузки модулей с CPAN) - это интересная задача, но под каждый проект лучше писать свою. Ну и на самом CPAN-е есть уже инструменты именно для деплоя.

    4. DBIx::Class, DBI, и МОРЕ других орм-ок.

    6. Я бы посомневался, но видимо это дело вкуса.

    7. Поройся по CPAN - там для exception-ов немало решений.


    Резюме:
    - Мне не нравятся кошки!
    - Вы просто не умеет их готовить :)

    ReplyDelete
  2. 1. С UTF-8 всё пучком. -- сколько модулей в системе?
    2. Это никоим образом не заменяет нормальные триды, хотя решение и правда красивое, но вовсе не от хорошей жизни оно.
    3. У нас деплой сейчас сделан на use CPAN; / CPAN::Shell, оно умеет и просто ставить модули и ставить с force. Но тут все равно куча проблем, особенно когда дело доходит до XS модулей, которые просто валятся при сборке ничего не говоря, для обычных юзеров это смерть. Также без мини хака PERL_MM_USE_DEFAULT=1 руки отваливаются щелкать Энтер при установке модулей
    4. Рекомендую все же посмотреть на СклАлчеми, оно правда очень удобное и аналогов ему в Перле нету. ПЫСЫ: DBI не ORM, полагаю, просто описка.
    6. Это смотря как писать :)
    7. В том и дело, что там нужно рыться и выбирать (мы это уже с год делаем и довольно безрезультатно), а тут стандартно и надежно :)

    ReplyDelete
  3. Все пучком с утф - это, когда взял, и работаешь с ним.
    А не когда разработчик (даже не начинающий) убивает полдня на избавление от козябр в базе данных.
    И когда не надо помнить, где надо сделать encode, а где decode, а где оно сделается самостоятельно.
    И когда не надо знать, что такое BOM.
    И да:
    Wide character in print at ...

    ReplyDelete
  4. Модулей в системе ОЧЕНЬ много. У нас каталистовский проект агрегатор. Но у нас в общем тоже есть минихак - та часть, которая всасывает в себя данные, пишется парнем, который на UTF-8 собаку съел ;)

    ReplyDelete
  5. "Все пучком с утф - это, когда взял, и работаешь с ним." -- вот в том и проблема, что это "помнить" -- не более чем растрата полезной энергии :)

    ReplyDelete
  6. "пишется парнем, который на UTF-8 собаку съел" -- случаем не Mons`ом ? ))

    ReplyDelete
  7. 2. fork :) Coro, POE, Event (интерфейс к libevent).
    4. Чем не нравится DBIx::Class?
    5. yum/apt-get/... или PAR::Packer или ShipWright.
    7. eval или TryCatch.pm (я использую Error.pm - очень удобный).

    Работа с почтой - MIME::Lite. Никогда не имел проблем с ним.

    ООП в Perl взято из Python. Сейчас луче использовать Moose/MooseX::Declare.

    ReplyDelete
  8. > Кстати, о Питоновском ООП: он очень хорош и выглядит "как влитой", никакого маразма как в С++/Java, где ради этого ООПе надо писать тонны обязательного кода.

    можно поподробнее - насчет "маразма в Java" и "тонны обязательного кода"?

    ReplyDelete
  9. Java:
    public class HelloWorld {
    public static void main(String[] args) {
    System.out.println("Hello, world!");
    }
    }

    vs

    Python:
    class HelloWorld:
    def main(self):
    return 'hello world'

    еще вопросы? :)

    ReplyDelete
  10. Автор явно не понимает, что такое Perl VM.

    ReplyDelete
  11. Perl VM, Вы имеете в виду Parrot? Какое он имеет отношение к Перл 5?

    ReplyDelete
  12. 1. Если не тянуть в рот всякую каку, которой лет 10, то всё нормально.

    2. "нет соблазна юзать заведомо кривую технологию." Сам сказал, сам возразил. Вот так и надо! В


    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, возможность перегрузки операций типа +, -, / и т.п.

    ReplyDelete
    Replies
    1. сисадмин?

      Delete
    2. Полностью согласен, за исключением научных расчётов Perl на порядок лучше и проще Python

      Delete
    3. Да, согласен :) Go рулит вообще!

      Delete

Note: only a member of this blog may post a comment.