> ...пока не получите производственную травму мозга при написании крупного проекта на Perl. Зато потом очень быстро перейдете на Python, доказано лучшими жемчужными змееводами.

15 тыщ строк, это достаточно крупный проект на Perl? И продолжает развиваться...

> Я изучал Перл ну примерно в описываемых масштабах - 15 лет назад. Сейчас пишу генератор интерфейса НА ТЕХ ЖЕ САМЫХ ЗНАНИЯХ, разве что given/when добавилось. :) Счаслив непомерно, что не нужно как студент заново прыгать вокруг банальных перетасовок синтаксиса.

Аналогично. Т.е. +1.

> нет, я конечно уважаю труд автора, просто не уважаю сам язык.

Так говорят люди, на которыми было совершено насилие. Perl изнасиловал тебе мозг? Или пытался, но его не оказалось на месте?

*читает комменты и с нетерпением ждёт, когда же восторженные школьники с питоном, так кричащие про свой профессональный инженеризм, перепишут все _действительно_ высоконагруженные проекты и утилита для анализа данных на свой язык-для-расстановки-отступов*

что такое кэмелбук? Programming Perl от Ларри?

Классы замечательны своей примитивностью и гениально встроены в язык. С магией типа mro сталкиваюсь только когда она действительно нужна в низкоуровневом API - базовой библиотеке которая один раз пишется и накрывается тестами. Частично магические заряды рассеяны по CPAN-модулям (синглетоны, IOC и прочие заморочки фанатов GoF)

Немного странной и слабой кажется ООП-абстракция - отсутствуют стандартные методы для ограничений private/public.Идеология «не лезь в чужие дела» тоже может быть минусом для тех кто привык брать от жизни все что можно. Усиливать эту абстракцию можно как угодно используя модули.

На практике довольствуюсь несколькими mixin которые дают максимальную простоту и эффективность: свой велосипед на базе Class::Base и дефолтный Class::Accessor::Fast для автоматической генерации акцессоров-мутаторов (всегда в стиле follow_best_practice). Получается красивый, понятный и достаточно строгий код который легко поддерживается - внутри нет магии.

Для задач которые хорошо ложатся на объектную модель можно использовать Moose - еще один пример расширяемости языка (для сильных духом).

> Классы замечательны своей примитивностью и гениально встроены в язык.

Я в децтве скипнул программирование под вин* как раз в силу примитивной гениальности системной eventloop, когда одно неосторожное движение, и даже не твоё, и приехали. На моей совести, если что, есть несколько пофикшеных перловых модулей с CPAN. Ладно, аналогия кривая. Я же говорю, Object::InsideOut вполне ничо, с автоматическим генерированием геттеров/сеттеров, private/public, и разными фишками. _Почти_ нормально.

Мифы перл. Для скептиков которых укусил верблюд и прочих гуманоидов интересующихся платформой: http://kapranoff.ru/talks/devconf-2010/perl_myths.html#1

С мнением автора слайдов согласен на 99%. Платформа интересная и продолжает развитие.

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

Очевидность уж точно не фича перла со своими неявными переменными на каждом шагу и геморным синтаксисом.

совершенно верно, его так называют за верблюда на обложке. ;3

Хочу сказать, что camel book на мой взгляд не очень подходит на роль учебника

ну так это и не учебник :)

Но начинал я учить перл именно с него, оттуда же узнал и про перлодоки, сейчас даже придушив жабу купил себе в бумаге, для перлопрогера must have

>Классы в перле это ужас на крыльях ночи. Да, я использую Object::InsideOut, или вообще голые классы, но счастья как-то мало, видеть и использовать все внутренности руками.

Посмотри в сторону Moose ( http://search.cpan.org/~flora/Moose-1.07/lib/Moose.pm ) Это крутая обертка для ООП. на нем даже фреймворк Catalyst переписали.

P.S Да и кстати в perlовиков есть свои сообщества(perl mongers http://pm.org ) в которых всегда можно задать вопрос (пример moscow.pm.org )

> Правда, в Python/Ruby/etc он (или очень на него похожий) тоже присутствует, просто не так бросается в глаза, по каковой причине часто им часто пренебрегают. А зря.

Он не бросается в глаза, потому что 1) его почти нет 2) он не создаёт проблем, т.к. при ошибке типизации программа сразу вылетает в эксепшн ещё на отладке. Перловая же программа легко может улететь на марс и не заметить этого.

> да ну ? это от какого года статья ?

2010, мой юный анонимный друг.

http://www.securityninja.co.uk/your-choice-of-programming-language-doesn%E2%8...

99,99% уязвимостей - плохая фильтрация данных. Какая связь с интерпретатором ? Это два.

Связь очень простая: «программисты» на перле - раздолбаи с завышенным самомнением. Перл потворствует написанию ковбойского кода - вот они его и пишут.

Слава богу, пионеры вымирают естественным путём.

Связь очень простая: «программисты» на перле - раздолбаи с завышенным самомнением. Перл потворствует написанию ковбойского кода - вот они его и пишут.

толсто, я бы такое отнес только к начинающим

За линк на презентацию спасибо. Включил его в последнюю статью.

> перепишут все _действительно_ высоконагруженные проекты и утилита для анализа данных на свой язык-для-расстановки-отступов*

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

«Утилиты для анализа данных» перепишут тогда, когда это будет оправдано экономически. Тогда же, когда и перепишут миллионы строк софта на Коболе. Старые неудачные языки помирают медленно, но верно.

> толсто, я бы такое отнес только к начинающим

Никто не спорит, что при известной дисциплине можно и на брэйнфаке писать. Но лучше таки огородить опасную каку ленточкой, поставить красный флажочек и пользоваться более надёжными, масштабируемыми и ПОДДЕРЖИВАЕМЫМИ средствами.

> Посмотри в сторону Moose

Пасиб, посмотрю :)

P.S Да и кстати в perlовиков есть свои сообщества(perl mongers http://pm.org ) в которых всегда можно задать вопрос (пример moscow.pm.org )

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

> Очевидность уж точно не фича перла со своими неявными переменными на каждом шагу и геморным синтаксисом.

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

> Связь очень простая: «программисты» на перле - раздолбаи с завышенным самомнением. Перл потворствует написанию ковбойского кода - вот они его и пишут.

Я не очень понял, кто присвоил тебе право присваивать ярлыки. Он? Или ты самовольно как-то? Не надо говорить за всех программистов.

Лень смотреть на слоника в домене. У меня есть проект на mod_perl и POE, глюки только мои собственные. Демон на POE работает в качестве сервера приложения в отдельной виртуалке. Не падает. Поскольку девелопится всё ещё активно, и отлаживается перманентно, то между перезапусками успевает пройти всего несколько дней, но видно, что память не течёт, всё работает исправно. Суммарно около 12 тыщ строчек кода в сервере приложения и 3 тысячи на mod_perl.

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

> Никто не спорит, что при известной дисциплине можно и на брэйнфаке писать. Но лучше таки огородить опасную каку ленточкой, поставить красный флажочек и пользоваться более надёжными, масштабируемыми и ПОДДЕРЖИВАЕМЫМИ средствами.

Брань, ссылки на чужой опыт, максимализм. Ты школу уже успел закончить?

>Ты школу уже успел закончить?

Ты шо, это же профессиональный(r)(c)(tm) инженер(r)(c)(tm) программист(r)(c)(tm)

>Связь очень простая: «программисты» на перле - раздолбаи с завышенным самомнением

спасибо. всё ясно. весьма показательное заявление.

Полистал блог slonik-v-domene, занятно. Если, как по вашему perl - [censored], откуда ж у вас столько кода на нем ? Или в вашей компании, все кроме вас одни [censored] работают ?

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

Это просто не правда.

немного пасты для пестонов

Мы часто слышим, как говорят: «Perl — мертв». Я полагаю, что вы не согласны, но что вы отвечаете людям, которые говорят вам это?

Дамиан КонвейОбычно я отвечаю: «Я согласен. Жаль, не так ли?». После этого сумасшедшие тихо сливаются, а я могу опять загрузить новый или улучшенный перл-модуль, увеличивая нынешние семь гигабайт открытого кода на спане (как это каждый месяц делают более 700 других разработчиков), или поехать на десятки перл-конференций и воркшопов, которые ежегодно проводятся во всем мире, или посетить одну из 250 PM-групп в 58 странах, или пообщаться с тысячами единомышленников, помогающих друг другу на главном сайте про изучение перла perlmonks.org, или принять участие в онлайновой социальной и образовательной деятельности (например, в соревновании Perl Iron Man), или обновиться до нового релиза Perl 5 и Perl 6 (оба они теперь выходят ежемесячно), или внести вклад в активный процесс разработки либо одной из двух реализаций Perl 5, либо в одну из четырех — Perl 6, или обучить десяткам новых возможностей, которые добавлены в Perl 5.10 и Perl 5.12 за последние три года, или заняться разной деятельностью по омоложению перла (enlightenedperl.org и modernperlbooks.com) или просто почитать замечательный обзор Тима Банса о том, насколько, на самом деле, мертвый перл жив, как никогда.

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

> Тима Банса

Он только Тим Бунс - умный мужик, на Highload в прошлом году много интересного толкал. Но конечно лоровские шольники стократ умнее.

На перле еще кто-то кодит?

спасибо

На самом деле перл популярен среди инженеров. Не веб-быдло-кодеров, которые почему-то называют себя инженерами, а нормальных инженеров. Ибо ничего лучше перла для обработки текстовых файлов пока не придумали. Вы конечно будете смеяться, но самые популярные у нас языки - perl, Tcl и scheme. Perl - для написания фильтров и автоматизации, tcl и scheme - встроены в тулы. А питон и иже с ними никто не использует. Так что перл живее всех живых. Ну и лоровские аналитики как всегда жгут напалмом.

>$name = shift();

Дальше не читал. Плохому учите.

> Это крутая обертка для ООП.

Ага, backport из Perl 6.

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

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

А производительность-то производительность! Перл медленн.

>> Правда, в Python/Ruby/etc он (или очень на него похожий) тоже присутствует, просто не так бросается в глаза, по каковой причине часто им часто пренебрегают. А зря.

Он не бросается в глаза, потому что 1) его почти нет 2) он не создаёт проблем, т.к. при ошибке типизации программа сразу вылетает в эксепшн ещё на отладке.

Там своих тараканов немеряно. В Python, например, вызов file.close, который не закрывает файл (должно быть file.close() (ну, почему не close(file)?!)), арифметические операции со строками, полная путаница с mutable/nonmutable объектами (включая mutable defaults, но не только) и с функциями, которые то ли возвращают копию, то ли меняют объект на месте. Comprehensions are incomprehensible, извините за каламбур.

Какой-то умный человек сказал: „The primary design principle behind the Python programming language is to take everything that’s horrible and wrong with Perl and get it horrible and wrong in a completely different and even more hideous way.“

> Если, как по вашему perl - [censored], откуда ж у вас столько кода на нем ?

В компании, в которой я работаю, кода на перле практически нет.

Откуда в мире столько много кода на перле - примерно оттуда же, откуда и много кода на коболе. Перл был практически первым «скриптовым» языком и через это стал весьма популярен.

Но, к щастью, его время уходит.

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

Некоторое время вы будете раздуваться, факт.

ага, но вот-вот, еще чуть чуть и все, лопнет перловский пузырь, да?

> В Python, например, вызов file.close, который не закрывает файл (должно быть file.close()

Потому что вызов функций производится при помощи скобок. А ещё вода мокрая. И небо обычно голубое. Я ещё вам могу кучу новостей сообщить!

полная путаница с mutable/nonmutable объектами

Где??? Иммутабельны только строки, кортежи и frozenset. Это описано в документации. Всё. Откуда путпница-то?

и с функциями, которые то ли возвращают копию, то ли меняют объект на месте

Всё в документации описано чёрным по белому. Деструктивные функции ещё и возвращают None, на всякий случай. Это вам не Java.

Comprehensions are incomprehensible, извините за каламбур.

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

Короче, какие-то совершенно детские доводы.

> ага, но вот-вот, еще чуть чуть и все, лопнет перловский пузырь, да?

Отнюдь. Чтобы лопнуть - надо надуваться, а он на самом деле тихо пшшшш...

http://www.tiobe.com/index.php/paperinfo/tpci/Perl.html

угу,«упадок» у перла это проходит как бум у пистона:
http://www.tiobe.com/index.php/paperinfo/tpci/Python.html

Там в первой 5рке java, плюсы, пиэйчпи и васик.
Еще можешь статистику показать для windows vs linux, ага.
Только воршопов, новых модулей и программ от этого не меньше.

>> В Python, например, вызов file.close, который не закрывает файл (должно быть file.close()

Потому что вызов функций производится при помощи скобок.

А сообщения об ошибке нет. Просто молча едем дальше с открытым файлом.

полная путаница с mutable/nonmutable объектами

Где??? Иммутабельны только строки, кортежи и frozenset. Это описано в документации.

Еще числа. Вот именно, что часть mutable, часть нет. Sets могут быть mutable, а могут быть frozen, а строки почему-то нет, только immutable.

Comprehensions are incomprehensible, извините за каламбур.

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

Нотация, используемая в Python, не математическая, а уродливая, хуже, чем __INIT__. Кстати, о подчеркиваниях. С какой радости len() у нас функция, а __len__ – метод?

А производительность-то производительность! Перл медленн.

Чем что? Почти все контуренты ему сливают, причём некоторые в разы.

>> и с функциями, которые то ли возвращают копию, то ли меняют объект на месте

Всё в документации описано чёрным по белому.

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

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

Там своих тараканов немеряно. В Python, например, вызов file.close, который не закрывает файл (должно быть file.close() (ну, почему не close(file)?!))

Если ВЫ не знаете чем отличается ссылка от вызова, то вам вообще не стоит никогда заниматься программированием. Тем более синтаксис вызова как «ссылка()» присутствует практически во всех современных языках.

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

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

> Только воршопов, новых модулей и программ от этого не меньше.

Да пусть себе маргиналы суетятся, вспоминают молодость. Со временем вымрут.

Вот именно этот пример вы искусственно высосали из пальца (долго, наверное, думали?). И я ещё раз напишу почему

синтаксис вызова как «ссылка()» присутствует практически во всех современных языках

> А сообщения об ошибке нет.

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

Еще числа.

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

а строки почему-то нет, только immutable.

Во-первых, для этого есть array('c'). Во-вторых, мутабельные строки практически не нужны.

Нотация, используемая в Python, не математическая, а уродливая,

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

Кстати, о подчеркиваниях. С какой радости len() у нас функция, а __len__ – метод?

Увы, исторические причины.