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

Оффтопик-лист (изменён 26.01.2022)

Новости о новых выпусках журналов. По просьбам пользователей.

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

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

Perl 6

Шитов

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

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

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

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

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

...

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

...

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

my @list1 = <10 20 30>;

Или даже так (вообще кайф):

my @list2 = 10, 20, 30;

Это победа!

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

меньшее число пунктуации

это не перл-путь. ересь!

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

Поклонником удава будешь?

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

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

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

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

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

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

Зооперл

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

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

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

Parrot, Rakudo?

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

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

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

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

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

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

потом вали

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

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

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

- Ааа, живой человек! Они существуют...

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

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

my @list2 = 10, 20, 30;

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

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

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

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

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

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

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

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

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

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

круто, чё

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... А тут велосипед не лучшего качества.

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

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

Нет, потом в морг.

Да, очень нуждаются <сарказм>. Это видно по рассылке 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 будет функциональщина или это типа, нафиг не нужно? (Риторический вопрос)

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

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

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

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

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

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

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

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

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

ЗЫЖ: Си-фан

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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