Как стать автором
Обновить

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

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

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

Но сил на это уже нет. Два часа переводил, пол часа форматировал, а выдохся так, будто вагон разгружал. Вероятно, это связано с тем, что это мой первый перевод - до этого момента я предпочитал писать сам, а не переводить. Но эта статья очень понравилась, давно сам такое хотел написать. И, в общем и целом, в ней всё верно... хотя попридираться можно, если бы силы остались. :)
Это от желания поскорее выложить :) Можно же перевести, на следующий день на свежую голову вычитать и поправить.
огромное спасибо за перевод, инетресная статья. Как раз разбираюсь с Perl 6 и приятно видить, что сохраняя всю мощь, как раз описанные sucks старательно исправляют.
Интересно было-бы почитать о сравнении PERL с PHP.
Ага. На хабре только этого flamewar нехватало для полного счастья. Лучше сделаем так - выше статья по недостаткам Perl, а вот статья по недостаткам PHP: К вопросу об ублюдочности PHP. На всякий случай, как и автор этой статьи уточню - речь не идёт о том, что "Perl rulez, PHP suxx", это просто описание недостатков PHP, а Perl иногда упоминается просто для сравнения, не более того. Все языки важны, все языки нужны. Ом!
Прочитал по диагонали. Скажем так: не совсем правда. Но это обсуждение для отдельной статьи.
Прочитал полностью. По пунктам которые там указаны
1. Такой разброс в названии функций, как ме кажется связан с тем что php разрабатывают/дорабатывают много людей, и если бы сейчас хотели бы упорядочить названия функций, было бы довольно сложно это сделать
2. Количество функций. Мне кажется, что именно поэтому php и популярен. Из за огромного количества функций которые могут выполнять рутинную работу. А то что они все сразу доступны. Опять же связано с архитектурой php
3. Насчет пространства имен, автор прав. Но к сожаленью например я, уже давно привык к этому =)
5. Бейте меня, но мне очень нравится работа с массивами в php. А для сравнения типов есть ===. Или при проверке, просто приводите переменную которую сравниваете к нужному типу.
6. Не хочу комментировать, так как сам начинаю задумывать насчет серьезности php

Хочу сказать что это всё, мое личное субьективное мнение. Я не гуру программинга на php и возможно что то говорю не правильно.
А насчет статьи про perl, то я бы лично не хотел говорить насчет его недостатках и говорить что он хуже php, так как такие языки как perl возникли сравнительно давно, и используются не только в вебе(в плане синтаксиса). Для меня лично, perl представляется эдаким пожилым мужчиной, а php молодым, постоянно куда то бегущим юнцом =)
А питон вообще змея :D
Было бы скорее интересно почитать о преимуществах Perl. Например: что в нём есть кроме регэкспов?
Регекспы много где есть. Просто в перле ими несколько более удобно пользоваться.
почему удобней? чем?
Смотря по сравнению с чем. По сравнению с PHP — явно удобнее. Например, regexp в Perl — отдельный типа, а в PHP он передаётся через строку. Из-за этого, иногда, возникает дикое количество слешей для экранирования.
Удобнее - тем, что есть синтаксический сахар. Строка
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 }

Это, конечно, просто зарядка для ума и развлечение, но возможности демонстрирует.
Пожалуй паскалевский код прочитать быстрее.
Хотя для тех кто пользует perl ежедневно пару лет и уже думает на нем, это наверное и не так.
Ну, если рассматривать только вариант ckinn10, то он понятнее. Но я люблю такие развлечения
Думаю, такая регекспина будет работать едва ли не дольше чем паскалевские функции, да и читаюстся они легче.
P.S. Я ни в коем случае не умоляю достоинств регулярных выражений, даже напротив время от времени ломаю об них мозг :)
А если конкретно и не касаясь регэкспов.
Эка тему я в своё время подкинул... :)))
вот из-за таких конструкций программисты и выбирают php, а не perl :)
когда delphi-с-программисту приходится быстро переходить на web-порграммирование, причём нет полгода на обучение, а проект нужно сдать через месяц
А потом мы спрашиваем откуда такое огромное количество ужасного кода в web-проектах...
Спасибо, интересно.

P.S. А аutovivification, по моему мнению, скорее плюс чем минус.
Я бы сказал, что это был бы плюс, если бы в перле были честные классы.

Но сейчас классы это, по сути, хэши. Отсюда и растёт желание убрать аutovivification для некоторых конкретных хэшей.
В некоторых конкретных случаях можно включить варнинг использования несуществующих ключей. Хотя это нельзя назвать решением.
А ещё lock_keys of Hash::Util.
use fields в помощь. Проблему с аutovivification решает, да еще и проверки будут не в рантайме (как с решениями на основе tie и пр.), а еще при компиляции.
Кто-нибудь знает, когда ждать perl 6? Нигде внятной информации найти не могу :(
когда будет готов :) так говорят разработчики. мне самому дико интересно, потому, что то, что получается мне кажется отличным языком.
Не в этом году - это точно :(
Где-то слышал, что Ларри обещал в мае... Уже июнь... Неужели правда не в этом году? Ссылка на источник есть?
Он уже седьмой год только и делает, что обещает :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это вы зря, у питона библиотека очень даже не маленькая. И скрипты автоматизации пишутся. Другое дело, что perl более привычен для многих в этой сфере.
может и немаленькая, но в перле документация ощутимо лучше той, что есть в питоне. поэтому для большинства применений в перле читаем документацию и пишем, а в питоне — сидим и экспериментируем.
В Питоне есть аналог mod_perl?
mod_python - это оно и есть?
Я вижу одну: CPAN.
НЛО прилетело и опубликовало эту надпись здесь
Смотря какие задачи. Я на 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).
Спасибо за наводку! Я с epoll работал в прошлом через libevent (про select забыл, как про страшный сон). Жалко, что в событийном модуле нет поддержки cookie и redirects... Но 280 url/sec более чем достаточно. Главное, чтобы модуль был рабочий и не тормозил, как LWP::Parallel. Я сейчас также присматриваюсь к POE + POE::Component::Client::HTTP. Если был положительный/отрицательный опыт работы с этим модулем, с удовольствием выслушаю.

Если вы используете epoll напрямую, а не через обёртку вроде libevent, то на других системах отличных от Linux работать не будет наверно. Но если через libevent, то на freebsd должно, т.к. там есть аналог epoll'a - kqueue.
Для меня большой минус перла - то, что там слишком много свободы. Можно использовать скобки, можно не использовать. Можно писать "if (blabla) { tratata}", а можно "tratata if (blabla)" и т.д. Поначалу это казалось плюсом, но как только довелось работать в команде, выяснилось, что очень трудно читать чужой код. Поэтому очень важно, если работаешь в команде, жестко придерживаться неких code rules, первым пунктом где ОБЯЗАТЕЛЬНОЕ использование use strict.
Ну так в любом языке можно словить множество неудобств из-за различий в форматировании, например. Меня, к примеру, крайне раздражают отступы в 1-2 пробела :), идентификаторы типа с1, x2 итп (в любом языке!). Так что, естественно, при работе в команде нужен стандарт.
форматирование в том числе, но я не только про него говорил. уж слишком много вольности, а без use strict так просто бардак.
Ну если вы разрабатываете большой проект, то надо использовать соглашения о кодировании, а с ними обычно код на всех языках очень похож. В маленьких скриптиках "для себя" strict иногда мешает и я его там не использую вообще.
можно пример, когда strict мешает?
Без use strict получается PHP ;)
1. Нет наследования объектов.

Не понимаю - зачем в скриптовом языке использовать ООП...
Perl это еще и объектно-ориентированный язык, просто "ориентация" там .. хм.. другая :)
Мне вот не нравится, что конструкция вида (1, 2, 3, (4, 5), 6) склеивается в один список и код вида. Ко всему остальному уже как-то привык
Первое предложе ние читать как "Мне вот не нравится, что конструкция вида (1, 2, 3, (4, 5), 6) склеивается в один список."
пиши (1, 2, 3, [4, 5], 6) :)
Это несколько другая вещь. По идее () - это список скаляров. Так вот когда я подставляю вместо одного из скаляров список, по идее должен срабатывать скалярный контекст на список, ан нет, списки склеиваются
А, вон ты про что. Видимо автор языка решил, что объединение списков понадобится чаще, чем преобразование списка в скаляр.
уродство этот perl по сравнению с ruby
то что не объектный это понятно уже давно, как и пхп... но писать коряво можно на любом языке, хоть тот же РУБИ или С++, еще как можно :)

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

*CONST = 'Hello World';

$CONST = 'Good buy World'; # вызовет ошибку! все нормально
вот так правильнее *CONST = \'Hello World';
Очень плохая статья. Человека, скорее относящегося равнодушно к perl!
Пользуюсь перлом довольно давно, в основном в качестве -pi-однострочников (ну, не люблю я sed/awk!) либо же для массовой обработки текстовых файлов.

Пробовал питон для второй задачи, но он у меня как-то не прижился. Стараюсь писать все перловые программы в 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;
По поводу функций и их 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 - еще на этапе компиляции).
Это уже софистика пошла. А на самом деле всё иначе.

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

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

Можно сказать, что самурайски меч - это слишком неудобный дивайс, ибо его нельзя метнуть в голову врагу. И ещё он шибко острый, об него обрезаться можно.
cybermozg, подписываюсь под вашими словами.
Великий перл.
Прочесть пытался -
Ушел с почтением.
Решение для 8го пункта есть в сборнике рецептов Кристиансена. Я брал на natahause.ru, кажется.
perl вызовы функций вида sub foo { 42 } оптимизирует до простой подстановки значения, фактически функция вызываться не будет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории