Работаю в небольшой компании (~30 человек в московском офисе). Доволен. Нравится, что работаю не со всякими «проджект менеджерами», а непосредственно с опытным техническим директором (он — что-то вроде «играющего тренера», т.е. не только руководит, но и учавствует в разработке).
Особым плюсом в моем случае является то, что нашей компанией частично владеет другая, большая и международная. Мы сидим в их офисе, имеем ограниченный, но все-таки доступ, к их ресурсам. И при все при этом мы сами по себе (не считая совместных проектов).
Пример всего-лишь указывал, что можно посмотреть в сторону BUILD. Код я написал, что называется «от балды». С SUPER, пожалуй, получилось и правда не очень удачно, т.к. кажется как-будто я пытаюсь вернуть другой объект. Можно чуть подправить и сделать вот так (в итоге получается почти то же самое):
sub BUILD {
my $self = shift;
# some checks
unless($success) {
$self->errstr('bla')
}
}
# ...
my $foo = Foo->new;
die $foo->errstr if $foo->has_errstr;
10k тоже неплохо, особенно учитывая что у вас «дохлый нотебук»)
А если для динамического контента использовать erlang-web или erlydtl, которые хранят шаблоны в скомпилированном виде (и имеют более сносный синтаксис), то думаю скорость обработки окажется тоже на уровне.
Но это, конечно, все мои догадки. Поэтому и написал, что интересно было бы увидеть бенч в сравнении с YAWS.
По большей части это реализовано с помощью модуля Devel::Declare. А вот уж как он работает, я подробно объяснить не могу, к сожалению. Часть его написана с помощью XS. Короче «hairy black magic».
Сбербанковской Visa Electron можно платить в интернете при наличии некого однаразового кода, который можно получить или в специальном банкомате (которых в Москве не так уж много), или в локальном отделении.
Пример получается довольно надуманный, но к сожалению в голову больше ничего не пришло: класс-«внук» не сможет сохранить часть функционала от дочернего класса первого уровня. Вы можете только целиком переопределить метод. А выделять для каждого нового уровня наследования отдельный метод — не есть хорошо. Хотя наличие таких проблем возможно является символом того, что в проектировании имеются недостатки.
Не поймите меня неправильно, я ведь не агитирую использование этого приема. Я рассказал, что так можно делать, и что мне удалось найти место, где (на мой взгляд) это оказалось уместно.
Сравнение с джавой, имхо, некорректно. Да, Perl6 сильно отличается от 5, но все-таки он не является полностью новым языком. Как ни крути, а я уверен, что многие мигруют на 6 после релиза. Даже разработчики агитируют к этому. Поэтому делать прослойку из Perl5 в Perl6 имеет смысл, а вот из Perl в Java — нет.
Когда я увидел первые наброски синтаксиса Perl6 (особенно гипер-операторы), я был уверен, что я не буду его использовать. Сейчас я уже не так уверен. Конечно, legacy-код никуда не денется, но для новых проектов я возможно буду использовать 6 версию.
Я привел недостаточно сложный пример. augment+inner имеет неограниченную глубину вложенности. Можно аугментировать уже аугментированные методы (естественно не в одном классе, а в дочерних). А простое переопределение метода скорее всего приведет к дублированию кода. Но, да, в целом я согласен, что это «сложность» и не стоит ей злоупотреблять.
На мой взгляд, это просто прослойка, которая поможет многим справиться с Perl6. Не хотите? Да пожалуйста, не надо. Можно писать очень стройные вещи используя и просто Moose. Но мне нравится, да)
А люди вот думают (а главное и делают) по другому. В качестве примера вам — BBC Corp. У них внутри довольно активно используется перл, и сейчас его рефакторят с использованием Moose.
Тем более, что перл конечно же остается перлом. Вся его гибкость и свобода, которую он предоставляет разработчику, остается.
Как часть лексического анализа — да.
Изначально ведь имелось ввиду, что интерпретатор написать можно, а вот простой парсер нет. Человек выше написал, что «Only perl (интерпретатор) can parse Perl (язык)». Parse, а не evaluate. Парсинг не подразумевает исполнение.
www.youtube.com/watch?v=KyLqUf4cdwc
Особым плюсом в моем случае является то, что нашей компанией частично владеет другая, большая и международная. Мы сидим в их офисе, имеем ограниченный, но все-таки доступ, к их ресурсам. И при все при этом мы сами по себе (не считая совместных проектов).
sub BUILD { my $self = shift; # some checks unless($success) { $self->errstr('bla') } } # ... my $foo = Foo->new; die $foo->errstr if $foo->has_errstr;А если для динамического контента использовать erlang-web или erlydtl, которые хранят шаблоны в скомпилированном виде (и имеют более сносный синтаксис), то думаю скорость обработки окажется тоже на уровне.
Но это, конечно, все мои догадки. Поэтому и написал, что интересно было бы увидеть бенч в сравнении с YAWS.
Не поймите меня неправильно, я ведь не агитирую использование этого приема. Я рассказал, что так можно делать, и что мне удалось найти место, где (на мой взгляд) это оказалось уместно.
Сравнение с джавой, имхо, некорректно. Да, Perl6 сильно отличается от 5, но все-таки он не является полностью новым языком. Как ни крути, а я уверен, что многие мигруют на 6 после релиза. Даже разработчики агитируют к этому. Поэтому делать прослойку из Perl5 в Perl6 имеет смысл, а вот из Perl в Java — нет.
Когда я увидел первые наброски синтаксиса Perl6 (особенно гипер-операторы), я был уверен, что я не буду его использовать. Сейчас я уже не так уверен. Конечно, legacy-код никуда не денется, но для новых проектов я возможно буду использовать 6 версию.
На мой взгляд, это просто прослойка, которая поможет многим справиться с Perl6. Не хотите? Да пожалуйста, не надо. Можно писать очень стройные вещи используя и просто Moose. Но мне нравится, да)
Тем более, что перл конечно же остается перлом. Вся его гибкость и свобода, которую он предоставляет разработчику, остается.
Изначально ведь имелось ввиду, что интерпретатор написать можно, а вот простой парсер нет. Человек выше написал, что «Only perl (интерпретатор) can parse Perl (язык)». Parse, а не evaluate. Парсинг не подразумевает исполнение.
whatever / 25 ; # / ; die "this dies!";
Без выполнения кода (чтобы узнать прототип whatever) нельзя сказать, как отработает этот код.
Человек все правильно написал, различайте evaluate и parse. Статический парсинг перла невозможен.