Comments 78
Честно говоря, в планах было после перевода выдать своё мнение... учитывая, что статья 3-х летней давности некоторые вещи могли измениться, о чём-то автор просто мог не знать.
Например, для определения типа скаляра есть функция looks_like_number() в модуле Scalar::Util. Ну и так далее, разных workaround-ов для описанных проблем существует некоторое кол-во.
Но сил на это уже нет. Два часа переводил, пол часа форматировал, а выдохся так, будто вагон разгружал. Вероятно, это связано с тем, что это мой первый перевод - до этого момента я предпочитал писать сам, а не переводить. Но эта статья очень понравилась, давно сам такое хотел написать. И, в общем и целом, в ней всё верно... хотя попридираться можно, если бы силы остались. :)
Например, для определения типа скаляра есть функция looks_like_number() в модуле Scalar::Util. Ну и так далее, разных workaround-ов для описанных проблем существует некоторое кол-во.
Но сил на это уже нет. Два часа переводил, пол часа форматировал, а выдохся так, будто вагон разгружал. Вероятно, это связано с тем, что это мой первый перевод - до этого момента я предпочитал писать сам, а не переводить. Но эта статья очень понравилась, давно сам такое хотел написать. И, в общем и целом, в ней всё верно... хотя попридираться можно, если бы силы остались. :)
Интересно было-бы почитать о сравнении PERL с PHP.
Ага. На хабре только этого flamewar нехватало для полного счастья. Лучше сделаем так - выше статья по недостаткам Perl, а вот статья по недостаткам PHP: К вопросу об ублюдочности PHP. На всякий случай, как и автор этой статьи уточню - речь не идёт о том, что "Perl rulez, PHP suxx", это просто описание недостатков PHP, а Perl иногда упоминается просто для сравнения, не более того. Все языки важны, все языки нужны. Ом!
Прочитал по диагонали. Скажем так: не совсем правда. Но это обсуждение для отдельной статьи.
Прочитал полностью. По пунктам которые там указаны
1. Такой разброс в названии функций, как ме кажется связан с тем что php разрабатывают/дорабатывают много людей, и если бы сейчас хотели бы упорядочить названия функций, было бы довольно сложно это сделать
2. Количество функций. Мне кажется, что именно поэтому php и популярен. Из за огромного количества функций которые могут выполнять рутинную работу. А то что они все сразу доступны. Опять же связано с архитектурой php
3. Насчет пространства имен, автор прав. Но к сожаленью например я, уже давно привык к этому =)
5. Бейте меня, но мне очень нравится работа с массивами в php. А для сравнения типов есть ===. Или при проверке, просто приводите переменную которую сравниваете к нужному типу.
6. Не хочу комментировать, так как сам начинаю задумывать насчет серьезности php
Хочу сказать что это всё, мое личное субьективное мнение. Я не гуру программинга на php и возможно что то говорю не правильно.
1. Такой разброс в названии функций, как ме кажется связан с тем что php разрабатывают/дорабатывают много людей, и если бы сейчас хотели бы упорядочить названия функций, было бы довольно сложно это сделать
2. Количество функций. Мне кажется, что именно поэтому php и популярен. Из за огромного количества функций которые могут выполнять рутинную работу. А то что они все сразу доступны. Опять же связано с архитектурой php
3. Насчет пространства имен, автор прав. Но к сожаленью например я, уже давно привык к этому =)
5. Бейте меня, но мне очень нравится работа с массивами в php. А для сравнения типов есть ===. Или при проверке, просто приводите переменную которую сравниваете к нужному типу.
6. Не хочу комментировать, так как сам начинаю задумывать насчет серьезности php
Хочу сказать что это всё, мое личное субьективное мнение. Я не гуру программинга на php и возможно что то говорю не правильно.
А насчет статьи про perl, то я бы лично не хотел говорить насчет его недостатках и говорить что он хуже php, так как такие языки как perl возникли сравнительно давно, и используются не только в вебе(в плане синтаксиса). Для меня лично, perl представляется эдаким пожилым мужчиной, а php молодым, постоянно куда то бегущим юнцом =)
А питон вообще змея :D
А питон вообще змея :D
Мне тоже интересно.
Было бы скорее интересно почитать о преимуществах Perl. Например: что в нём есть кроме регэкспов?
Регекспы много где есть. Просто в перле ими несколько более удобно пользоваться.
почему удобней? чем?
Смотря по сравнению с чем. По сравнению с PHP — явно удобнее. Например, regexp в Perl — отдельный типа, а в PHP он передаётся через строку. Из-за этого, иногда, возникает дикое количество слешей для экранирования.
Удобнее - тем, что есть синтаксический сахар. Строка
str =~ /\d+/;
нагляднее, чем
re.search('\d+', str)
хотя может это просто привычка
str =~ /\d+/;
нагляднее, чем
re.search('\d+', str)
хотя может это просто привычка
В Perl регулярные выражения реализованы в самом языке на уровне операторов. Кроме того, в Perl лучший диалект, что признает тот же Фридл.
В дополнение к уже сказанному (насчет удобного синтаксиса и диалекта) - в Перле регекспы проходят проверку синтаксиса на этапе компиляции. Это очень удобно.
На нём красиво и компактно выглядят скрипты и очень удобно обрабатывать текстовые данные.
Но, если к 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 }
Это, конечно, просто зарядка для ума и развлечение, но возможности демонстрирует.
Но, если к 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 }
Это, конечно, просто зарядка для ума и развлечение, но возможности демонстрирует.
Пожалуй паскалевский код прочитать быстрее.
Хотя для тех кто пользует perl ежедневно пару лет и уже думает на нем, это наверное и не так.
Хотя для тех кто пользует perl ежедневно пару лет и уже думает на нем, это наверное и не так.
Ну, если рассматривать только вариант ckinn10, то он понятнее. Но я люблю такие развлечения
Думаю, такая регекспина будет работать едва ли не дольше чем паскалевские функции, да и читаюстся они легче.
P.S. Я ни в коем случае не умоляю достоинств регулярных выражений, даже напротив время от времени ломаю об них мозг :)
P.S. Я ни в коем случае не умоляю достоинств регулярных выражений, даже напротив время от времени ломаю об них мозг :)
А если конкретно и не касаясь регэкспов.
Эка тему я в своё время подкинул... :)))
вот из-за таких конструкций программисты и выбирают php, а не perl :)
когда delphi-с-программисту приходится быстро переходить на web-порграммирование, причём нет полгода на обучение, а проект нужно сдать через месяц
когда delphi-с-программисту приходится быстро переходить на web-порграммирование, причём нет полгода на обучение, а проект нужно сдать через месяц
Спасибо, интересно.
P.S. А аutovivification, по моему мнению, скорее плюс чем минус.
P.S. А аutovivification, по моему мнению, скорее плюс чем минус.
Я бы сказал, что это был бы плюс, если бы в перле были честные классы.
Но сейчас классы это, по сути, хэши. Отсюда и растёт желание убрать аutovivification для некоторых конкретных хэшей.
Но сейчас классы это, по сути, хэши. Отсюда и растёт желание убрать аutovivification для некоторых конкретных хэшей.
В некоторых конкретных случаях можно включить варнинг использования несуществующих ключей. Хотя это нельзя назвать решением.
Есть workaround для таких целей.
http://search.cpan.org/~kvail/Tie-Strict…
http://search.cpan.org/~kvail/Tie-Strict…
use fields в помощь. Проблему с аutovivification решает, да еще и проверки будут не в рантайме (как с решениями на основе tie и пр.), а еще при компиляции.
Кто-нибудь знает, когда ждать perl 6? Нигде внятной информации найти не могу :(
UFO just landed and posted this here
UFO just landed and posted this here
В Питоне есть аналог mod_perl?
Я вижу одну: CPAN.
UFO just landed and posted this here
Смотря какие задачи. Я на Ruby ради интереса и для более детального изучения синтаксиса пытался портировать готовое Perl приложение. Так вот местный Net::HTTP даже не умеет работать с плюшками, а во всех конференциях предлагают родить велосипед самому. Что уж говорить об LWP::Parallel и прочих радостях. CPAN - это то, благодаря чему Perl живет и довольно активно используется.
LWP::Parallel - это такой тормоз. В 3 раза медленнее PHP curl_multi... Я щас пытаюсь найти ему замену. На с наскока пока ничего не нашёл (можно чеерез fork + mhtttp (ghttp), но там нет https, cookie etc.).
Посмотрите у меня на сайте модули POWER::Multi::GET и POWER::Event::IO.
Первый (POWER::Multi::GET) был написан много лет назад как значительно более быстрая альтернатива LWP::Parallel (его скорость достигала в те времена 280 url/sec, а на современном железе возможно будет больше).
А второй был написан с целью исправить некоторые архитектурные недостатки первого. Во-первых он использует epoll, так что CPU жрёт значительно меньше. Во-вторых он использует событийную модель, так что в процессе выкачки url можно заниматься другими делами. Но для второго я ещё не реализовал поддержку HTTP как в первом (с куками, редиректами, etc.), так что это пока нужно делать ручками. Но его скорость в среднем 500 url/sec, судя по нашим тестам.
Использовалось это всё под Linux, и врядли будет работать под другими системами (второй - точно не будет, т.к. в других системах нет epoll).
Первый (POWER::Multi::GET) был написан много лет назад как значительно более быстрая альтернатива LWP::Parallel (его скорость достигала в те времена 280 url/sec, а на современном железе возможно будет больше).
А второй был написан с целью исправить некоторые архитектурные недостатки первого. Во-первых он использует epoll, так что CPU жрёт значительно меньше. Во-вторых он использует событийную модель, так что в процессе выкачки url можно заниматься другими делами. Но для второго я ещё не реализовал поддержку HTTP как в первом (с куками, редиректами, etc.), так что это пока нужно делать ручками. Но его скорость в среднем 500 url/sec, судя по нашим тестам.
Использовалось это всё под Linux, и врядли будет работать под другими системами (второй - точно не будет, т.к. в других системах нет epoll).
Спасибо за наводку! Я с epoll работал в прошлом через libevent (про select забыл, как про страшный сон). Жалко, что в событийном модуле нет поддержки cookie и redirects... Но 280 url/sec более чем достаточно. Главное, чтобы модуль был рабочий и не тормозил, как LWP::Parallel. Я сейчас также присматриваюсь к POE + POE::Component::Client::HTTP. Если был положительный/отрицательный опыт работы с этим модулем, с удовольствием выслушаю.
Если вы используете epoll напрямую, а не через обёртку вроде libevent, то на других системах отличных от Linux работать не будет наверно. Но если через libevent, то на freebsd должно, т.к. там есть аналог epoll'a - kqueue.
Если вы используете epoll напрямую, а не через обёртку вроде libevent, то на других системах отличных от Linux работать не будет наверно. Но если через libevent, то на freebsd должно, т.к. там есть аналог epoll'a - kqueue.
Для меня большой минус перла - то, что там слишком много свободы. Можно использовать скобки, можно не использовать. Можно писать "if (blabla) { tratata}", а можно "tratata if (blabla)" и т.д. Поначалу это казалось плюсом, но как только довелось работать в команде, выяснилось, что очень трудно читать чужой код. Поэтому очень важно, если работаешь в команде, жестко придерживаться неких code rules, первым пунктом где ОБЯЗАТЕЛЬНОЕ использование use strict.
Ну так в любом языке можно словить множество неудобств из-за различий в форматировании, например. Меня, к примеру, крайне раздражают отступы в 1-2 пробела :), идентификаторы типа с1, x2 итп (в любом языке!). Так что, естественно, при работе в команде нужен стандарт.
1. Нет наследования объектов.
Не понимаю - зачем в скриптовом языке использовать ООП...
Мне вот не нравится, что конструкция вида (1, 2, 3, (4, 5), 6) склеивается в один список и код вида. Ко всему остальному уже как-то привык
Первое предложе ние читать как "Мне вот не нравится, что конструкция вида (1, 2, 3, (4, 5), 6) склеивается в один список."
уродство этот perl по сравнению с ruby
то что не объектный это понятно уже давно, как и пхп... но писать коряво можно на любом языке, хоть тот же РУБИ или С++, еще как можно :)
кстати, а про константы, чем ему не нравиться такой метод
*CONST = 'Hello World';
$CONST = 'Good buy World'; # вызовет ошибку! все нормально
кстати, а про константы, чем ему не нравиться такой метод
*CONST = 'Hello World';
$CONST = 'Good buy World'; # вызовет ошибку! все нормально
Очень плохая статья. Человека, скорее относящегося равнодушно к perl!
Пользуюсь перлом довольно давно, в основном в качестве -pi-однострочников (ну, не люблю я sed/awk!) либо же для массовой обработки текстовых файлов.
Пробовал питон для второй задачи, но он у меня как-то не прижился. Стараюсь писать все перловые программы в C-стиле, иначе, действительно, потом хрен поймёшь, что же делает программа. Ну, а основное преимущество — это, конечно, CPAN.
Пробовал питон для второй задачи, но он у меня как-то не прижился. Стараюсь писать все перловые программы в C-стиле, иначе, действительно, потом хрен поймёшь, что же делает программа. Ну, а основное преимущество — это, конечно, CPAN.
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;
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;
По поводу функций и их inline. К сожалению, это работает далеко не всегда, например смотрите мой пост на perlmonks: Slow constants. Кроме того, read-only скаляры (созданные, например, так:
eval q{*O_NONBLOCK = \\}.O_NONBLOCK;) работают немного быстрее и обычных скаляров, и инлайнящихся функций! Об этом можно почитать в другом моём посте: Import constants as scalar instead of bareword sub.Естественно, компилятор не может оптимизировать то, чего нет на этапе компиляции - так что фолдинг не будет работать для динамически генерируемых функций (подозреваю, что и для XS тоже).
Вариант с readonly-переменными я тоже предлагал выше, ибо TMTOWTDI, но у него есть один очень серьезный недостаток: переменные, даже readonly, все-таки можно переопределить, причем случайно (что мешает мне обьявить my $O_NONBLOCK ?) - и компилятор/рантайм не выдаст при этом никаких сообщений! При переопределении же constant sub (не важно, через sub CONST {} или *CONST = sub) получим предупреждение: Constant subroutine main::CONST_NAME redefined (в случае sub CONST - еще на этапе компиляции).
Вариант с readonly-переменными я тоже предлагал выше, ибо TMTOWTDI, но у него есть один очень серьезный недостаток: переменные, даже readonly, все-таки можно переопределить, причем случайно (что мешает мне обьявить my $O_NONBLOCK ?) - и компилятор/рантайм не выдаст при этом никаких сообщений! При переопределении же constant sub (не важно, через sub CONST {} или *CONST = sub) получим предупреждение: Constant subroutine main::CONST_NAME redefined (в случае sub CONST - еще на этапе компиляции).
Это уже софистика пошла. А на самом деле всё иначе.
Да, "компилятор не может оптимизировать то, чего нет на этапе компиляции". Но проблема в том, что когда я подгружаю через use разные модули, я не могу заранее знать, на каком этапе эти модули генерируют/экспортируют константы - на этапе компиляции или на этапе выполнения. В доке такие нюансы обычно не упоминают, да и задолбаешься по каждому отдельному модулю это уточнять. Так что проблема таки есть!
Что касается объявления "my $O_NONBLOCK", то тут два нюанса. Во-первых существует соглашение, что в верхнем регистре пишутся только константы, так что "my $O_NONBLOCK" в середине кода - это красный флаг на который среагируют все квалифицированные программисты, и никто из них такого не напишет (если не хочет действительно переопределить эту константу, как грязный но нужный хак). А во-вторых никто не мешает через
Да, "компилятор не может оптимизировать то, чего нет на этапе компиляции". Но проблема в том, что когда я подгружаю через use разные модули, я не могу заранее знать, на каком этапе эти модули генерируют/экспортируют константы - на этапе компиляции или на этапе выполнения. В доке такие нюансы обычно не упоминают, да и задолбаешься по каждому отдельному модулю это уточнять. Так что проблема таки есть!
Что касается объявления "my $O_NONBLOCK", то тут два нюанса. Во-первых существует соглашение, что в верхнем регистре пишутся только константы, так что "my $O_NONBLOCK" в середине кода - это красный флаг на который среагируют все квалифицированные программисты, и никто из них такого не напишет (если не хочет действительно переопределить эту константу, как грязный но нужный хак). А во-вторых никто не мешает через
no warnings 'redefine' отключить предупреждение о переопределении константной процедуры и переопределить её так же тихо, как и скаляр через "my".
Весь перл - это один большой хак. В этом его сила и в этом его слабость.
Но перл - это всего лишь инструмент. Всё остальное - вопросы мастерства и дисциплины.
Можно сказать, что самурайски меч - это слишком неудобный дивайс, ибо его нельзя метнуть в голову врагу. И ещё он шибко острый, об него обрезаться можно.
Но перл - это всего лишь инструмент. Всё остальное - вопросы мастерства и дисциплины.
Можно сказать, что самурайски меч - это слишком неудобный дивайс, ибо его нельзя метнуть в голову врагу. И ещё он шибко острый, об него обрезаться можно.
cybermozg, подписываюсь под вашими словами.
Великий перл.
Прочесть пытался -
Ушел с почтением.
Прочесть пытался -
Ушел с почтением.
Решение для 8го пункта есть в сборнике рецептов Кристиансена. Я брал на natahause.ru, кажется.
perl вызовы функций вида sub foo { 42 } оптимизирует до простой подстановки значения, фактически функция вызываться не будет.
Sign up to leave a comment.
Why Perl sucks?