Perl мертв. Да здравствует Perl!

>Ты не понял. Речь о том, что Perl - это неоправданно сложно.

ты не понял. я не спорю и никогда не спорил с тем что для быдлокодера перл неоправдано сложен.

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

>А сложность ради сложности нужна только пионерам.

а простота ради простоты - идиотам?

ЗЫ: появились тут - получите порку. если бы все было так прекрасно как ты распинаешься, ты бы (и твои едмномышленники) никогда не появился в этом топике. ты бы был всем доволен. раз появился - значит недоволен. думаю подсознательно ты просто тяготишься своим пристрастием к быдлокодерству. опровергни меня - уйди из топика. плюнь на свой нерастраченный подростковый максимализм

>Ты не понял. Речь о том, что Perl - это неоправданно сложно.

ты не понял. я не спорю и никогда не спорил с тем что для быдлокодера перл неоправдано сложен.

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

>А сложность ради сложности нужна только пионерам.

а простота ради простоты - идиотам?

ЗЫ: появились тут - получите порку. если бы все было так прекрасно как ты распинаешься, ты бы (и твои едмномышленники) никогда не появился в этом топике. ты бы был всем доволен. раз появился - значит недоволен. думаю подсознательно ты просто тяготишься своим пристрастием к быдлокодерству. опровергни меня - уйди из топика. плюнь на свой нерастраченный подростковый максимализм

> я рассуждаю по принципу "если все упрощать и жаловаться на необходимость обучения то превратишься в "ротожопу""

А кто жалуется на необходимость обучения? Тут говорят о корявости инструмента, которому есть более прямые альтернативы.

> кроме того, кто сказал тебе что "мудохались"? использовали рабочий инструмент. или нам надо было отложить дела и ждать лет 10-20?

Ну дык, кто виноват что у вас не было инструмента поудобнее? Вон раньше крестьяне с плугом по полю таскались, а нынешние всё больше на тракторах чего то. Тоже ламеры?

> print $array->[2][0];

Ага, просто и тривиально. Теперь еще пожалуйста *разумно* объясни, почему print "$list->[2]->[0]" - тоже работает. Ну и до кучи - почему синтаксис для вложеных список принципиально отличается от синтаксиса невложненных.

> кроме того, кто сказал тебе что "мудохались"?

Я лично мудохался - возможностей МК-61 решительно нехватало.

> появились тут - получите порку. если бы все было так прекрасно как ты распинаешься, ты бы (и твои едмномышленники) никогда не появился в этом топике. ты бы был всем доволен. раз появился - значит недоволен.

Ты всё же слишком серьёзно относишься к флейму :) И ещё явно преувеличиваешь собственную важность. Я вполне всем доволен, и даже использую Перл (представь себе), когда это необходимо. Вот интересно, ты всерьёз считаешь всех, кто критикует Перл, идиотами?

> Если вам так сильно хочется "близкое вашему мозгу", пишите так:

> @list = (1,2, [3,4]);

> print $list[2][0];

По-моему это самый человеческий вариант, даже если принять во внимания два вида скобок в описании и необходимости писать делее @list2 = (0 , [@list]); Или я не вижу подводных камней?

>> А сложность ради сложности нужна только пионерам.

> а простота ради простоты - идиотам?

То есть вы считаете что "выпендреж" лучше "понятности"? Типа Raymond только шиворот навыворот?

> Вам не понять но это и вправду элегантно, из моей записи видно что $list - это ссылка на массив, и третий элемент этого массива так же является ссылкой.

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

> print $list->[2]->[0];

А почему не $list[2][0]? Какова фундаментальная причина того, что существуют ДВА синтаксиса доступа к элементам массива?

Вот это мы и имеем в виду, когда говорим что синтаксис поганый.

> Так же как и за ваш экзампл. И тот и другой возможны. Языки позволяют. Но использовать нежелательно.

Так мне перловый экзампл привели как канонический!

Самое ужасное в перлистах - то, что они ГОРДЯТСЯ нечитаемым кодом.

> А почему не $list[2][0]? Какова фундаментальная причина того, что существуют ДВА синтаксиса доступа к элементам массива?

TMTOWTDI ;)

> > print $list->[2]->[0];

> А почему не $list[2][0]

Нет, выкинуть можно только вторую стрелку! А первую нельзя. %)

>Теперь еще пожалуйста *разумно* объясни, почему print "$list->[2]->[0]" - тоже работает

да надоело мне объяснять. Есть дока и там разьяснено, разжеванно и даны примеры

http://perldoc.perl.org/perldata.html

http://perldoc.perl.org/perlref.html

вот строчка: One more thing here. The arrow is optional between brackets subscripts, so you can shrink the above down to

Я понимаю вы не читали, или не поняли английского.

>По-моему это самый человеческий вариант, даже если принять во внимания два вида скобок в описании и необходимости писать делее @list2 = (0 , [@list]); Или я не вижу подводных камней?

Конечно не видите, читайте ссылки выше. Это разные структуры.

>> print $list->[2]->[0];

>А почему не $list[2][0]? Какова фундаментальная причина того, что существуют ДВА синтаксиса доступа к элементам массива?

>Вот это мы и имеем в виду, когда говорим что синтаксис поганый.

Потому что ваш вариант неверен. $list - это ссылка на массиа а не сам массив. И как я уже сказал из синтаксиса это прекрасно видно. Но вы - не заметили )

Нет, вы просто не ЧИТАЛИ доку, а читали "перл за 10 уроков" на 3 страницах.

> зы: вас бы горе программеров за БЗ-34 засадить на пол-годика - год. для прочистки мозгов и кармы

ну зачем быть таким жестоким, можно и за MK-52, там хоть памяти чуть больше

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

Что значит излишнее? Если для вас скриптовый язык - это на уровне баша - то да. Можно мне пример популярных скриптовых языков без ссылок?

>> байт это всегда восемь бит

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

CD -- это музейное специализированное железо? там, если не ошибаюсь, 14 bit

Очень показательный флейм. Собрались перловики, питонисты, рубисты и пр. "гошпода" кодерасты в одной теме и давай сравнивать разные виды дерьма. "вот тут закорючка - не понятно - в топку!", "это необейсик с дуболомным синтаксисом - для дегенератов!", "если не знаешь синтаксис Перла, ты не мужЫк!", "да кто он такой? где библиотеки для него? где code base?", "Да мои энтерпрайз скрипты ещё при Наполеоне уже работали, когда его ещё в проекте не было", "На свалку, старперы хреновы!", "Поколение пепси выбирает Питон!", "Сам дурак!". Ещё чуть-чуть и начнётся в буквальном смысле измерение пиписек. А изначально тема была про перл (хоть и флеймообразующая). Это говорит о том, что все перловики, питонисты, рубисты и пр. фанаты своего большого интимного опыта - люди одного сорта и ни о какой исключительности отдельной подгруппы не идёт речи. Одним словом, Программисты :)

Нафлудили на полтыщи комментариев, из них по делу - от силы 1%. По ссылке на Oreilly Net и то диалог более продуктивный. Там хотя бы люди рассказывают, для чего использовали Перл, как долго, почему и пр., без соплей, дешёвых эмоций и пионерии. А тут... Противно читать.

> я против того чтобы они срали в топиках посвященных перлу.

Мы хотим создать вокруг перлофанатиков на ЛОРе атмосферу дискомфорта, как ФБР создаёт вокруг педофилов в чатах. Только они соберутся водить хороводы вокруг поганого идолища CPAN или придумывать новый способ записать "rm -rf /" в виде знаков препинания, как мы тут как тут: "а нахрена нужны указатели? что такое $_? как там Perl 6 и кто его ТЕПЕРЬ доделывает?"

>> $list = [1,2, [3,4]];

> Ты лучше честно напиши как теперь обратится к элементу со значением "3".

если человек не осиливает такой примитив, как $$list[2][0], ты быдлокодерство для него -- это совершенства.

> Можно мне пример популярных скриптовых языков без ссылок?

Python? Ruby? JavaScript?

В них всех почему-то пишется list[0][2] без всяких дурных стрелок.

> Есть дока и там разьяснено, разжеванно и даны примеры

> http://perldoc.perl.org/perldata.html > http://perldoc.perl.org/perlref.html

Уже по разделению видно, что вторая дока лишняя и есть костыль.

> Конечно не видите, читайте ссылки выше. Это разные структуры.

Структуры разные, но проблема то в чем?

>> print $list->[2]->[0];

> Очень элегантно, ага :)

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

ни кто не мешал писать @list = (1,2, [3,4]) для обычного массива, где обращение будет $list[2][0]

> если человек не осиливает такой примитив, как $$list[2][0],

А, уже третий вариант! Но - самый убогий, уж извините. Выигрывает $list->[2]->[0] самый прозрачный. Хотя с точки зрения перла $$list[2][0] наверное самый супер, да.

> без которого в других скриптовых языках отлично обходятся почему то

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

> больше всего задалбывают псевдоуказатели

Псевдоуказатели - это что такое? references типа ARRAY, HASH, SCALAR, CODE?

Что же именно сложного в типах данных Perl? Вот вся теория по типам данных. Существует 3 синтаксиса: $scalar (или $ref или $object), @list, %hash (последние два для работы с list-context). С соответствующим референсингом: \@list, \%hash, \$scalar. И дереференсингом: $arrayref->[0], @$arrayref, $hashref->{key}, %$hashref, $$scalarref, $object->method.

Это всё, что достаточно знать о типах данных Perl, чтобы начать использовать мощный механизм манипуляций данными, со всеми возможными сценариями, включая work-on-copy, work-on-reference.

Можно почитать историю такого дизайна языка (и заодно про list-context, который при умелом использовании упрощает запись и улучшает читабельность). Отдельный namespace для переменных это очень удобно и читабельно (да-да, те самые доллары. собачки и проценты читабельнее дезориентирующего кода Питона и подобных языков, где всё выглядит как монотонная каша и identificator может быть как переменной, так и функцией, так и именем класса, так и конструктором класса, так и зарезервированным словом языка, сразу и не разберешься).

В свою очередь списки и хэши это настолько распространнённые концепты, что заслуживают свой более удобный синтакс, отдельный от элементов данных списков и хэшей. Хотя можно работать и только с референсами для любителей всё-есть-объект; правда так как много в языке конструкций для list-context, то придется для использования их делать тривиальный дереференсинг. Оптимально ли такое решение или надо было идти путём Python или Ruby, у которых изрядно урезаны случаи работы со списками и хэшами (если не согласны, вспомните work-on-copy, work-on-reference)? Для многих ответ ясен. Более богатый синтакс не мешает (а часто помогает) восприятию написанного и с лихвой оправдывает появившиеся возможности.

В Perl 6 оставили list-context и те же 3 типа переменных с некоторыми изменениями в синтаксисе и некоторыми изменениями в логику list-context (если в Perl 5 список в скаляр преобразовывался как длина списка, то по крайней мере в pugs просто делается реферемсинг списка).

Согласен, для тех, у кого один лишь Python (или Ruby?) в голове, синтаксис Perl 6 будет намного роднее, но это как раз совсем неважные детали, никак к концепции и мощи языка не относящиеся.

> необходимости писать делее @list2 = (0 , [@list]);

зачем?

> Что значит излишнее? Если для вас скриптовый язык - это на уровне баша - то да. Можно мне пример популярных скриптовых языков без ссылок?

Не, ссылки как раз нужны. А вот зачем в скриптовом языке value-based (не знаю как правильно назвать) переменные? Вернее зачем нужно синтаксическое различие между ссылками и такими переменными? В Питоне, Руби, JS как то обходятся без этого.

> Мне не нравится само разделение на ссылки и не-ссылки в Перл, совершенно излишнее для скриптового языка.

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

>Ты просто не хочешь замечать ответы. На тему "чем плох синтаксис перла" можно долго рассуждать, но перловики ведь всё сведут к "ниасилили". Лично меня в перле больше всего задалбывают псевдоуказатели. Очень уродливый костыль, без которого в других скриптовых языках отлично обходятся почему то. Да, а JS и C ты к чему привёл? У них с синтаксисом всё хорошо. Потому что люди думали головой, когда их проектировали.

Это как с правдой, она вроде одна для всех, но с другой стороны разная для каждого, а меня вот задалбливают скобки в лиспе. Ну и че. Я же не лезу в топик про лисп и не начинаю визжать что лисп мертв, и де нахер он никому не нужен, давайте вместо него писать на XXXX всех заставим. Ну не нравится мне его синтаксис - ну и не использую.

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

> Вернее зачем нужно синтаксическое различие между ссылками и такими переменными?

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

> Что же именно сложного в типах данных Perl? Вот вся теория по типам данных. Существует 3 синтаксиса: $scalar (или $ref или $object), @list, %hash (последние два для работы с list-context). С соответствующим референсингом: \@list, \%hash, \$scalar. И дереференсингом: $arrayref->[0], @$arrayref, $hashref->{key}, %$hashref, $$scalarref, $object->method.

Что в этом сложного? Ну для начала следует найти язык где *сложнее*. Я сходу и не соображу...

> Оптимально ли такое решение или надо было идти путём Python или Ruby, у которых изрядно урезаны случаи работы со списками и хэшами? Более богатый синтакс не мешает (а часто помогает) восприятию написанного и с лихвой оправдывает появившиеся возможности.

Кстати, мы на прошлых страницах еще не дождались примера, где grep {} был бы понятнее чем питоновский вариант. Продолжаем?

> синтаксис Perl 6 будет намного роднее

То есть автор тоже понял, что так жить дальше нельзя?

>Ты не понял. Речь о том, что Perl - это неоправданно сложно. Что есть более простые средства с той же областью применения и с такой же производительностью. Более сложное решение должно быть чем то оправдано. А сложность ради сложности нужна только пионерам.

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

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

>> необходимости писать делее @list2 = (0 , [@list]); 

> зачем?

Если нужно получить (0, [1, [2, 3]]).

> Пионерам нужна простота, доки и экземплы

Доки и экзамплы нужны для перл. Сколько человек *сами* долдумались до grep {$_{$_}++} ? Если такие есть, я потрясен вашими умом, честно.

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

А если код *чужой* ?

> он позволяет писать на себе так как тебе хочется,

Расскажешь о том как делать вложенные списки без ссылок?

> Существует 3 синтаксиса: $scalar (или $ref или $object), @list, %hash (последние два для работы с list-context). С соответствующим референсингом: \@list, \%hash, \$scalar. И дереференсингом: $arrayref->[0], @$arrayref, $hashref->{key}, %$hashref, $$scalarref, $object->method.

Ну так дереференсинг и задалбывает.

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

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

> Хотя можно работать и только с референсами для любителей всё-есть-объект; правда так как много в языке конструкций для list-context, то придется для использования их делать тривиальный дереференсинг. Оптимально ли такое решение или надо было идти путём Python или Ruby, у которых изрядно урезаны случаи работы со списками и хэшами (если не согласны, вспомните work-on-copy, work-on-reference)

По-моему ни разу не оптимальное. В Руби, к примеру, можно клонировать объекты и работать с копиями без извращений с синтаксисом. Да и потом, для вложенных структур все равно приходиться использовать ссылки, как ни крутись. И опять возвращаемся к work-on-reference и дереференсингу. Такое усложнение синтаксиса только ради удобства работы с плоскими структурами данных считаю неоправданным.

>> необходимости писать делее @list2 = (0 , [@list]);

> Если нужно получить (0, [1, [2, 3]]).

а может проще сразу @list = (0, [1, [2, 3]])?

+1. Раньше почему-то считал, что этот ресурс для интеллектуалов. А тут бессмысленная драка Big Endian с Little Endian ))

> дезориентирующего кода Питона и подобных языков, где всё выглядит как монотонная каша и identificator может быть как переменной, так и функцией, так и именем класса, так и конструктором класса

И всё это будет переменной, и более того - объектом. Который отвечает на различные сигналы. Вау!

А перловская сегрегация приковывает к земле и не даёт абстрагироваться от типа переменных, чтобы с ними адекватно работать.

> Более богатый синтакс не мешает (а часто помогает) восприятию написанного и с лихвой оправдывает появившиеся возможности.

Какие такие загадочные "появившиеся возможности"? По-моему на все хитрозадые криптографические примеры перла питонщики уже дали адекватное читабельное алаверды. Где у перла преимущества-то?

> а этого разделения и нет, в переменной что хочешь, то и хранишь: все обычные переменные -- это скаляры, и больше ничего.

Как же нет? Если в переменной хранится ссылка, то использовать её как обычную переменную не получится. Нужно дереференсинг делать. Это что, не разделение?

>А если код *чужой* ?

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

>о том как делать вложенные списки без ссылок?

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

> > Вернее зачем нужно синтаксическое различие между ссылками и такими переменными?

> Вы сказали бред. Одна и та же переменная может хранить как ссылку, так и данные.

Ну правильно. Я и говорю, зачем нужно синтаксическое различие при использовании переменных, хранящих значение и переменных, хранящих ссылку?

> $$array[2][0]

Если честно, я так никогда не пишу. И не посоветовал бы так писать. (Впрочем я раньше писал исключительно $array->[2]->[0], пока не убедил себя, что от удаления второй стрелки читабельность не падает и конфликтов не возникает, так что мои вкусы тоже меняются.)

Ещё одна запись для извлечения тройки, которую я также не посоветовал бы новичкам: @$array[2]->[0]. Это работает, потому как запись @$array[2] эквивалентна @{$array}[2] или (@$array)[2], что в свою очередь эквивалентно $array->[2]

Те. кому двойной дереференсинг за раз сложно даётся и преоритеты операторов не хочется изучать, могут разбить его на 2 строки. Так обычно в реальных программах и бывает. Редко когда надо залезть в структуру глубоко, заранее зная точный путь к внутреннему элементу.

> а может проще сразу @list = (0, [1, [2, 3]])?

Предполагается, что list1 пришел к нам "свыше", разумеется.

>Какие такие загадочные "появившиеся возможности"? По-моему на все хитрозадые криптографические примеры перла питонщики уже дали адекватное читабельное алаверды. Где у перла преимущества-то?

http://gambit.com.ru/~jerom/labirint.png
Лабиринт который надо решить и потом вывести каждое второе значение красной компоненты цвета пиксела.

Перл:

use GD;
$png = newFromPng GD::Image('labirint.png',1);

for$x(@r=0..640){$m{"$x $_"}=$png->getPixel($x,$_)for@r};

@c=(639,0);
while(640-$c[1]){push@p,[@c];$m{"@c"}|=1;
c(-1)||c(0,1)||c(1)||c(0,-1)or@c=@{pop@p,pop@p};}

print chr($m{"@$_"}>>16)while$_=splice@p,0,2;

sub c{@b=map$c[$_]+$_[$_],0,1;!($m{"@b"}%2)and@c = @b;}


Запостите плиз код на питоне, интересно. (пример не мой)

> И не посоветовал бы так писать.

Одобряю. Стрелки все-таки читабельне. Особенно две.

да, простите, забыл источник указать, пример взят отсюда: http://community.livejournal.com/ru_perl/154645.html

(да просто первое что под руку попалось)

> А тут бессмысленная драка Big Endian с Little Endian ))

Очень даже осмысленная драка. Для меня, во всяком случае, полезная.

>> А если код *чужой* ?

> Ну и что ? Не сахарный, не растаешь,

... перепишешь по новой, ага.

> А чем тебе ссылки вообще не нравятся ?

Чем мне не нравится ссылки в скриптовых языках? Самим фактом своего существования, я думаю.

>... перепишешь по новой, ага.

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

> не дождались примера, где grep {} был бы понятнее чем питоновский вариант

Отфильтровать любой список с помощью grep, что же может быть понятнее. А если учесть, что условие может состоять из любого числа выражений (для чего в Python требуется создать отдельную именную функцию), то и сравнивать-то тут не с чем.

> > синтаксис Perl 6 будет намного роднее

> То есть автор тоже понял, что так жить дальше нельзя?

Не волнуйся, там будет достаточно много богатого синтаксиса (не менее богатого, чем в Perl 5), чтобы отпугнуть тех, кто не желает обучаться и предпочитает чего попроще. :) А те же, кто открыты к знаниям, найдут в Perl 6 свой рай, впрочем такие и в Perl 5 его находят. :)