LINUX.ORG.RU

22-й выпуск журнала Pragmatic Perl

 , ,


1

2

Вышел 22-й выпуск журнала о современном Perl. В этом выпуске:

>>> Подробности

доктор сказал «в морг», значит в морг (с).

halturin ★★★★★ ()
Ответ на: комментарий от aembers_guggenheim

Тут не новость про журнал, тут ссылки на его содержимое. Это ОК, как мне кажется.

Shaman007 ★★★★★ ()

Прагматический подход к перлу заключается в том, что писать на нём новый код не нужно.

anonymous ()

Perl 6

Шитов

Этим все сказано!

anonymous ()
Ответ на: комментарий от anonymous

Неосиляторы боятся синтсаксиса и возможностей перла, поэтому раз за разом клепаются новые динамически-типизированные язычки (екмаскрипт, гвидо, похапе, руби итд) содержащие крошечное подмножество перла, вмещающееся в крохотные мозжечки неосиляторов и не причиняющее им анальной боли. Таким образом, из -за тупости и играниченности неосиляторов количестов ненужно растет год от года.

anonymous ()

Автор хочет дать еще один шанс шестому перлу

Надо же, действующий некромант

Gvidon ★★★★ ()

Perl 6 XXI века, Андрей Шитов Автор хочет дать еще один шанс шестому перлу

...

my @list = (10, 20, 30);
...

Однако, сразу можно воспользоваться преимуществами синтаксиса Perl 6 и записать те же инструкции, используя меньшее число символов и пунктуации:

my @list1 = <10 20 30>;
Или даже так (вообще кайф):
my @list2 = 10, 20, 30;

Это победа!

qaqa ()
Ответ на: комментарий от anonymous

прагматический подход к тем, кто говорит «не нужно» только из принципа, заключается в том, чтобы слать занести их в список «недалёких личностей» и игнорировать в дальнейшем.

pef-secure ()
Ответ на: комментарий от Shaman007

Если этот формат ок, то буду и дальше добавлять анонсы. Надеюсь, что холиварщикам интересно будет :)

pragmaticperl ()
Ответ на: комментарий от pragmaticperl

то не холиварщики, то быдлоненужники. с холиварщиками было как раз интересно похоливарить.

pef-secure ()

Ещё один провал

Автор хочет дать еще один шанс шестому перлу

К несчастию Perl6 провалился вместе со своей виртуальной машиной.

Camel ★★★★★ ()
Ответ на: комментарий от aembers_guggenheim

Зооперл

А Ларри говорит, что он будет готов для продакшена уже в следующем году.

Кто из них? Parrot, Rakudo?

Camel ★★★★★ ()
Ответ на: Зооперл от Camel

Узнаем в январе.

Parrot, Rakudo?

Я не очень много знаю про Perl 6, но разве Rakudo — не реализация Perl 6, работающая на Parrot?

aembers_guggenheim ()
Ответ на: комментарий от aembers_guggenheim

Rakudo может работать на Parrot, JVM или MoarVM.

На сегодняшний день, как в статье и написано ;), лучше использовать связку rakudo+moarvm.

pragmaticperl ()
Ответ на: комментарий от aembers_guggenheim

разве Rakudo — не реализация Perl 6, работающая на Parrot?

уже нет. Parrot не взлетел.

pef-secure ()
Ответ на: комментарий от halturin

сначала пароль выложи

потом вали

anonymous ()

Хорошая новости, спасибо

fero ★★★★ ()

п6 не нужен. Т.к. вместо того, чтобы исправить проблемы нормального п5, мертворожденный п6 наоборот ещё сильнее уменьшает популярность п5...

А журнал - хорошо, что пишут, в принципе.

vitalif ★★★★ ()
Последнее исправление: vitalif (всего исправлений: 1)

Будем ждать Perl 6. Спасибо за журнал.

necromant ()
Ответ на: комментарий от qaqa

my @list2 = 10, 20, 30;

Ты смотри, питон во все поля. Глядишь, лет через 20 на переле можно будет писать читаемый код...

anonymous ()
Ответ на: комментарий от wayland_systemd

Лопата в комплекте с журналом?

Будет кстати - чтобы закапывать Perl-хейтеров.

anonymous ()

Как-то первые 21 номера журнала прошли мимо меня...

Vinni_Pooh ★★★★★ ()

Вышел 22-й выпуск журнала о современном Perl.

Да не уж то о Perl 6?

iron ★★★★★ ()
Ответ на: комментарий от pawnhearts

> меньшее число пунктуации
это не перл-путь. ересь!

Вообще-то ровно наоборот. Епитимью тебе!

anonymous ()
Ответ на: комментарий от anonymous

Глядишь, лет через 20 на переле можно будет писать читаемый код...

писать читаемый код можно прямо сейчас. вернее, писать могут не только лишь все, а мало кто вообще из камментаторов про «не нужно» и «нечитаемый код» может это делать на любом языке. (с)

pef-secure ()

Perl 6 XXI века

Java 33 XXI века.

Perl 6

for @*ARGS {
    $_.say;
}

# aka 

.say @*ARGS;

vs

Perl 5

use feature qw(say);

@list = qw(a b c d);
say for @list;

Т.е., все трындец, без точки спереди теперь say не может подхватить $_? Просто уточняю. Если нет, то это уже не Perl. Это что-то другое. Как по мне это неудачный клон явы. В Perl 6 слишком много взято от явы, при этом с учетом того, что скорость парсинга как у г., то ожидаем появление файлов .plc, .pmc (аля .pyc). А то и вовсе .pljar.

Нет, чтобы пилить на яве очередной cofeescript, ведь там все есть: потоки, O(1) на new/destroy... А тут велосипед не лучшего качества.

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

А тут велосипед не лучшего качества.

Концепция perl6 - отстой, perl5 - вещь! Синтаксические вкусности из perl6 легко можно сделать в perl5, но судя по тому сколько сделано - в них народ нуждается вовсе.

anonymous ()
Ответ на: комментарий от anonymous

Да, очень нуждаются <сарказм>. Это видно по рассылке Marpa. И чего-то только автор проекта все суетится и суетится, а никто даже не смог ничего сделать для p6. Видимо ждут, когда автор Marpa сам напишет анализатор.

Концепция perl6 - отстой

Она не отстой. ИМХО, слишком поздно взялись. В середине 90х появилась Java, к выходу Java 2 (1.2, 1998г.) было сделано практически все, что нужно. Книги по Java 1.x все также актуальны, т.к. само ядро, синтаксис не изменились. Т.о. на сегодняшний момент нишу VM-based языков занимает Java и позволяет писать на ней приложения любой сложности.

Что ждет perl 6, будучи той VM-машиной? Мертво-рожденный язык, который даже не поживет толком. Много людей ушли с Java на Groovy, Clojure? Нет, никто никуда не уходил, выучили их как второй язык, т.к. ядро тоже: JVM. Много Java-программистов уйдет на Perl 6? Думаю, что нет. Никому не нужен опилок от JVM. Много людей перейдет на несовместимый с p5 на p6? Думаю нет, т.к. никакой поддержки XS (это примерно 30% всех модулей на CPAN) в p6 не планируется.

Итого ниша ЯП меняется координально со скриптового языка на VM-based. Что полностью меняет нишу применения ЯП. С такой скоростью запуска «Hello World» в современном мире делать нечего. К примеру сказать, половина пакетного менеджера в OpenBSD это perl 5 (еще времен начала 2000х, когда не было Moo и прочих забористых клонов Java-ООП).

И с учетом того, сколько людей пилять p6 ждать появления чего-то готового и сравнимого с Java в ближайшие 5 лет не стоит. Через 5 лет Java станет еще более навороченной, еще более популярной, напишут для JVM еще тонны DSL-языков.

Есть надежда, что p6 станет ЯП узкого назначения, ну скажем как Forth. Если допилят autothreading (ключевое слово «если») и выведут его за границы одной физической машины. Однако обольщаться не стоит, т.к. здесь пока «господствует» Erlang.

И да, о p6 много говорят в контексте плющек ООП. При этом позабыв, что у p5 неполная функциональщина (6/7 правил-требований выполнено). А в p6 будет функциональщина или это типа, нафиг не нужно? (Риторический вопрос)

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

ЯП узкого назначения

Не нужны. Pеализуется dsl'ем поверх того же perl5

anonymous ()
Ответ на: комментарий от gh0stwizard

Про p6 говорить пока рано, релиза пока нет. Скорость запуска хелло ворлда пока ни о чём не говорти, да и на яве даже скомпилированный класс хелло ворлда запускается заметное время. Надо сказать, убойных прямо фишек в p6 я тоже не приметил пока, но это надо что-то большое написать с осознанием всех фишек, чтобы понять.

pef-secure ()

Спасибо, хорошее дело делаете!

ach ()
Ответ на: комментарий от pef-secure

Про p6 говорить пока рано, релиза пока нет. Скорость запуска хелло ворлда пока ни о чём не говорти, да и на яве даже скомпилированный класс хелло ворлда запускается заметное время. Надо сказать, убойных прямо фишек в p6 я тоже не приметил пока, но это надо что-то большое написать с осознанием всех фишек, чтобы понять.

Нет, уже не рано. Концепция языка уже заявлена и мы понимаем примерно что ожидается. Perl5 очень прост сам по себе, но при этом он обеспечивает огромные возможности и дает большую свободу действии. А в perl6 уже идет закос под ООП, а ООП - это довольно топорная концепция.

Концепция perl6 - отстой

Она не отстой.

Остой. ООП - отстой.

ЗЫЖ: Си-фан

anonymous ()
Ответ на: комментарий от anonymous

то> в perl6 уже идет закос под ООП

главное, чтобы не лишили тех возможностей, что есть сейчас. а доп возможности, да с более прямым синтаксисом — ну пусть будут.

текущая объектность в перле синтаксически жутковата, хотя я привык и всяческие му-мусы-маусы считаю ненужными.

сама по себе оопность местами полезна полиморфизмом. что я могу перегрузить метод у нужного мне модуля и этот модуль станет работать как мне надо, а не как он работал раньше через этот метод. иногда полезна инкапсуляция, хотя и не так часто.

pef-secure ()
Ответ на: комментарий от pef-secure

То что предлагается сейчас - тоже не сахар, так сказать.

has $.name;
has @!orders;
self.public;
self!private;

Теперь внимание, вопросы: а) где 'protected'? б) зачем навелосипедили два (три?) разных синтаксиса вызова метода? в) зачем тогда нужен ^mro, если мы взяли курс на «каждому объекту по symtable»?

Ну и по мелочи, чисто за что глаз зацепился больше всего:

  • printf как метод строки. Лапша в коде - гарантирована.
  • зачем нужен Bool в принципе? if ($var) / unless ($var) - не модно?
  • аналогично Int,Str — у нас уже явная типизация? Это точно перл? Сигнатуры, не?
  • именованные параметры — чем это отличается от передачи хэша, за исключением того, что вводит новый синтаксис?

И самый главный недостаток - отсутствие совместимости. Кому-то мало было третьего питона и руби?

anonymous ()
Ответ на: комментарий от anonymous

зачем нужен Bool в принципе? if ($var) / unless ($var) - не модно?

Согласен со всем, кроме вот этого замечания. Лично я каждый раз ментально напрягаюсь, когда пишу подобный код, судорожно соображаю, может ли при этом в строке оказаться «0» и как должно сработать условие в этом случае. Bool нужен в принципе, хотя в том ли виде как тут придумали типизацию, это вопрос. Вобщем, я сам пока глубоко не вникал за ненадобностью, только поверхностный интерес. «Слишком много ООП» тоже заметил, но не вникал можно ли его игнорировать :)

pef-secure ()
Ответ на: комментарий от pef-secure

Лично я каждый раз ментально напрягаюсь, когда пишу подобный код, судорожно соображаю, может ли при этом в строке оказаться «0» и как должно сработать условие в этом случае.

У вас проблемы на уровне организации кода - perl тут не виноват.

anonymous ()
Ответ на: комментарий от anonymous

У вас проблемы на уровне организации кода - perl тут не виноват.

Телепатия или проводил ревью моего кода? Я уже предлагал один свой проект на обсуждение, из 53 посетителей один сделал ревью одного модуля, за что ему спасибо.

pef-secure ()
Ответ на: комментарий от anonymous

У вас проблемы на уровне организации кода - perl тут не виноват.

Я уточню, на всякий случай, о чём говорю. Допустим, функция принимает или регекспом откуда-то получает параметр, допустим это имя файла. И вот надо понять есть у нас имя файла или нет. if($var) не сработает, когда имя файла есть, но равно «0». Формально, это может быть допустимым именем файла. Приходится проверять более явно на " и/или defined. Или не имя файла, может быть какой-то айди.

pef-secure ()
Ответ на: комментарий от pef-secure

Если ты различаешь 0 и undef при использовании в качестве флагов - используй явно if (defined $var) / unless (defined $var).

anonymous ()
Ответ на: комментарий от pef-secure

Я уточню, на всякий случай, о чём говорю. Допустим, функция принимает или регекспом откуда-то получает параметр, допустим это имя файла. И вот надо понять есть у нас имя файла или нет. if($var) не сработает, когда имя файла есть, но равно «0». Формально, это может быть допустимым именем файла. Приходится проверять более явно на " и/или defined. Или не имя файла, может быть какой-то айди.

Тут все еще проще - ты еще плоховато ориентируешься в perl, ну и порядок нужен в голове если хватаешься за такой мощный инструмент как perl (это php-шникам как-попало сгодиться, а у нас быдлокодить не принято).

if($var) - это булева проверка, то есть через интерпретацию, а ты проверяешь не собственно значение, а существование значения. То есть у тебя простой тест на неопределенность. Это сильно разные условия и, вообще говоря, они не пересекаются. Есть оператор //. Пример со статичным перекрытием неопределенности:

  sub xy{
    my $file = $_[0] // $ENV{FILE} // "default.txt";
    ...
  }

Пример с динамичным перекрытием:

 $file //= do{
    my $var;
    ...
    $var;
 }

Вам надо еще perl подучить. Поверьте мне, это стоит того..

anonymous ()
Ответ на: комментарий от anonymous

Подсветка кода ломается на операторе //. Пофиксите.

sub xy{
    my $file = $_[0] // $ENV{FILE} // "default.txt";
    ...
  }
anonymous ()
Ответ на: комментарий от anonymous

Тут все еще проще - ты еще плоховато ориентируешься в perl

Смелое утверждение. Про существование оператора // я в курсе. Мне в таком тоне общаться не интересно. Приведённые примеры «простоваты», жизнь бывает посложнее. Вобщем, я повторю один раз: приравнивание строкового нуля к «false» может приводить к проблемам в программе. Сам я не помню когда последний раз такую ошибку совершал, просто отмечаю этот момент.

Вам надо еще perl подучить. Поверьте мне, это стоит того..

Не откажешься посмотреть проектик на github? Буду рад конструктивной критике.

pef-secure ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.