Larry Wall представил Perl 6

Плохо или хорошо кому?

Давай так: Во-первых, для perl-кодеров это не проблема. Даже самый обфусцированный код (с стандартным модулем Deparse) вызовет кратковременную запинку. Тот же патч Бармина прекрасно парсится через Deparse, и не вызывает после этого никаких осложнений. Чтоб сразу распарсить его глазами :-D нужно иметь некоторый опыт. Если об этом не знать - понимаю твою позицию, брэйнфак.

Во-вторых: в отличие от питона каждый может располагать код так, как ему вздумается. Для perl-кодера не проблема: с помощью perl::tidy он выровняет код так, как нужно его глазам. Если об этом не знать - проблема.

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

P.S. Люблю питон, с него начинал (после паскаля, конечно) :) P.P.S. Ссорь за простыню.

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

Проблема не сводится к одному лишь синтаксису, посмотри на крестухов. Сомневаюсь, что какой-то deparse выручит тебя, если один предпочитает писать в ФП-стиле, а другой долбится в фабрики и визиторы.

tuple иммутабельны и могут быть использованы как ключ хэша

Readonly::{Array, Hash} Tie::RefHash

Можно. То что можно в питоне, можно в перле. А вот наоборот? В питоне goto можно запилить?

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

Синтаксис не проблема, code style + чекер на коммиты. Человек может и не напрягаться, всё сделает автомат.

Сомневаюсь, что какой-то deparse выручит тебя, если один предпочитает писать в ФП-стиле, а другой долбится в фабрики и визиторы.

В каком языке эта проблема решена? В ассемблере?

В питоне goto можно запилить?

https://github.com/snoack/python-goto

http://entrian.com/goto/

Readonly::{Array, Hash} Tie::RefHash

Они же не могут быть ключом хэша, не?

https://github.com/snoack/python-goto

http://entrian.com/goto/

Я там прочел про столько ограничений, что неловко как то. Давай сравним два кода создающих такую структуру(такую языковую конструкцию):

case ([condition 1], [condition 2]):
    both:
        sub 1
    first:
        sub 2
    second:
        sub 3
    none:
        sub 4

ммм? а то мелочимся чот.

Они же не могут быть ключом хэша, не?

ссылка может быть ключом. Глянь еще https://metacpan.org/pod/Hash::MultiKey

ссылка может быть ключом

А как это работает? В смысле если я сделаю ключом пару (0, 1) и потом буду вытаскивать по результату какой-либо функции, то если она вернёт (0, 1) — это же другая ссылка, не? Оно вытащит исходное значение или как?

В этом случае, лучше Hash::Multikey.

P.S. Так что, макропрограммированием померяемся? Я уже достал почти.

В питоне goto можно запилить?

Сравнение двух ЯП по конкретным фичам совсем некорректно. У каждого языка есть свои сильные и слабые стороны. И вообще, это всё субъективно.

Но вот перл славится очень странными вещами. Например, некоторое время назад у людей вызывало восторг то что в доках было написано как вызвать у интерпретатора segfault. Или вот ты щас про goto начал Или какой-нить dualval.

При этом перлисты упускают из виду то что многие фичи не имеют ценности которые они в них видят. Это касается и квалификаторов доступа (ну вообще ни разу не замена нормальной системе типов и статической проверке кода), и 100500 странных модулей, и произвольным форматированием. И плевать что perl::tidy превратит код прям как в питоне, главное свобода :).

Короче, ребята, вы как-то... не от мира сего. Perl выглядит очень интересно, но больше воспринимается как один большой эксперимент одного усатого дядьки. Если ты разделяешь его ценности то добро пожаловать в его мир. Но не надо заблуждаться что весь мир это сплошные текстовые потоки. Как только перл выходит за пределы «распарсить текст» многие преимущества описанные в этом треде как минимум смотрятся как рудименты.

Ни питон ни перл не являются полноценной заменой друг другу. Они очень разные. Но в общем случае я выбираю питон.

До конца - ни в каком. Но это не значит, что с ней не надо бороться.

Но не надо заблуждаться что весь мир это сплошные текстовые потоки.

Да ты же поднял руку на прешвятые жаповеди Unix.

такую языковую конструкцию

Вот-вот, в перле людей тянет постоянно изобретать :). Поверь, в питоне тоже много-много чего можно навелосипедить. Я тоже иногда люблю поиграться с кишками питона и добавлять новые фичи на которые он не был расчитан. Главное чтобы в продакшн это не попало.

Тут перл выигрывает. Судя по кол-во модулей на cpan его специально затачивали чтобы его хачили.

Но лично меня вполне устроит такое:

cond1 = ...
cond2 = ...
if cond1 and cond2:
  ...
elif cond1:
  ...
elif cond2:
  ...
else:
  ...

Конечно, с таким кодом на лоре не повыпендриваться :)

При этом перлисты упускают из виду то что многие фичи не имеют ценности которые они в них видят.

как и питонщики.

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

Или бородатого дядьки Гвидо Ван Россума? :-D

Как только перл выходит за пределы «распарсить текст» многие преимущества описанные в этом треде как минимум смотрятся как рудименты.

Опиши задачи, где перл теряет преимущества (в сравнении с другими скриптовыми, разумеется).

Но в общем случае я выбираю питон.

а я зависит от ситуаций. Чаще перл.

Лучше, имхо, бороться с конкретными случаями, чем с общими. И в общем, многополярный мир, по мне лучше однополярного. Пусть будут языки свободные, пусть будут топорные, и всё что между ними. Некоторые мои знакомые-непрограммисты ворчат: - Зачем столько языков? Лучше бы был один, лучший!

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

Да ты же поднял руку на прешвятые жаповеди Unix.

багахульник!!!

Ларри тоже советовал: используйте текст где это возможно, текст - это хорошо.

Поверь, в питоне тоже много-много чего можно навелосипедить. Я тоже иногда люблю поиграться с кишками питона и добавлять новые фичи на которые он не был расчитан.

Судя по goto я разочарован. До кишок не добраться, только переодеть. Например, как управлять ходом запуска программы и её завершения на разных уровнях (вроде BEGIN, UNITCHECK, CHECK, INIT, END в perl)?

Судя по кол-во модулей на cpan его специально затачивали чтобы его хачили.

Это следствие гибкости и свободы, которая предоставлена программисту.

Конечно, с таким кодом на лоре не повыпендриваться :)

не выпендривания ради, оценки возможностей для ;) Для всяких DSL важная фича. Или питонщикам DSL => ненужно?

Опиши задачи, где перл теряет преимущества (в сравнении с другими скриптовыми, разумеется).

Да обычное повседневное ООП и не очень программирование. Ты же понимаешь что вот так большинство людей не пишет? Baby-code нашё всё. Именно поэтому позавчера я успешно распарсил код systemd на си а сегодня расковырял proxmox на перле. Слава богу что там не страдали «давайте заюзаем пол cpan в нашем проекте». Иначе бы я повесился

Ну и вообще, что есть программа с точки зрения перла? В ООП-мире между собой взаимодействуют объекты, в ФП всё строится на функциях, в перле... на тексте? :)

Возможно, я смотрю со своей колокольни, но не вижу как перл бы облегчил жизнь по сравнению с питоном. Вот тот же веб. Пока это был текст перл был на высоте. А потом выяснилось что веб это всякие MVC, ORM, NOSQL и прочее. Какая из основных фишек перла тут поможет? Я могу ответить за питон: ООП, модульность, простота конструкций, встроенный юникод :).

как управлять ходом запуска программы и её завершения на разных уровнях (вроде BEGIN, UNITCHECK, CHECK, INIT, END в perl)?

Зачем это тебе? Просто затем что ты можешь? Какой процент перловых программ это использует? Вот я про это и говорю: то что ты считаешь круто на самом деле мало кому нужно.

Или питонщикам DSL => ненужно?

Питон не умеет в DSL. Но DSL это не такая широкая ниша.

в перле... на тексте? :)

На регэкспах, конечно же. В Perdl 6 просто нужно было ввести мета-регэкспы, которыми можно управлять самой программой.

Да обычное повседневное ООП и не очень программирование.

TMTOWTDI. Да, дефолт даст полный контроль над деталями, но это нужно не всегда. Можно воспользоваться модулями, их на любой вкус и модель ООП, которая нужна. Это позволит абстрагироваться до той степени, которой необходимо.

В ООП-мире между собой взаимодействуют объекты, в ФП всё строится на функциях, в перле... на тексте? :)

Есть объекты, только тсссс :)

ООП

тебе нравится просто что выбрали за тебя.

модульность

можно уже выбирать версию модуля при загрузке?

встроенный юникод

какой версии?

модель ООП, которая нужна

Что делать когда либы используют разный ООП?

Есть объекты

«Девушка, у вас грудь есть? — Есть! — А почему не носите?»

можно уже выбирать версию модуля при загрузке?

Да, есть несколько либ которые это делают. Например: http://stackoverflow.com/questions/6445167/force-python-to-use-an-older-versi...

Но зачем это понадобилось? Принято делать virtualenv с нужными версиями.

какой версии?

Той что работает :). Серьёзно. Даже на лету выбирает внутреннее представление (1, 2 или 4 байта на символ) в зависимости от символов в строке.

Зачем это тебе?

Профайлеры, синтаксические анализаторы, прагмы, инлайнеры, трансляторы, песочницы. Для кого-то дичь и редкость, а нужно. Даже в пользовательском ПО бывает нужно переопределить поведение системных функций. Например autodie люблю, ммм)

Вот я про это и говорю: то что ты считаешь круто на самом деле мало кому нужно.

Питонщикам не нужно. Стандартный ответ.

Питон не умеет в DSL. Но DSL это не такая широкая ниша.

А потому - не нужно ;)

Что делать когда либы используют разный ООП?

Использовать. Приведи пример проблемы.

«Девушка, у вас грудь есть? — Есть! — А почему не носите?»

«Носим, упорным - показываем, любителям - даём потрогать» :-P

Той что работает :)

новые версии - не нужны :)

Профайлеры, синтаксические анализаторы

Это есть.

Даже в пользовательском ПО бывает нужно переопределить поведение системных функций

Вообще без проблем, monkey patching называется. Но это не приветствуется, вполне возможен ногострел.

Питонщикам не нужно. Стандартный ответ.

Я не говорил что не нужно. У питона есть технические ограничения и свои тараканы в реализации. Есть класс задач которые он решает плохо. Для питона есть и сэндбоксы, и трансляторы и прочее. Но часто сделано оно через опу. Его кишки не расчитаны на такое, поэтому сэндбоксы для питона это всегда потенциальная дырень. В общем, если для решения задачи нужно патчить байт-код, подправить stack frame или перепарсить файл то лучше пересмотреть подход (a для перла это норма :)).

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

новые версии - не нужны

Там ничего нового, ascii/ucs-2/ucs-4 внутри, наружу выводит то что в локале (utf-8/16/32/whatever) или любой кодировке на выбор. Просто тебе об этом знать не нужно. Ты просто «работаешь с текстом», остальное на себя берёт питон, конкретно модуль codecs.

Ладно, не смею тебя отвлекать от других троллей. Их много а перловый программист у нас один :)

Это есть

У них всех очень скромные возможности, как и у питон.

А потом выяснилось что веб это всякие MVC, ORM, NOSQL и прочее. Какая из основных фишек перла тут поможет?

Perl уже давно не про обработку текста. В моих проектах и MVC, ORM, SQL/NOSQL и что угодно.

Я могу ответить за питон: ООП, модульность, простота конструкций, встроенный юникод :).

Так в Perl тоже есть ООП (пусть и своеобразный, и даже совсем не ООП с т.з. упоротых пуристов, но вполне годный), модульность, простота и юникод (возможно один из самых продвинутых в этом плане ЯП).

Я не буду спорить. Если вышел perl6 значит это кому-то нужно. Просто меня удивляет что в 2015 году вышел «новый» язык в котором

my $i = "25" + 10;
say $i;
=> 35, Карл! :)

Но я не хочу по этому поводу бучу поднимать.

Если вышел perl6 значит это кому-то нужно.

Видимо да. Я все ще на Perl5, не знаю зачем шестерка (ведь есть Скала).

в 2015 году вышел «новый» язык

А, ну это не интересно, я думал вы «пятерку» обсуждаете.

А, ну это не интересно, я думал вы «пятерку» обсуждаете.

ну мы пятёрку и обсуждали))

недостаток - это вечные преобразования to_integer, to_string, to_boolean и т.д., которые сравни шуму и заиканиям.

А зачем они вам? Преобразование числа в строку, например, где-то нужно кроме как в printf? А там и так есть для этого оператор %d например. Числа/строки в bool вообще не нужно, bool должен получаться при вычислении < > == всяких. Строки в число — нужно, но не очень часто. И гораздо лучше его сделать явно, уже при вводе числа. а не позже, когда оно задействуется.

юникод (возможно один из самых продвинутых в этом плане ЯП)

Давно последний раз читал, что делает Encode::encode, а что Encode::decode, и в каком порядке их надо применять? Я вот пару месяцев назад. Если бы мы жили в волшебном мире, населённом понями, разговаривающими исключительно в юникоде...

можно конечно всё интерполировать, но это для примера.

На Tcl то же самое выглядит элегантнее:

set l [list a b c]
set s {hello}
set i 4
set r 8.3
array set a {x 3 y 4}
set d [dict create a 1 b 2 c 3]
append str "$l " $s { } $i $r [expr {$i+$r}] " [array get a]" " " $d
# в $str: "a b c hello 48.312.3 x 3 y 4 a 1 b 2 c 3"

Давно последний раз читал, что делает Encode::encode, а что Encode::decode, и в каком порядке их надо применять?

Да, довольно таки давно, тк хорошо помню что там написано и как с этим работать. Когда-то много приходилось с этими заморочками сталкиваться.

А зачем они вам?

чтоб писать:

@List + $a / "$ratio.$b" . ++$appendix + $current_tag

а не

(length(@List) + $a.to_int / (0 + $b.to_int)).to_str + $appendix.succ.to_int + $current_tag.to_int

элегантность в многословности?

элегантность в многословности?

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

@List + $a

А откуда ты знаешь заранее, что возьмётся длина списка, а не что-то другое? Без length придётся лезть в мануал по языку. И в следующей версии может поменяться.

«$ratio.$b»

А это что за фигня?

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

В логичности и читаемости кода, во-первых,

и чем он так логичен и более читаем?

во-вторых мой код всё равно короче твоего получился.

ну напиши короче:

@List + $a / "$ratio.$b" . ++$appendix + $current_tag

А откуда ты знаешь заранее, что возьмётся длина списка, а не что-то другое?

из контекста.

Без length придётся лезть в мануал по языку.

тебе - да.

И в следующей версии может поменяться.

баюс-баюс. лет дцать не менялось - вдруг поменяется?

А это что за фигня?

реальное число

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

у тебя сломается, ты забудешь, не поймёшь. тяжело быть тобой :(

ну напиши короче:

Я не могу это написать короче, да и вообще никак, потому что не понимаю, что это за хрень без контекста. Сравнивать нужно не на какой-то строчке, а на целой программе, которая что-то более-менее полезное или хотя бы понятное делает. Может быть в другом языке для того, чтобы это сделать есть совсем другие конструкции.

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

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

Код на Tcl понять легко, если прочитать man Tcl и маны по каждой используемой команде

а потом забывать, снова читать. И вообще, всегда читать, ведь в новой версии могут поменять поведение.

а потом забывать, снова читать.

Бывает, но сам синтаксис Tcl настолько просто, что сложно его забыть.

И вообще, всегда читать, ведь в новой версии могут поменять поведение.

В Tcl поведение не меняют, только иногда новые фичи осторожно добавляют, чтобы не ломало существующих программ.

Сюрприз, но с перлом так же. Сейчас, в гораздо меньшей степени, чем раньше, да и в сравнение с тиклем. Но и развитие сравни. Тикль далеко позади глотает пыль.

Сюрприз, но с перлом так же.

И это ты пишешь в теме про Perl6, ага

Но и развитие сравни. Тикль далеко позади глотает пыль.

Ну да, сейчас Python доминирует (не считая веба), а Perl пыль глотает. Ну и что? Это не говорит о том, что сам язык лучше.

Perl6 вряд ли кто-то будет пользоваться массово, потому что из интересных фич только грамматики, а они есть и отдельно от перла. А фигня с 1, 2, 4, .. 2**32 — это вообще недостаток, так как возникает неожиданный результат. А что если он формулу по-сложнее не распознает?

И это ты пишешь в теме про Perl6, ага

Inline::Perl6, Inline::Perl5.

Ну да, сейчас Python доминирует (не считая веба), а Perl пыль глотает.

Ну, покажи мне Mechanize для python. Или metacpan. Профайлер уровня nytprof. Я говорю о таком доминировании, а не о том, что на слуху и распиарено.

потому что из интересных фич только грамматики

для тебя.

Без объяснения чем эти mechanize, matacpan или nytprof круты нельзя сказать есть ли альтернативы или нет.

Mechanize

https://www.reddit.com/r/Python/comments/3dvq25/are_there_any_better_alternat...

metacpan

Эээ, гугл?

nytprof

Что у него за киллер-фича?

Без объяснения чем эти mechanize, matacpan или nytprof круты нельзя сказать есть ли альтернативы или нет.

какбэ информация не закрытая. Можно глянуть. Каждому свои фичи. Обычно наши разговоры о фичах заканчиваются так «фича не нужна!».

Mechanize

https://www.reddit.com/r/Python/comments/3dvq25/are_there_any_better_alternat...

Из этого - сравнительно смотрится Grab. Который стал юзабелен в прошлом году только, судя по чейнджлогам. Пока он пилился - на Mechanize уже писали. Как он сейчас, ты пользуешься?

metacpan

Эээ, гугл?

эээ, дискетки с рар-архивами по друзьям.

Что у него за киллер-фича?

https://metacpan.org/pod/Devel::NYTProf

Заодно сравни фичи metacpan с чем-нибудь. Просто посмотри ресурс.