@powerman4 июн 2007 в 21:31

Why Perl sucks?

7 мин

4.9K

Perl *

Перевод

+35

Комментарии 78

@powerman 4 июн 2007 в 21:49

Честно говоря, в планах было после перевода выдать своё мнение... учитывая, что статья 3-х летней давности некоторые вещи могли измениться, о чём-то автор просто мог не знать.

Например, для определения типа скаляра есть функция looks_like_number() в модуле Scalar::Util. Ну и так далее, разных workaround-ов для описанных проблем существует некоторое кол-во.

Но сил на это уже нет. Два часа переводил, пол часа форматировал, а выдохся так, будто вагон разгружал. Вероятно, это связано с тем, что это мой первый перевод - до этого момента я предпочитал писать сам, а не переводить. Но эта статья очень понравилась, давно сам такое хотел написать. И, в общем и целом, в ней всё верно... хотя попридираться можно, если бы силы остались. :)

@glader 5 июн 2007 в 05:04

Это от желания поскорее выложить :) Можно же перевести, на следующий день на свежую голову вычитать и поправить.

@ihrd 5 июн 2007 в 06:58

огромное спасибо за перевод, инетресная статья. Как раз разбираюсь с Perl 6 и приятно видить, что сохраняя всю мощь, как раз описанные sucks старательно исправляют.

@super 5 июн 2007 в 03:29

Интересно было-бы почитать о сравнении PERL с PHP.

@powerman 5 июн 2007 в 04:14

Ага. На хабре только этого flamewar нехватало для полного счастья. Лучше сделаем так - выше статья по недостаткам Perl, а вот статья по недостаткам PHP: К вопросу об ублюдочности PHP. На всякий случай, как и автор этой статьи уточню - речь не идёт о том, что "Perl rulez, PHP suxx", это просто описание недостатков PHP, а Perl иногда упоминается просто для сравнения, не более того. Все языки важны, все языки нужны. Ом!

@blockdog 5 июн 2007 в 05:46

Прочитал по диагонали. Скажем так: не совсем правда. Но это обсуждение для отдельной статьи.

@HeadWithoutBrains 5 июн 2007 в 06:36

Прочитал полностью. По пунктам которые там указаны
1. Такой разброс в названии функций, как ме кажется связан с тем что php разрабатывают/дорабатывают много людей, и если бы сейчас хотели бы упорядочить названия функций, было бы довольно сложно это сделать
2. Количество функций. Мне кажется, что именно поэтому php и популярен. Из за огромного количества функций которые могут выполнять рутинную работу. А то что они все сразу доступны. Опять же связано с архитектурой php
3. Насчет пространства имен, автор прав. Но к сожаленью например я, уже давно привык к этому =)
5. Бейте меня, но мне очень нравится работа с массивами в php. А для сравнения типов есть ===. Или при проверке, просто приводите переменную которую сравниваете к нужному типу.
6. Не хочу комментировать, так как сам начинаю задумывать насчет серьезности php

Хочу сказать что это всё, мое личное субьективное мнение. Я не гуру программинга на php и возможно что то говорю не правильно.

@HeadWithoutBrains 5 июн 2007 в 06:39

А насчет статьи про perl, то я бы лично не хотел говорить насчет его недостатках и говорить что он хуже php, так как такие языки как perl возникли сравнительно давно, и используются не только в вебе(в плане синтаксиса). Для меня лично, perl представляется эдаким пожилым мужчиной, а php молодым, постоянно куда то бегущим юнцом =)
А питон вообще змея :D

@blockdog 5 июн 2007 в 06:14

Мне тоже интересно.

@oogl 5 июн 2007 в 04:42

Было бы скорее интересно почитать о преимуществах Perl. Например: что в нём есть кроме регэкспов?

@glader 5 июн 2007 в 05:07

Регекспы много где есть. Просто в перле ими несколько более удобно пользоваться.

@oogl 5 июн 2007 в 07:16

почему удобней? чем?

@bolk 5 июн 2007 в 11:58

Смотря по сравнению с чем. По сравнению с PHP — явно удобнее. Например, regexp в Perl — отдельный типа, а в PHP он передаётся через строку. Из-за этого, иногда, возникает дикое количество слешей для экранирования.

@glader 5 июн 2007 в 13:59

Удобнее - тем, что есть синтаксический сахар. Строка
str =~ /\d+/;
нагляднее, чем
re.search('\d+', str)
хотя может это просто привычка

@bendingunit22 5 июн 2007 в 15:04

В Perl регулярные выражения реализованы в самом языке на уровне операторов. Кроме того, в Perl лучший диалект, что признает тот же Фридл.

@random 18 июн 2007 в 09:20

В дополнение к уже сказанному (насчет удобного синтаксиса и диалекта) - в Перле регекспы проходят проверку синтаксиса на этапе компиляции. Это очень удобно.

@jerom 5 июн 2007 в 05:19

На нём красиво и компактно выглядят скрипты и очень удобно обрабатывать текстовые данные.

Но, если к C++ добавить boost, то всё становится примерно так же удобно, просто многословнее.

Вот тут из двух крупных функций на Паскале получаются такие строки:

sub ckinn($) { $_[0]!~/^(\d{9})(\d)(?:(\d)(\d))?$/ || (($3) ?
$3!= c("0".$1.$2) || $4!= c($1.$2.$3): $2!= c("00".$1)) + 0 }
sub c($) { $a=shift; $c=0; map { $c+=chop($a)*$_ } (8,6,4,9,5,3,10,4,2,7,3); $c %11 %10 }

Это, конечно, просто зарядка для ума и развлечение, но возможности демонстрирует.

@jartashi 5 июн 2007 в 07:04

Пожалуй паскалевский код прочитать быстрее.
Хотя для тех кто пользует perl ежедневно пару лет и уже думает на нем, это наверное и не так.

@jerom 5 июн 2007 в 07:37

Ну, если рассматривать только вариант ckinn10, то он понятнее. Но я люблю такие развлечения

@iDev 5 июн 2007 в 07:09

Думаю, такая регекспина будет работать едва ли не дольше чем паскалевские функции, да и читаюстся они легче.
P.S. Я ни в коем случае не умоляю достоинств регулярных выражений, даже напротив время от времени ломаю об них мозг :)

@oogl 5 июн 2007 в 07:23

А если конкретно и не касаясь регэкспов.

@schors 5 июн 2007 в 07:29

Эка тему я в своё время подкинул... :)))

@diamant 5 июн 2007 в 08:51

вот из-за таких конструкций программисты и выбирают php, а не perl :)
когда delphi-с-программисту приходится быстро переходить на web-порграммирование, причём нет полгода на обучение, а проект нужно сдать через месяц

@gribozavr 5 июн 2007 в 15:16

А потом мы спрашиваем откуда такое огромное количество ужасного кода в web-проектах...

@glader 5 июн 2007 в 05:02

Спасибо, интересно.

P.S. А аutovivification, по моему мнению, скорее плюс чем минус.

@jerom 5 июн 2007 в 05:08

Я бы сказал, что это был бы плюс, если бы в перле были честные классы.

Но сейчас классы это, по сути, хэши. Отсюда и растёт желание убрать аutovivification для некоторых конкретных хэшей.

@glader 5 июн 2007 в 05:18

В некоторых конкретных случаях можно включить варнинг использования несуществующих ключей. Хотя это нельзя назвать решением.

@nonSmoker 5 июн 2007 в 05:30

Есть workaround для таких целей.
http://search.cpan.org/~kvail/Tie-Strict…

@Meneldor 5 июн 2007 в 07:36

А ещё lock_keys of Hash::Util.

@random 18 июн 2007 в 09:32

use fields в помощь. Проблему с аutovivification решает, да еще и проверки будут не в рантайме (как с решениями на основе tie и пр.), а еще при компиляции.

@Helg 5 июн 2007 в 06:06

Кто-нибудь знает, когда ждать perl 6? Нигде внятной информации найти не могу :(

@ihrd 5 июн 2007 в 07:11

когда будет готов :) так говорят разработчики. мне самому дико интересно, потому, что то, что получается мне кажется отличным языком.

@bendingunit22 5 июн 2007 в 07:17

Не в этом году - это точно :(

@Helg 5 июн 2007 в 07:45

Где-то слышал, что Ларри обещал в мае... Уже июнь... Неужели правда не в этом году? Ссылка на источник есть?

@bendingunit22 5 июн 2007 в 15:06

Он уже седьмой год только и делает, что обещает :)

НЛО прилетело и опубликовало эту надпись здесь

@anortorn 6 июн 2007 в 09:36

Это вы зря, у питона библиотека очень даже не маленькая. И скрипты автоматизации пишутся. Другое дело, что perl более привычен для многих в этой сфере.

@apla 15 мая 2008 в 12:00

может и немаленькая, но в перле документация ощутимо лучше той, что есть в питоне. поэтому для большинства применений в перле читаем документацию и пишем, а в питоне — сидим и экспериментируем.

@Meneldor 5 июн 2007 в 07:36

В Питоне есть аналог mod_perl?

@Meneldor 5 июн 2007 в 07:42

mod_python - это оно и есть?

@bubuq 5 июн 2007 в 08:22

Я вижу одну: CPAN.

НЛО прилетело и опубликовало эту надпись здесь

@bendingunit22 5 июн 2007 в 15:11

Смотря какие задачи. Я на Ruby ради интереса и для более детального изучения синтаксиса пытался портировать готовое Perl приложение. Так вот местный Net::HTTP даже не умеет работать с плюшками, а во всех конференциях предлагают родить велосипед самому. Что уж говорить об LWP::Parallel и прочих радостях. CPAN - это то, благодаря чему Perl живет и довольно активно используется.

@scam 21 окт 2007 в 16:34

LWP::Parallel - это такой тормоз. В 3 раза медленнее PHP curl_multi... Я щас пытаюсь найти ему замену. На с наскока пока ничего не нашёл (можно чеерез fork + mhtttp (ghttp), но там нет https, cookie etc.).

@powerman 22 окт 2007 в 02:08

Посмотрите у меня на сайте модули POWER::Multi::GET и POWER::Event::IO.

Первый (POWER::Multi::GET) был написан много лет назад как значительно более быстрая альтернатива LWP::Parallel (его скорость достигала в те времена 280 url/sec, а на современном железе возможно будет больше).

А второй был написан с целью исправить некоторые архитектурные недостатки первого. Во-первых он использует epoll, так что CPU жрёт значительно меньше. Во-вторых он использует событийную модель, так что в процессе выкачки url можно заниматься другими делами. Но для второго я ещё не реализовал поддержку HTTP как в первом (с куками, редиректами, etc.), так что это пока нужно делать ручками. Но его скорость в среднем 500 url/sec, судя по нашим тестам.

Использовалось это всё под Linux, и врядли будет работать под другими системами (второй - точно не будет, т.к. в других системах нет epoll).

@scam 22 окт 2007 в 08:07

Спасибо за наводку! Я с epoll работал в прошлом через libevent (про select забыл, как про страшный сон). Жалко, что в событийном модуле нет поддержки cookie и redirects... Но 280 url/sec более чем достаточно. Главное, чтобы модуль был рабочий и не тормозил, как LWP::Parallel. Я сейчас также присматриваюсь к POE + POE::Component::Client::HTTP. Если был положительный/отрицательный опыт работы с этим модулем, с удовольствием выслушаю.

Если вы используете epoll напрямую, а не через обёртку вроде libevent, то на других системах отличных от Linux работать не будет наверно. Но если через libevent, то на freebsd должно, т.к. там есть аналог epoll'a - kqueue.

@life4beer 5 июн 2007 в 09:16

Для меня большой минус перла - то, что там слишком много свободы. Можно использовать скобки, можно не использовать. Можно писать "if (blabla) { tratata}", а можно "tratata if (blabla)" и т.д. Поначалу это казалось плюсом, но как только довелось работать в команде, выяснилось, что очень трудно читать чужой код. Поэтому очень важно, если работаешь в команде, жестко придерживаться неких code rules, первым пунктом где ОБЯЗАТЕЛЬНОЕ использование use strict.

@khibinite 5 июн 2007 в 09:45

Ну так в любом языке можно словить множество неудобств из-за различий в форматировании, например. Меня, к примеру, крайне раздражают отступы в 1-2 пробела :), идентификаторы типа с1, x2 итп (в любом языке!). Так что, естественно, при работе в команде нужен стандарт.

@life4beer 5 июн 2007 в 10:20

форматирование в том числе, но я не только про него говорил. уж слишком много вольности, а без use strict так просто бардак.

@DimaD 5 июн 2007 в 11:32

Ну если вы разрабатываете большой проект, то надо использовать соглашения о кодировании, а с ними обычно код на всех языках очень похож. В маленьких скриптиках "для себя" strict иногда мешает и я его там не использую вообще.

@life4beer 5 июн 2007 в 12:06

можно пример, когда strict мешает?

@bendingunit22 5 июн 2007 в 15:12

Без use strict получается PHP ;)

@123 5 июн 2007 в 10:05

1. Нет наследования объектов.

Не понимаю - зачем в скриптовом языке использовать ООП...

@mshilov 5 июн 2007 в 12:07

Perl это еще и объектно-ориентированный язык, просто "ориентация" там .. хм.. другая :)

@DimaD 5 июн 2007 в 11:29

Мне вот не нравится, что конструкция вида (1, 2, 3, (4, 5), 6) склеивается в один список и код вида. Ко всему остальному уже как-то привык

@DimaD 5 июн 2007 в 11:31

Первое предложе ние читать как "Мне вот не нравится, что конструкция вида (1, 2, 3, (4, 5), 6) склеивается в один список."

@glader 5 июн 2007 в 14:05

пиши (1, 2, 3, [4, 5], 6) :)

@DimaD 6 июн 2007 в 08:42

Это несколько другая вещь. По идее () - это список скаляров. Так вот когда я подставляю вместо одного из скаляров список, по идее должен срабатывать скалярный контекст на список, ан нет, списки склеиваются

@glader 6 июн 2007 в 09:02

А, вон ты про что. Видимо автор языка решил, что объединение списков понадобится чаще, чем преобразование списка в скаляр.

@kentposalu 5 июн 2007 в 13:06

уродство этот perl по сравнению с ruby

@MpaK 6 июн 2007 в 08:48

то что не объектный это понятно уже давно, как и пхп... но писать коряво можно на любом языке, хоть тот же РУБИ или С++, еще как можно :)

кстати, а про константы, чем ему не нравиться такой метод

*CONST = 'Hello World';

$CONST = 'Good buy World'; # вызовет ошибку! все нормально

@MpaK 6 июн 2007 в 08:49

вот так правильнее *CONST = \'Hello World';

@zag 6 июн 2007 в 11:05

Очень плохая статья. Человека, скорее относящегося равнодушно к perl!

@Cancel 9 июн 2007 в 11:33

Пользуюсь перлом довольно давно, в основном в качестве -pi-однострочников (ну, не люблю я sed/awk!) либо же для массовой обработки текстовых файлов.

Пробовал питон для второй задачи, но он у меня как-то не прижился. Стараюсь писать все перловые программы в C-стиле, иначе, действительно, потом хрен поймёшь, что же делает программа. Ну, а основное преимущество — это, конечно, CPAN.

@random 18 июн 2007 в 10:21

1. "ОО в Perl это на самом деле не более чем bless-нутые ссылки и немного синтаксического сахара" - интересно, что это "не более чем" дает возможность реализовать больше ОО-фичей, чем в любом другом мейнстримном языке: от множественного наследования до использования prototype-based обьектности вместо class-based.

2. Со счетчиком ссылок все просто: при необходимости используйте средства для создания weak references (ссылок, не инкрементящих счетчик). Стандартно - Scalar::Util::weaken().

5. "Здесь же, вместо мелкого выигрыша, perl, интерпретатор, получает непотребный удар по производительности." - это заблужение. Действительно, use constant создает функциии (сделано это, чтобы не вводить доп. сущностей в язык). Но: умный компилятор инлайнит функции, возвращающие константное значение (не важно, созданные ли через use constant или вручную), так что при операциях с ними работа идет непосредственно со значением, вызова функции не происходит. Кроме того, в качестве констант можно использовать readonly переменные.

6. Непонятно, зачем определять тип переменной вместо того, чтобы просто использовать ее в нужном контексте. Впрочем, если есть необходимость, можно напрямую обратиться к IV или строковому значению SV. Пример:

use B;
my $x = "string"; $x = 10;
my $xb = B::svref_2object(\$x);
printf "%s, %d",$xb->PVX,$xb->IV;

@powerman 18 июн 2007 в 11:59

По поводу функций и их inline. К сожалению, это работает далеко не всегда, например смотрите мой пост на perlmonks: Slow constants. Кроме того, read-only скаляры (созданные, например, так: eval q{*O_NONBLOCK = \\}.O_NONBLOCK;) работают немного быстрее и обычных скаляров, и инлайнящихся функций! Об этом можно почитать в другом моём посте: Import constants as scalar instead of bareword sub.

@random 18 июн 2007 в 13:45

Естественно, компилятор не может оптимизировать то, чего нет на этапе компиляции - так что фолдинг не будет работать для динамически генерируемых функций (подозреваю, что и для XS тоже).

Вариант с readonly-переменными я тоже предлагал выше, ибо TMTOWTDI, но у него есть один очень серьезный недостаток: переменные, даже readonly, все-таки можно переопределить, причем случайно (что мешает мне обьявить my $O_NONBLOCK ?) - и компилятор/рантайм не выдаст при этом никаких сообщений! При переопределении же constant sub (не важно, через sub CONST {} или *CONST = sub) получим предупреждение: Constant subroutine main::CONST_NAME redefined (в случае sub CONST - еще на этапе компиляции).

@powerman 19 июн 2007 в 00:11

Это уже софистика пошла. А на самом деле всё иначе.

Да, "компилятор не может оптимизировать то, чего нет на этапе компиляции". Но проблема в том, что когда я подгружаю через use разные модули, я не могу заранее знать, на каком этапе эти модули генерируют/экспортируют константы - на этапе компиляции или на этапе выполнения. В доке такие нюансы обычно не упоминают, да и задолбаешься по каждому отдельному модулю это уточнять. Так что проблема таки есть!

Что касается объявления "my $O_NONBLOCK", то тут два нюанса. Во-первых существует соглашение, что в верхнем регистре пишутся только константы, так что "my $O_NONBLOCK" в середине кода - это красный флаг на который среагируют все квалифицированные программисты, и никто из них такого не напишет (если не хочет действительно переопределить эту константу, как грязный но нужный хак). А во-вторых никто не мешает через no warnings 'redefine' отключить предупреждение о переопределении константной процедуры и переопределить её так же тихо, как и скаляр через "my".

@cybermozg 2 авг 2007 в 21:52

Весь перл - это один большой хак. В этом его сила и в этом его слабость.
Но перл - это всего лишь инструмент. Всё остальное - вопросы мастерства и дисциплины.

Можно сказать, что самурайски меч - это слишком неудобный дивайс, ибо его нельзя метнуть в голову врагу. И ещё он шибко острый, об него обрезаться можно.