Основы Perl - 4 урока

> Так и Perl все его !@^% описаны в документации. Читайте. Учите. Какая-то пара лет, и все запомните.

Нахера мне терять пару лет непонятно на что?

Блин, тот же TCL при всех его недостатках в десять раз логичнее Питона.

Тем не менее, питон учится за неделю. И никаких !@^% не надо.

> Сообщения об ошибке не будет, а заметить эту ошибку будет ох, как непросто.

Я вас удивлю, наверное: я много и давно пишу на питоне. ТАКОГО РОДА ошибок у меня не возникало НИКОГДА. Основная проблема в питоне, вообще - опечатки в идентификаторах. В логике ошибиться трудно: язык чист, прост и интуитивно понятен.

> С какой радости len() у нас функция, а __len__ – метод?

У вас там в Perl'е вообще методов нет.

А у нас в Python'е __len__ используется для эмуляции длины произвольного контейнера. Хоть на диске храните, всё равно len(container) будет корректным выражением что для списка, что для другого класса эмулирующего __len__.

> Потому что это допустимая конструкция языка. И потому что таких дебильных ошибок практически никто не делает.

Кстати, никто не мешает создать скрипт-шпаргалку «для самых маленьких»

> Блин, тот же TCL при всех его недостатках в десять раз логичнее Питона.

TCL прост как три копейки. Однажды, я пытался его использовать в проекте, красиво всё так, expectk. Проблем было несколько, не считая, что несколько одновременно открытых программ в режиме диалога начинали мухлевать с буферами, и поэтому диалоги были неустойчивы, не всегда flush помогал. Самая засада была в скорости обработки текстовой информации. Что программа на перле делала 20 сек, на Tcl занимало 3 минуты. Так что пришлось всё делать на Perl/Tk, благо там и диалог нафиг не нужен был, все модули были доступны и так.

> Конечно нет. Потому что это допустимая конструкция языка. И потому что таких дебильных ошибок практически никто не делает.

Вот и полная аналогия между, например, такой же дебильной ошибкой в Perl: написание @var вместо $var.

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

Нет, это я придираюсь к тому, что вы вспомнили не все immutable типы :)

Именно математическая, практически без изменений покраденная из Хаскеля.

С изменениями. Общепринятые символы заменили на предлоги, которые уже имеют совершенно определенные значения в языках программирования. Если бы оставили нотацию Haskell или Erlang, было бы проще.

> Вот и полная аналогия между, например, такой же дебильной ошибкой в Perl: написание @var вместо $var.

Аналогия не полная. Потому что скобки используются для вызова функций в БОЛЬШИНСТВЕ языков. А вот мистические @/$ - это уже личная перловская криптография.

Нет, это я придираюсь к тому, что вы вспомнили не все immutable типы :)

Ещё NoneType иммутабелен, забыли, ай-яй!

Вот отличие между перлом и питоном. Кошмарность перла очевидна сразу. А поблемы с питоном приходится мучительно выдумывать.

Если бы оставили нотацию Haskell или Erlang, было бы проще.

Буквы набирать проще знаков препинания.

При чем тут вообще знаки препинания?
Я так и не понял, в чем перл кошмарен. В том что он - не питон?
так напиши фильтр

> Нахера мне терять пару лет непонятно на что?

Про пару лет я говорил применительно как к Перлу, так и к Питону.

Тем не менее, питон учится за неделю. И никаких !@^% не надо.

Боюсь, что за неделю вы научитесь только писать что-то типа анализатора логов. Чтобы выучить Питон на уровне, аналогичном уровню, достигаемому за пару лет перловодства, нужно ничуть не меньше, если не больше, времени. Просто потому что литературы, сравнимой с Орейлевской Perl bookshelf, для Питона нет.

>> С какой радости len() у нас функция, а __len__ – метод?

У вас там в Perl'е вообще методов нет.

Попрошу воздержаться от инсинуаций. С высоты моего происхождения разница между Перлом и Питоном минимальна. О чем я и толкую :)

А у нас в Python'е __len__ используется для эмуляции длины произвольного контейнера. Хоть на диске храните, всё равно len(container) будет корректным выражением что для списка, что для другого класса эмулирующего __len__.

Да не оправдывайтесь, что уж там. Я же не в упрек вам. Как тут сказали, исторически сложилось.

> так напиши фильтр

Перловикам это не нужно, а пейтонисты не справятся.

>Чем что?

Чем другие скриптовые. Тот же писон например.

Боюсь, что за неделю вы научитесь только писать что-то типа анализатора логов.

+ можно научиться читать чужой код за эту же неделю (ключевой скилл для освоения ЯП на профессиональном уровне). Т.е. считай освоил синтаксические основы и некоторые паттерны.

С перлом так не пройдёт, пока не перечитаешь многие перлдоки не сможешь на достаточном уровне читать и понимать чужой код. Это уже будет пара месяцев практики. И всё это ради чего? Должен же быть в последствии определённый профит, какой он у ЯП уровня перла?

> Лол, а на Perl будто есть стандарт.

В каком-то смысле его нет (т.е. этакий строгий документ типа «C# language», где описано всё, вплоть до разлива кофе на клаву), но само руководство по языку (+ тонна сопутствующих PerlLOL, PerlRef, PerlFunc, etc) - вполне себе исчерпывающе. В КРАЙНЕМ случае - всегда есть возможность написать тестовый код и проверить сомнительное место.
(ну и Dumper в помощь)
Мне кажется, этой документации вполне достаточно.

> Вот и полная аналогия между, например, такой же дебильной ошибкой в Perl: написание @var вместо $var.

:))))))))))
Извините, но вы сейчас «дебильным» назвали свой моск, а не Перл. Ошибку сделали вы, а виноват - Перл?!! :))) @var и $var настолько же разные, как «+» и "-": оба состоят из чёрточек, но означают совсем разное.

Прелесть «$@%» нотации в том, что при беглом взгляде в код, сразу понятен контекст операции. Безликие же имена а-ля localDocs мне ни о чём не говорят. Венгерская нотация - мудаковатое воплощение той же $@% идеи.

Извините, но вы сейчас «дебильным» назвали свой моск, а не Перл

*тихо нашёптывает* не стреляйте по своим

> С перлом так не пройдёт, пока не перечитаешь многие перлдоки не сможешь на достаточном уровне читать и понимать чужой код. Это уже будет пара месяцев практики. И всё это ради чего? Должен же быть в последствии определённый профит, какой он у ЯП уровня перла?

Не знаю, не знаю...

Мне хватило 1-2 часа для понимания той перловой части, которая мне нужна: структурно простые системные скрипты, обработка текстов и т.д. Перл - отличный, идеальный язык для замены хоть сколько-нибудь сложных shell-скриптов. Но вот что-то сложное я бы на Перле не стал писать: слишком уж он незащищён от ошибок для программирования в большом. -w и ООП не очень-то спасают.

>> Вот и полная аналогия между, например, такой же дебильной ошибкой в Perl: написание @var вместо $var.

Аналогия не полная. Потому что скобки используются для вызова функций в БОЛЬШИНСТВЕ языков. А вот мистические @/$ - это уже личная перловская криптография.

Ну, хорошо, я хотел избежать этой банальности, но это судьба. Разница между @ и $ несоизмеримо больше разницы между " " и «   ». Ты хотел этого, Жорж Данден.

> Боюсь, что за неделю вы научитесь только писать что-то типа анализатора логов.

Обработку текстов на Python? Вы уже перестали принимать коньяк по утрам? Для этих задач есть другие языки: Perl, например.

Кстати, мой товарищ-админ хвастал Python следующим образом: «я просто пишу на этом языке». Типа, не надо ничего учить — один раз прочитал manual/tutorial и всё.

У Python'а есть чёткая грамматика, у Perl-а — нет. И этим всё сказано.

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

> Мне хватило 1-2 часа для понимания той перловой части

А написанное на Python можно было б просто прочесть. Представьте проект размером с LOR на Perl?

> А написанное на Python можно было б просто прочесть.

На Перле вобщем-то тоже. Просто я всё равно читаю хотя бы вводную по языку, прежде чем.

Представьте проект размером с LOR на Perl?

Я же сказал: заменитель shell в более-менее нетривиальных случаях, лёгкий системный скриптинг. Для структурно сложных задач python лучше (GUI, веб-сайты например). Но, опять же, писать какой-то скрипт, обвязывающий несколько системных утилит, на питоне мне влом :)

> Просто потому что литературы, сравнимой с Орейлевской Perl bookshelf, для Питона нет.

У питона есть мануал. Он очень простой и понятный. Никаких орейли не надо.

> Разница между @ и $ несоизмеримо больше разницы между " " и " ".

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

> Представьте проект размером с LOR на Perl?

Без проблем. Был же он когда-то на PHP :)

Ничего удивительно: PHP лучше Perl.

Перл - отличный, идеальный язык для замены хоть сколько-нибудь сложных shell-скриптов. Но вот что-то сложное я бы на Перле не стал писать: слишком уж он незащищён от ошибок для программирования в большом. -w и ООП не очень-то спасают.

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

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

Python как тайваньсикий — сложный, местами красивый, говорить не нужно.

> Аналогия не полная. Потому что скобки используются для вызова функций в БОЛЬШИНСТВЕ языков.

Тогда ИСПОЛЬЗУЙТЕ их! А не так, чтобы если аргумента нет, их ставить нужно, а если аргумент один, то не обязательно.

Кошмарность перла очевидна сразу. А поблемы с питоном приходится мучительно выдумывать.

Неудобна упомянутая выше нелогичность со скобками. Неудобно, когда функции то возвращают копию аргумента, то меняют его на месте. Неудобно, когда слово for означает разные вещи в зависимости от контекста (цикл или comprehension). Неудобно начинать строки с u'. Так же неудобно ставить целых три кавычки. Неудобно, что 3/2 равно 1. Неудобны mutable defaults. Неудобна питоновская реализация class variables в унаследованных классах. Неудобно отсутствие use strict. Неудобно, что x+=y это не то же самое, что x=x+y. Неудобна убогая лямбда.

Если бы оставили нотацию Haskell или Erlang, было бы проще.

Буквы набирать проще знаков препинания.

Нужно же и о читабельности думать.

> Ничего удивительно: PHP лучше Perl.

Ты, наверное, думаешь, что ты очень крутой программист. Легко рассуждаешь о том, о чём не понимаешь, остальные должны внимать разинув рот, видимо. Красный свет лучше зелёного. Чем лучше? Что лучше? Кому это вообще видно? В те годы, про которые речь (конец 90х, самое начало 2000х) PHP не мог быть лучше Perl ни в чём, кроме интеграции в код HTML, что порождало просто массу чудовищ. Тебе, видимо, когда-то так же, как и sniper21, Perl попытался изнасиловать мозг, но не обнаружил его на месте. Нападки питонистов в этом треде отличаются тупой ненавистью, это наводит на мысли...

>> Разница между @ и $ несоизмеримо больше разницы между " " и " ".

У вас проблемы с отступами?

У меня нет проблем со non-alphanumeric символами :)

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

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

> Сложность переписанного шелл скрипта на перле относительна и не постоянна во времени: cегодя она небольшая, а завтра понадобилось что-то дописать и так ещё много раз.

Так рассуждая, можно сразу браться за Java =)

Конечно, со временем скрипты растут, но процент _по-настоящему_ больших, выросших из маленьких, не так уж высок. Так что проще потом переписать с нуля, всё равно есть уже работающий прототип.

> Тогда ИСПОЛЬЗУЙТЕ их! А не так, чтобы если аргумента нет, их ставить нужно, а если аргумент один, то не обязательно.

Вы чё-то путаете питон с руби. В питоне всегда надо ставить. И никаких проблем.

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

Её, как я уже заметил, нет. Учите матчасть.

Неудобно, когда функции то возвращают копию аргумента, то меняют его на месте.

Какие именно функции возвращают копию аргумента? Расскажите нам, не стесняйтесь.

Неудобно, когда слово for означает разные вещи в зависимости от контекста (цикл или comprehension).

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

Неудобно начинать строки с u'. Неудобно, что 3/2 равно 1.

Fixed в 3.0.

Так же неудобно ставить целых три кавычки.

Это по сравнению с HEREDOC?!! Опять - бревно, глаз.

Неудобны mutable defaults. Неудобна питоновская реализация class variables в унаследованных классах.

Чем именно?

Неудобно, что x+=y это не то же самое, что x=x+y.

Для стандартных типов - то же самое.

Неудобна убогая лямбда.

Брехня, очень удобна. Опять-таки, в перле и такой нет.

Нужно же и о читабельности думать.

Читабельность букв выше читабельности каши из знаков препинания.

> PHP не мог быть лучше Perl ни в чём, кроме интеграции в код HTML

По крайней мере, там были более вменяемые массивы и синтаксис вообще.

> Нападки питонистов в этом треде отличаются тупой ненавистью,

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

Для «большого» есть все что нужно - средства анализирующие качество кода, фреймворки тестирования помогающие при забегах на длинные дистанции. Уже давно реализованы различные модули упрощающие реализацию идей объектно-ориентированного проектирования - паттернов: IOC, синглетоны, усилители референсного перлового ООП, прочие полезные прибамбасы.

Легко связывать подсистемы реализованные на других ЯП - прекрасно справляется с IPC и в CPAN хватает _качественных_ оберток для RPC.

Неудобно, когда слово for означает разные вещи в зависимости от контекста (цикл или comprehension).

в питоне нет циклов в традиционном понимании и потому for везде означает одно и то же.

Так рассуждая, можно сразу браться за Java =)

Ява уже игрок другой весовой категории. Альтернативы пока такие: perl, python и в какой-то степени ruby и tcl. Среди всего этого на данный момент лучше всего (в нашем контексте) подходит питон.

Нет ненависти, и всё тут. Конечно, корявые игрушки (вроде Python) не стоит использовать как инструмент для работы, при наличии более адекватных аналогов, при наличии Ruby и Scheme. Согласен с Вами.

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

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

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

>Ага, backport из Perl 6.
Ну не совсем.

Я не очень понимаю слов «даже переписали фреймфорк Catalyst». Его просто портанули.

Ну там много чего переписали.Правда и кушать ОЗУ он начал больше )

Не, Moose хорошая штука, и вот с ним-то начиная можно и с Perl5 работать.

Да,в плане ООП,возможно

Ну не одним каталистом живем!
Есть же mojo, dancer, из популярных.

Кстати, реквестирую серию уроков о работе с Catalyst.

>> Тогда ИСПОЛЬЗУЙТЕ их! А не так, чтобы если аргумента нет, их ставить нужно, а если аргумент один, то не обязательно.

Вы чё-то путаете питон с руби. В питоне всегда надо ставить. И никаких проблем.

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

Неудобно, когда функции то возвращают копию аргумента, то меняют его на месте.

Какие именно функции возвращают копию аргумента? Расскажите нам, не стесняйтесь.

Да хотя бы sort. Или lower.

Неудобно, когда слово for означает разные вещи в зависимости от контекста (цикл или comprehension).

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

Я же говорил, что с высоты моего происхождения разницы между Perl и Python не видно.

Неудобны mutable defaults. Неудобна питоновская реализация class variables в унаследованных классах.

Чем именно?

Тем, что в производном классе используется значение class variable, взятое из класса-родителя. Но если попытаться присвоить ему значение, у производного класса тут же появится своя копия class variable. После этого изменение значения переменной в классе-родителе уже не изменит значения этой переменной в потомке.

Неудобно, что x+=y это не то же самое, что x=x+y.

Для стандартных типов - то же самое.

Вот-вот. А в голове-то это держать надо.

Неудобна убогая лямбда.

Брехня, очень удобна. Опять-таки, в перле и такой нет.

Еще бы не удобна :). Только урезана по самое не могу.

> корявые игрушки (вроде Python) не стоит использовать как инструмент для работы, при наличии более адекватных аналогов, при наличии Ruby и Scheme

Ruby объектный, вычеркните его! :)

> в питоне нет циклов в традиционном понимании и потому for везде означает одно и то же.

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

>Кстати, реквестирую серию уроков о работе с Catalyst.

http://yapc.tv/2008/fe/roman-catalyst/

> Если я вдруг решу освоить питон, я уверен, я найду от чего плеваться, и что мне не так, и если после этого ещё приду в тред про питон и начну всем объяснять какие они идиоты, что используют жуткую кривизну

Обычно люди, которые переходят на питон, радуются как дети - всё начинает адекватно работать и перестаёт глючить.

>Обычно люди, которые переходят на питон, радуются как дети - всё начинает адекватно работать и перестаёт глючить. Нет, всё перестаёт глючить при переходе на Haskell. Или на любой другой язык со статической типизацией.