Comments 37
Оу. Пост про перл на хабре. Спасибо, почитал с удовольствием.
Про замыкания и аттрибуты очень полезно, пригодится.
Про замыкания и аттрибуты очень полезно, пригодится.
+17
UFO just landed and posted this here
Поддерживаю, отличная книга про функциональное программирование.
+1
Какая? Подскажите.
0
Если говорить про перл и функциональное программирование в целом, то вот эта книга:
hop.perl.plover.com
«Higher-Order Perl
by Mark Jason Dominus»
hop.perl.plover.com
«Higher-Order Perl
by Mark Jason Dominus»
0
Спасибо, познавательная статья. Всё-таки неспроста Perl широко распространён.
Это не касается только книг с Ламой, Альпакой и Верблюдом (“Learning Perl”, “Intermediate Perl” и “Programming Perl”) — мы настоятельно рекомендуем их прочитать.Что скажете о Modern Perl?
+3
«Modern Perl» появилась в тот момент, когда все классические книги по Perl давно не переиздавались. А при этом как раз возникал это самый обновленческий Modern Perl, появлялись новые техники и практики, которых в старых книгах не было, менялись взгляды на то, что раньше считалось нормой в написании кода. Так что на тот момент это была, можно сказать, единственная актуальная книга по Perl.
С появлением свежих версий классики актуальность её существенно уменьшилась, да и уровень изложения там не так высок. Но, тем не менее, внимания заслуживает, особенно для тех, кто не готов с ходу осилить что-то более объёмное. ;)
Я её переводил, кстати, если кому интересно на русском.
Исходники на Гитхабе: github.com/timurn/modern_perl_book/tree/russian_translation.
Сайт: modernperlbook.ru (до конца так и не докрутили, но читать можно).
С появлением свежих версий классики актуальность её существенно уменьшилась, да и уровень изложения там не так высок. Но, тем не менее, внимания заслуживает, особенно для тех, кто не готов с ходу осилить что-то более объёмное. ;)
Я её переводил, кстати, если кому интересно на русском.
Исходники на Гитхабе: github.com/timurn/modern_perl_book/tree/russian_translation.
Сайт: modernperlbook.ru (до конца так и не докрутили, но читать можно).
+3
UFO just landed and posted this here
Эталонно оформленная статья, добавил в избранное для семинаров :)
+8
Работаю с perl более 10 лет. Статью почитал с большим интересом. Спасибо!
+3
UFO just landed and posted this here
Реквестирую такую же подробную статью про plack
0
Кстати, про Plack есть цикл статей в PragmaticPerl:
статья 1,
статья 2,
статья 3,
статья 4,
статья про разворачивание Plack-приложения.
Есть совсем краткое введение-инструкция здесь:
про Plack вообще,
про Plack + SOAP.
статья 1,
статья 2,
статья 3,
статья 4,
статья про разворачивание Plack-приложения.
Есть совсем краткое введение-инструкция здесь:
про Plack вообще,
про Plack + SOAP.
0
Первый пример не очень получился. Лучше так:
Вообще написание хороших примеров — это особое исскусство.
Статья получилась отличная. Только недавно просил на ru.pm чтобы кто-нибудь написал сводную статью про функции. Не хватает только сигнатур из 5.20
Вот хороший однострочник для затравки:
sub mySub { my $var = @_; print $var; }
Если вызвать данную функцию как mySub('a', 'b', 'c') в $var мы внезапно получим не 'a', а 3.
Вообще написание хороших примеров — это особое исскусство.
Статья получилась отличная. Только недавно просил на ru.pm чтобы кто-нибудь написал сводную статью про функции. Не хватает только сигнатур из 5.20
Вот хороший однострочник для затравки:
perl -E 'say "kaboom" if bomb; $because=bareword; say $because'
+6
Всегда любил перл.
Но когда в коде используешь все его специфические «фишки», не покидает очень своеобразное ощущение, что рассказываешь очень специфический анекдот, которого не поймет никто.
Но когда в коде используешь все его специфические «фишки», не покидает очень своеобразное ощущение, что рассказываешь очень специфический анекдот, которого не поймет никто.
+8
Отличная статья. Освежил память и узнал про атрибуты:)
Хочу поинтересоваться, а как Вы относитесь к использованию модулей? Например, мой типичный набор для функций и методов включает в себя Params::Validate и аналогичные (например MooseX::Params::Validate), что позволяет более точно контроллировать данные на входе.
Хочу поинтересоваться, а как Вы относитесь к использованию модулей? Например, мой типичный набор для функций и методов включает в себя Params::Validate и аналогичные (например MooseX::Params::Validate), что позволяет более точно контроллировать данные на входе.
0
Перл Хабр!
+5
Последний пример сломан же, не? Скорее всего имелось в виду что–то типа:
*{$symbol} = sub {
if(is_auth()) {
goto &$referent;
}
else {
require Carp;
Carp::croak "nope";
}
};
0
Спасибо, goto там было лишним, исправлено, однако пример не сломан. Дело в том, что если проверка атрибутов проходит успешно далее вызывается эта самая функция и goto не нужен. В данном случае проверка атрибутов выполняется успешно, если is_auth возвращает 1.
Я писал большую статью в pragmaticperl по атрибутам и более подробно рассматривал подробные примеры.
Я писал большую статью в pragmaticperl по атрибутам и более подробно рассматривал подробные примеры.
0
UFO just landed and posted this here
Многие давно используют нормальные функции и методы (например, MooseX::Method::Signatures):
Ну и напомню — habrahabr.ru/post/52532/
method hello (Str :$who, Int :$age where { $_ > 0 }) {
$self->say("Hello ${who}, I am ${age} years old!");
}
Ну и напомню — habrahabr.ru/post/52532/
0
Приятно удивлён, что статья про perl на хабре встречена позитивно)
Вопрос авторам статьи: каково ваше мнение про perl6? Взлетит или нет? Как там вообще прогресс, есть?
Вопрос авторам статьи: каково ваше мнение про perl6? Взлетит или нет? Как там вообще прогресс, есть?
0
На этот вопрос вряд ли могут достоверно ответить даже авторы Perl 6, что уж там говорить про авторов статьи.
Пока Perl 6 — это академический проект. Взлетит — хорошо, не взлетит — для пользователей Perl 5 всё равно вряд ли что-то кардинально от этого изменится. Строить же свои проекты или свою карьеру с расчётом на Perl 6 пока однозначно не стоит.
Пока Perl 6 — это академический проект. Взлетит — хорошо, не взлетит — для пользователей Perl 5 всё равно вряд ли что-то кардинально от этого изменится. Строить же свои проекты или свою карьеру с расчётом на Perl 6 пока однозначно не стоит.
+1
Интересная статья.
Мне кажется, что ещё более интересной и полезной была бы статья о стиле программирования на перле, который не приводит к проблемам поддержки и отладки программ. Что я имею ввиду:
Например, генерация методов на лету, — приводит к тому, что функция то есть, то её нет в зависимости от переданных параметров. Когда-то это полезно, конечно, но если этим увлекаться, то поиск места объявления такой функции превращается в квест. AUTOLOAD сам по себе приносит больше проблем чем пользы, мне кажется. Да, это дополнительные возможности, но и дополнительные проблемы, иногда через несколько лет после написания программы. Хотя многие синтаксические сахары именно на определении на лету и AUTOLOAD построены. Но отлаживать их просто ад.
Приведённый пример с isAuth выглядит привлекательным, но всё хорошо пока есть привычка именно к такому стилю программирования. Не говоря о экспериментальном характере атрибутов. Тот же каталист по неизвестным причинам проигрывает неатрибутному Rose в скорости на порядок. И вообще если для использования какой-то части языка нужен специальный модуль — это уже повод задуматься.
MooseX::Method::Signatures, MooseX::Declare выглядят хорошо, но с ними не дружат некоторые перловые IDE. Не считая что это ещё и Moose.
Прототипы теоретически хорошо, но практически мало где используется. Проблем от них больше чем пользы, Params::Validate удобнее. Этот момент давно надо было бы улучшить в перле.
Насчёт бесскобочных функций как-то невнятно сказано, что все функции можно вызывать без скобок. Главное, чтобы это была именно функция, что достигается либо её объявлением в use subs, либо обычным определением. При чём тут третий путь — прототипы — непонятно.
Мне кажется, что ещё более интересной и полезной была бы статья о стиле программирования на перле, который не приводит к проблемам поддержки и отладки программ. Что я имею ввиду:
Например, генерация методов на лету, — приводит к тому, что функция то есть, то её нет в зависимости от переданных параметров. Когда-то это полезно, конечно, но если этим увлекаться, то поиск места объявления такой функции превращается в квест. AUTOLOAD сам по себе приносит больше проблем чем пользы, мне кажется. Да, это дополнительные возможности, но и дополнительные проблемы, иногда через несколько лет после написания программы. Хотя многие синтаксические сахары именно на определении на лету и AUTOLOAD построены. Но отлаживать их просто ад.
Приведённый пример с isAuth выглядит привлекательным, но всё хорошо пока есть привычка именно к такому стилю программирования. Не говоря о экспериментальном характере атрибутов. Тот же каталист по неизвестным причинам проигрывает неатрибутному Rose в скорости на порядок. И вообще если для использования какой-то части языка нужен специальный модуль — это уже повод задуматься.
MooseX::Method::Signatures, MooseX::Declare выглядят хорошо, но с ними не дружат некоторые перловые IDE. Не считая что это ещё и Moose.
Прототипы теоретически хорошо, но практически мало где используется. Проблем от них больше чем пользы, Params::Validate удобнее. Этот момент давно надо было бы улучшить в перле.
Насчёт бесскобочных функций как-то невнятно сказано, что все функции можно вызывать без скобок. Главное, чтобы это была именно функция, что достигается либо её объявлением в use subs, либо обычным определением. При чём тут третий путь — прототипы — непонятно.
0
Насчет прототипов. Например, константы в Perl это функции с пустым прототипом ().
0
Например, генерация методов на лету, — приводит к тому, что функция то есть, то её нет в зависимости от переданных параметров. Когда-то это полезно, конечно, но если этим увлекаться, то поиск места объявления такой функции превращается в квест.
Вот у нас есть Redis, у него несколько БД, у каждой БД свой индекс (для команды select), свои таймауты (в зависимости от паттерна использования), список БД redis хранится в конфиге.
Сделали автогенерации функций на стадии компиляции модуля:
r_somedb
, r_anotherdb
— возвращает нужный коннект. Т.е. r_somedb->somecommand
выполняет нужную команду. Всё документировали. Написали тесты.Без автогенерации пришлось бы делать что-то вроде
redis("somedb")->somecommand
, при этом в "somedb"
не должно быть опечатки. Или сделать константу SOMEDB => "somedb"
, что опять, является дубликатом конфига, и использовать redis(SOMEDB)->somecommand
. В итоге это было бы неудобно, т.к. такое обращение используется в сотнях строчек кода.AUTOLOAD сам по себе приносит больше проблем чем пользы, мне кажется.
Опять про Redis: Есть CPAN модули Redis и Redis::Fast. В обоих модуль не знает полный список команд сервера Redis. И выполняет любую команду вызванную как функцию. Т.е.
$redis->mget
$redis->get
— всё это обрабатывается AUTOLOAD.И вообще если для использования какой-то части языка нужен специальный модуль — это уже повод задуматься.
Например, для использования наследования нужен специальный модуль.
use parent
или use base
. Напрямую @ISA
не принято писать.Ещё для экспортирования функций используют
use Exporeter
. Эти модули как и Attribute::Handlers
— модули ядра.-1
Написать проблемный, потенциально бажный, неотлаживаемый, неподдерживаемый и т. п. код можно и с использованием самых простых конструкций языка. Причём, наверное, любого языка.
Так что нужно просто включать мозг в каждом конкретном случае. И иметь какие-то правила и отстроенное взаимодействие внутри проекта. А какой-то такой универсальный стиль программирования, позволяющий писать любые программы так, чтобы всё было шоколадно, вряд ли существует.
Так что нужно просто включать мозг в каждом конкретном случае. И иметь какие-то правила и отстроенное взаимодействие внутри проекта. А какой-то такой универсальный стиль программирования, позволяющий писать любые программы так, чтобы всё было шоколадно, вряд ли существует.
0
Еще по поводу прототипов:
Обычно все говорят как и никто не говорит зачем.
В Perl есть хорошо известное соглашение про передачу параметров в пользовательские функций.
Но некоторые встроенные функции работают немного не по этому соглашению.
Так вот: прототипы в Perl нужны с единственной целью — позволить программистам делать так же.
Как правило это удобно для очень низкоуровневых функций для работы с данными и блоками.
В прикладной же разработке — почти нафиг не нужно.
Пожалуйста, подумайте дважды прежде чем писать прототип: вы точно делаете новый map?
Пока видел одно достойное применение прототипов — Try::Tiny и аналоги.
Обычно все говорят как и никто не говорит зачем.
В Perl есть хорошо известное соглашение про передачу параметров в пользовательские функций.
Но некоторые встроенные функции работают немного не по этому соглашению.
push @arr, $elem; # @arr не сливается в один список с $elem.
Так вот: прототипы в Perl нужны с единственной целью — позволить программистам делать так же.
Как правило это удобно для очень низкоуровневых функций для работы с данными и блоками.
В прикладной же разработке — почти нафиг не нужно.
Пожалуйста, подумайте дважды прежде чем писать прототип: вы точно делаете новый map?
Пока видел одно достойное применение прототипов — Try::Tiny и аналоги.
+4
Пользуясь случаем предлагаю перловикам присоединиться к поддержке любимого языка. secure.donor.com/pf012/give
donate.perlfoundation.org/donate.html
donate.perlfoundation.org/donate.html
0
Sign up to leave a comment.
Функции в Perl