пятница, 31 июля 2009 г.

Причины популярности PHP на фоне Perl Web Frameworks

Я не согласен с автором заметки Причины стремительного успеха PHP.

Истоки PHP находятся в Perl. Он один из многих. Но он "застолбил" себе расширение файлов php, в то время, как другие использовали расширение cgi в каталоге /cgi-bin/, или "цепляли" свой Perl обработчик на страницы с расширением htm или html.
PHP выделился, он стал узнаваемый - а это 80% успеха. Остальные же оставались безликим множеством.

Следующим по значению фактом является то, что в те далекие времена поисковые машины не индексировали динамику, не индексировали ничего, что находилось в каталоге /cgi-bin/. Поэтому сайты на PHP были целиком известны поисковикам, а на Perl не всегда. Ведь большинство в то время не могли использовать Perl скрипты вне каталога /cgi-bin/ или не знали о такой возможности.

Мой первый хостер для статики предоставлял url следующего вида: http://hoster/~user/, а для cgi - http://hoster/cgi-bin/user.
PHP в то время обычно также ставился в каталог cgi-bin, но Apache был настроен на обработку расширения php.
Вот и третья причина: url http://server/foo.php выглядит более красивым, чем http://server/cgi-bin/project.cgi?foo.
Кажется пустяк, но психология так не считает.

Я уверен, что если бы Perl сообществу в те далекие времена удалось бы "протолкнуть" в Apache настройки поумолчанию привязку расширения, например, plp к виртуальному обработчику /cgi-bin/plp.cgi, а с Perl поставлялся бы простой обработчик plp.cgi (обработчик-каркас), то сегодня расстановка сил была бы иной.

Но история не имеет сослагательного наклонения.

пятница, 24 июля 2009 г.

Невидимый Perl

Недавно один знакомый удивленно спросил: "А разве проект N не был статическим?". "Нет", - ответил я: "он изначально был полностью написан на Perl".

На момент создания проекта его основной целью было SEO исследование, объектом которого являлся Google.
В те далекие времена поисковики не индексировали динамику, поэтому проект извне виделся как набор статических HTML страниц.
Проект выполнил свою SEO задачу на отлично и был передан дочерней структуре.

Дальнейшая судьба проект протекала без моего участия. У проекта появились новые цели, сменился дизайн и одновременно проект был почти полностью переписан на PHP. Именно смена расширения HTML страниц вызвала вопрос с которого начата эта заметка.

Зачем я рассказал эту историю? Даже не знаю. Наверно чтобы сказать, что вокруг существует множество проектов на Perl, но не видно как и на чем они сделаны. Вот такой невидимый Perl.

пятница, 17 июля 2009 г.

Аспектно-ориентированное программирование в Perl

Существует замечательные модуль Memoize, который оборачивает указанные подпрограммы чтобы предотвратить их идентичные повторные вызовы и быстро вернуть ранее вычисленный результат. Модуль позволяет в качестве хранилища использовать не только память, но и любой другой объект, связанный с хешем. Также имеется возможность снять "обертку".

В терминах Аспектно-ориентированного программирования модуль Memoize является аспектом, который применяет к указанным подпрограммам.

Частичная реализация Аспектно-ориентированного программирования в Perl осуществляется модулем Aspect.
Этот модуль позволяет применять аспекты по маске ко множеству подпрограмм или к модулям целиком.
Кроме точки применения аспекта "before", существует также точка "after". Аспекты можно применять так, что при выходе из текущей лексической области видимости, они будет автоматически сняты.

Элементы Aspect-ориентированного программирования имеются и в Moose (Moose::Manual::MethodModifiers).
Аспекты очень гармонично сочетаются с ролями (Moose::Manual::Roles).

В Perl6 поддержка Aspect-ориентированного программирования сделана на уровне самого языка.

среда, 8 июля 2009 г.

Tailcall оптимизация в Perl5

Еду вчера вечером домой и с интересом наблюдаю за хаотичным блужданием мыслей в своей голове. Так забавно! И вдруг, в мгновение ока все замирает и тут же исчезает - остается лишь одна единственная мысль. Мысль о том, что "все-таки она вертится". То есть - существует. Это я о tailcall оптимизации в Perl5.

B одной заметке из цикла "Сегодня без..." было упомянуто, что в Per5, в отличии от Perl6, нет tailcall оптимизации. Так вот, это утверждение не совсем корректное. Да, в Perl5 нет автоматической tailcall оптимизации, но ее можно сделать вручную при помощи выражения "goto &NAME".

В качестве примера узнаем чему равен факториал десяти тысяч:

sub fact {
my ($i) = @_;
if ($i) {
return $i * fact($i - 1);
} else {
return 1;
}
}

Хотя, зачем мне знать это большое число? Да и кто на практике считать факториал рекурсией, если можно циклом. Но пример есть пример. И так, запускаем код на выполнение - Perl выводит предупреждение о слишком глубокой рекурсии и начинает "пухнуть", пытаясь вычислить факториал. Ой, память закончилась...

Перепишем подпрограмму для tailcall оптимизации:

sub fact { _fact(1, $_[0]) }
sub _fact {
my ($r, $i) = @_;
if ($i) {
return _fact($r * $i, $i - 1);
} else {
return $r;
}
}

Результат вычисления, как и следовало ожидать, такой же - нехватка памяти.

А теперь воспользуемся магией "goto &NAME" и сделаем tailcall:

sub _fact {
my ($r, $i) = @_;
if ($i) {
@_ = ($r * $i, $i - 1);
goto &_fact;
} else {
return $r;
}
}

Да... Большое число вышло: 35 с половиной тысяч знаков (использовалась прагма bigint).

Вывод. Не перестаю удивляться возможностям Perl в умелых руках.

среда, 1 июля 2009 г.

Parrot: PIR, PASM и L1


PASM слишком низкоуровневый для человека и
слишком высокоуровневый для машины.

Часть критического кода, используемого виртуальной машиной Parrot, написана на PIR, а часть на С. Постоянное переключение между этими слоями: PASM (PIR) регистрами и C стеком, - существенно снижает производительность Parrot.

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

Однако не все, что хотелось, можно переписать с C на PIR.

В связи с этим в среде разработчиков Parrot ведутся обсуждения о создании внутреннего языка специального назначения, известного под рабочим названием L1. Это язык будет максимально простым и быстрым.
Если провести аналогию с процессорами, то L1 - это аналог микрокода, на котором реализованы CISC команды поверх RICS ядра процессоров таких как x86.

По аналогии с PIR (PASM) L1 будет компилироваться в байткод L1BC, который будет исполнятся подсистемой, условно называемой nanoparrot.

Не надо пугаться, обычной PBC никуда не денется! Он будет на лету транслироваться в L1. Так что разработчики компиляторов языков высокого уровня ничего и не заметят, кроме прироста производительности! :-)

В заключении можно сказать, что:
PASM - слишком низкоуровневый для человека и появился PIR.
PASM - слишком высокоуровневый для машины и создается L1.

P.S.
Ссылки по теме:
https://trac.parrot.org/parrot/wiki/L1Recap
http://wknight8111.blogspot.com