После года разработки состоялся (http://www.nntp.perl.org/group/perl.perl5.porters/2016/05/ms...) релиз новой стабильной ветки языка программирования Perl - 5.24 (https://metacpan.org/release/perl). При подготовке нового выпуска было изменено около 360 тыс. строк кода, изменения затронули 1800 файлов, в разработке приняли участие 77 разработчиков.Ветка 5.24 выпущена в соответствии с утверждённым пять лет назад фиксированным графиком разработки, подразумевающим выпуск новых стабильных веток раз в год и корректирующих релизов - раз в три месяца. Примерно через месяц планируется выпустить первый корректирующий релиз Perl 5.24.1, в котором будут исправлены наиболее значительные ошибки, выявленные в процессе внедрения Perl 5.24.0. Одновременно с выходом Perl 5.24 прекращена поддержка ветки 5.20, для которой в будущем могут быть выпущены обновления только в случае выявления критических проблем с безопасностью. Также начался процесс разработки экспериментальной ветки 5.25, на базе которой в мае 2017 года будет сформирован стабильный релиз Perl 5.26.
Ключевые изменения (https://metacpan.org/pod/release/RJBS/perl-5.24.0/pod/perlde...):- В разряд стабильных возможностей переведена операция постфиксного разыменования (postderef), которая ранее поставлялась в числе экспериментальных функций и требовала активации специального флага "use feature postderef". Операция постфиксного разыменования "$sref->$*" эквивалентна "${ $sref }", "$aref->@*" эквивалентна "@{ $aref }", а "$href->%{ ... }" - "%$href{ ... }";
- Добавлена поддержка Unicode 8.0 (http://www.unicode.org/versions/Unicode8.0.0/);
- Реализована генерация ошибки в случае неудачного закрытия выходного файла. Ранее сбой при закрытии выходного файла мог привести к проблемам, так как ошибка не фиксировалась, например, при выполнении операции фильтрации входного файла с его последующим удалением;
- В регулярных выражениях появился новый оператор "\b{lb}", определяющий место в Unicode-строке, в котором последовательность символов может быть разорвана для того, чтобы вывод уместился в заданную ширину экрана. Ранее возможность поставлялась в виде модуля Unicode::LineBreak (http://search.cpan.org/~nezumi/Unicode-LineBreak-2016.003/li...);- Скобки (http://search.cpan.org/~rjbs/perl-5.24.0/pod/perlrecharclass...) "qr/(?[ ])/" c расширенными условиями определения классов символов теперь применимы для включенных через "use locale" локалей UTF-8. Задаваемые в скобках шаблоны преобразуются в штатные правила Unicode;
- Более явно определены операции сдвига целых чисел ("<<" и ">>"), которые теперь не зависят от поведения реализации на Си. Например, точно определено поведение при сдвиге отрицательных чисел и при переполнении числа. Сдвиг отрицательного числа определён как операция сдвига в обратную сторону (операция сдвига отрицательного числа влево приведёт к выполнению сдвига вправо и наоборот). Выходящие за границы сдвигаемые биты воспринимаются как ноль;
- В printf и sprintf добавлена возможность применения обратного порядка указания аргументов настройки точности, например, вызов "sprintf '|%.*2$d|', 2, 3" вернёт "|002|";
- Расширено число полей, передаваемых в callback-обработчик sigaction, вызванный с флагом SA_SIGINFO. В число таких полей теперь входят errno, status, uid, pid, addr и band;
- Расширены правила передачи скрипта в другой интерпретатор. Ранее передача осуществлялась если в заголовке скрипта отсутствовало слово "perl" (например, "#!/bin/sh"). Теперь проброс также осуществляется и при наличии слова perl6 для улучшения совместимости с Perl 6;
- Несовместимые изменения:
- Прекращена поддержка экспериментальных переменной "my $_" и функции авторазыменования (autoderef), которые признаны неудачными нововведениями. Переменная "my $_" была добавлена в Perl 5.10 и вызывала больше путаницы, чем пользы. Механизм autoderef позволяющий выполнить push/pop/... для каждого скалярного аргумента также не получил распространения;- Прекращена поддержка вложенных выражений определения переменных. Блоки my, our и state теперь не могут пересекаться, например, выражение "my ($x, my($y))" является недопустимым;
- Некоторые шаблоны регулярных выражении, приводящие к ошибкам во время выполнения, теперь приводят к выводу ошибки во время компиляции выражения (т.е. ошибка выводится сразу, а не через какое-то время работы программы). Например, добавлены предварительные проверки корректности использования шаблонов \p{} и \P{};
- Ничего не делающее выражение "qr/\N{}/" (пустой "\N{}") теперь недопустимо в режиме "strict";- Прекращена поддержка класса символов "/\C/", для оценки отдельных байтов строки UTF8 рекомендуется использовать utf8::encode();
- Вызов chdir('') теперь не приводит к смене текущего пути на домашнюю директорию, следует использовать chdir();
- Все ASCII-символы, используемые в именах переменных, должны быть видимыми;
- В категорию устаревших возможностей переведено использование функций sysread(), syswrite(), recv() и send() с обработчиками :utf8;- Производительность:
- Сокращены накладные расходы при входе и выходе из области видимости, что привело к ускорению вызова подпрограмм, циклов и базовых блоков. Например, вызов пустой функции "sub f{} f()" теперь занимает на треть меньше времени;
- На платформах с поддержкой оптимизированных реализаций memchr() в libc значительно ускорено выполнение операций с шаблонами, в которых используются фиксированные строки. Например, на системах с memchr() с оптимизациями для современных x86_64 CPU выражения $s = "a" x 1000 . "wxyz" и $s =~ /wxyz/ for 1..30000 выполняются в 7 раз быстрее, чем при использовании неоптимизированного варианта memchr(). Отмечаются и регрессии для достаточно нетипичных применений, например, "ab" x 1000 =~ /aa/ выполняется в 1.5 раза медленнее;- Ускорены операции сложения, деления и умножения 64-разрядных целых чисел за счёт оптимизации проверки пограничных условий;
- Ускорены операции инкремента и декремента (++i, i++, --i, i--) ха счёт выноса обработчиков разных условий в разные функции;- Значительно ускорены операции присвоения списку единственного аргумента, например "($x) = (...)" или "(...) = ($x)";- Снижено пиковое потребление памяти, наблюдаемое в моменты компиляции шаблонов регулярных выражений;
- Безопасность:
- Изменено поведение установки маски прав доступа при создании временных файлов. В 5.22 маска устанавливалась в 0600 до вызова mkstemp(3) и восстанавливалась после вызова, что приводило к появлению файлов с правами 0066 (доступ на запись и чтение) на системах с применяемой по умолчанию маской 0666. В новой версии в качестве значения umask используется 0177;- Решены проблемы (CVE-2015-8608 (https://rt.perl.org/Public/Bug/Display.html?id=126755)) с доступом к областям вне границы буфера в коде обработки файловых путей на платформе Win32;
- Уязвимость в XS File::Spec::canonpath (CVE-2015-8607 (https://rt.perl.org/Public/Bug/Display.html?id=126862));
- Добавлены дополнительные проверки для защиты от обращения к неинициализированной памяти при вызове функции crypt() на платформе Win32. В том числе добавлена проверка на использование слишком коротких значений salt или указания некорректных символов в salt;- Обеспечено удаление дубликатов переменных окружения в хэше %ENV. Ранее сохранялся последний из дубликатов, в то время как getenv() возвращал первый, теперь поведение унифицировано. Дубликаты также удалены из environ[], что прикрыло возможные способы атаки (CVE-2016-2381);
- Обновлены версии модулей, входящих в базовую поставку.- В состав возвращён порт для платформы AmigaOS. Во FreeBSD задействована (https://rt.perl.org/Ticket/Display.html?id=126847) функция fdclose(). Включена большая порция изменений, связанных поддержкой работы на платформе Win32;
URL: http://perlnews.org/2016/05/perl-5-24-released/
Новость: http://www.opennet.ru/opennews/art.shtml?num=44394
Лучший скриптовый язык. Неосиляторы, минусуйте!
Согласен. Именно как скриптовый в оригинальном понимании - "быстро накидать автоматизацию для себя, часто - на один раз" перл даже сравнить особенно не с чем.
Неосилятор, но минусовать не буду. Буду плюсовать и завидовать.
Только вот встречаются не редко проекты по типу "начали писать на perl. Ой фак. Переписали на python. Полет нормальный".PS Не фанат python.
Да, для проектов его сейчас применять не стоит.
Можно узнать, почему?
Наверное, собеседник не до конца правильно выразился. В принципе, если есть слаженная команда, то очень даже стоит. А если строить команду с нуля для разработки, то появляется проблема кадров: программистов на перле найти тяжелее, чем на жс/руби/другом модном языке.
На перле как правило спецы работают. На фронтенд перловиков сажать реально не нужно и дорого.
Почему же на фронтэнд? На сколько я в курсе текущей ситуации (а я могу быть совсем не в курсе), то всё указанное выше сейчас прекрасно работает бекендах.А по поводу спецов — всё верно. На перле либо только-только начавшие учить язык, либо спецы, которые за среднюю зарплату не пойдут пилить проекты. Уверенных середнячков на перле найти сложно, куда проще на других популярных языках.
Я выразился ровно так, как и хотел. Учитывая, что моим основным языком был перл не один год - я знаю, о чём говорю. То, что нужно поддерживать/расширять, лучше писать на рубях/питонах/Go/D/ещё чём-то. И дело в чисто технических недостатках. Одного отсутствия нормальных прототипов и проблем с юникодом хватит. Причём юникод там так хитро поломан, что если для конкретного случая можно подкостылить, то наваять какой-то общий подход довольно проблематично - слишком много вариантов, особенно у модулей. А принципиальных преимуществ для написания софта нет по сравнению с конкурентами. Ну и скорость у него так себе, если не считать процессинг текста. Особенно если об ООП речь идёт.Лет N назад всё было по-другому - Перл - это ж практически первый скриптовый язык, на котором можно что-то большое написать.
> Лучший скриптовый языкЛучший скриптовый язык это тот на котором пишешь, а так нету времени учить мне все языки программирования
Так разберись с Perl и появится время на другие языки или что-нибудь еще. :)
действительно, если вместо работы учить перл - много времени может высвободиться. особенно если работаешь авиадиспетчером или хирургом.
> ... авиадиспетчером или хирургом.Слабак! Я вот бывало прибегу после смены авиадиспетчером в поликлинику и по 10 операций за ночь. А после поликлиники еще и таксовал, а пока клиентов ждал перл учил с планшета.
В принципе я еще и на машинке вышивать умею.
Операции ночью в поликлинике? Вы там органы вырезали что-ли?.. Кошмар. Вот какие у нас диспетчера во еропортах оказыца...
Ващщета, травмпункты работают круглосуточно...
> Лучший скриптовый язык. Неосиляторы, минусуйте!сколько скриптовых языков ты знаешь?
>> Лучший скриптовый язык. Неосиляторы, минусуйте!
> сколько скриптовых языков ты знаешь?Он знает один, разумеется. И это не баш! :)
а когда он сдохнет из-за несовместимости версий не подскажете?
Призываю в тред ненавистников проверенных стабильных версий, пусть популярно объяснят народу, что Perl 5 давно пора похоронить и прекратить поддерживать, а нынче писать можно только на Perl 6 (да-да, тех самых из соседнего треда, кто агитировал за Python 3 и не понимал, почему в реальности все продолжают писать на Python 2).
зачем хоронить - пусть чернь поддерживает легаси проекты на perl.
а мы будем писать на языке бояр - Go.
> а мы будем писать на языке бояр - Go.Писать на языке бояр - не значит быть боярином! Так смердом и закончишь :)))
>> а мы будем писать на языке бояр - Go.
> Писать на языке бояр - не значит быть боярином! Так смердом и
> закончишь :)))Кто из грязи вышел в князи - тот не человек (с) Русская поговорка, кстати.
> Perl 5 давно пора похоронить и прекратить поддерживать, а нынче писать можно только на Perl 6У тебя задержка развития? Жалость то какая :( Ну ничего, лет ещё чере 10 до тебя тоже дойдёт что это два разных языка. Как С и С++.
> соседнего треда, кто агитировал за Python 3 и не понимал, почему в реальности все продолжают писать на Python 2).
В какой реальности? Поставь бубунту - там тольуо третий питон уже. Второй - если нуже - надо ставить руками. И так - везде.
> У тебя задержка развития? Жалость то какая :( Ну ничего, лет ещё чере 10 до тебя тоже дойдёт что это два разных языка. Как С и С++.Да мне, в общем, без разницы; просто несколько смешно читать комментарии людей, не понимающих всю разницу между python 2 и 3, но почему-то считающих, что perl 6 сильно отличается от perl 5. Принципиально (читая http://perl6.su/charta.html и https://doc.perl6.org/language/5to6-nutshell) это один язык, несколько измененный синтаксис вполне себе покрывается автоматическим преобразованием. Ссылки на некоторые из них есть в конце второго документа, кстати.
Это примерно соответствует изменениям синтаксиса python 2 -> 3 (где тоже можно применить автоматический транслятор 2to3 и получить из python 2 кода нечто, синтаксически пригодное для python 3. В теории. На практике, конечно, без ручной правки не обойтись).> В какой реальности? Поставь бубунту - там тольуо третий питон уже. Второй - если нуже - надо ставить руками. И так - везде.
Ну, что там из коробки - это одно дело. А в реальном софте лишние проблемы с python3 (без каких-либо явных преимуществ) никому не сдались, когда все модули гарантировано собираются и проверяются под python2, а пытаться разобраться с проблемами, насколько что хорошо работает под python3 (не получая ничего взамен) никому особо не нужно. И пишут под python2, не заморачиваясь. По-моему за пределами django python3 никому не интересен от слова "совсем".
Т.к. perl 6 вышел позже python 3, мне было любопытно, выучится ли Ларри Уолл на ошибках python и сумеет ли сделать так, чтобы люди действительно переходили - и можно было прекратить поддерживать предыдущую версию. К сожалению, похоже, не вышло.
На самом деле, это грустно, конечно. С точки зрения прогресса я за то, чтобы все писали на perl 6 и python 3 и не думали о предыдущих версиях. А с точки зрения реальности - пишу постоянно кучу python 2 кода и не имею никакого интереса в python 3 (кроме чистого любопытства), как и другие разработчики. Никак преимущества не покрывают всего, что сломается или просто изменилось в синтаксисе.
У perl6, в отличии от python3, нет пригодных к использованию реализаций. Какая разница насколько хорош perl6, если он работает в 40 раз медленее perl5. Также я бы отметил, что Ларри, в отличии от Гвидо, не призывает к переходу на perl6.
> У perl6, в отличии от python3, нет пригодных к использованию реализаций. Какая
> разница насколько хорош perl6, если он работает в 40 раз медленее
> perl5. Также я бы отметил, что Ларри, в отличии от Гвидо,
> не призывает к переходу на perl6.На баше пиши. И будет щастье.
много ли вакансий вы выдели за последние пару лет для перла?
Но если в резюме увидят опыт работы с perl, написание многопоточной системы или обёртки на Plack, то у взорслых ИТ-шников сразу будет неосознанный прилив уважения в вашу сторону. Знает перл, значит смог в этих сумбурных хитросплетениях разобраться, значит не глупый человек.
>...сразу будет неосознанный прилив уважения в вашу сторону.А семью свою вы этим приливом уважения накормите?
>>...сразу будет неосознанный прилив уважения в вашу сторону.
> А семью свою вы этим приливом уважения накормите?Хм... Знакомые перловщики голодными и затравленными не выглядят ... Шифруются? :)
Массовую статистику и перспективу для освоения ЯП предъявите?Как ни крути, но если ЯП позволяет незатейливо выражаться
по принципу "Смотри как я умею!", то абсолютно нулёво,
что ты будешь соблюдать при написании своих скриптов.
Ты не один. А значит будешь тратить время на расшифровку
очередного смотрикакяумею стиля.
Наверно поэтому, очень желательно иметь ТЗ(а не сам Perl код)
и переписать всё по своему смотрикакяумею.
Именно в этом проблема, и в Perl она выраженна наиболее показательно.
>Массовую статистику и перспективу для освоения ЯП предъявите?Зачем? Ресурсов с подобным в сети >> 1 - иди да смотри ...
Но как это отменит зе факт о котором я писал? Не голодают сволочи! :)
И ещё - твой успех в последнюю очередь будет зависеть от языка который ты выучил ... вот такая вот фигня! :)
> Как ни крути, но если ЯП позволяет незатейливо выражаться
> по принципу "Смотри как я умею!", то абсолютно нулёво,
> что ты будешь соблюдать при написании своих скриптов.Ну вот вам очередной смотрикакяумею:
def unique(_, __ = type({( )})):
__ = type("""
.-=-. .--.
__ .' '. / " )
_ .' '. / .-. \ / .-'\
( \ / .-. \ / / \ \ / / ^
\ `-` / \ `-' / \ `-` /
jgs`-.-` '.____.' `.____.'""", (__,),
{'_' : __.__dict__[filter(lambda _: '_' not in _,
sorted(__.__dict__))[::-1].pop()]})( {( )} )
return [_ for _ in _ if _ not in __ and not __._(_)]
И как, от того, что это питон, легче читается?
С документацией более удобно читать код на любом языке.
Почему то, не учитывают, что Ларри лингвист. И он создал язык программирования более близкий к языку человека. Человек может описывать одно и то же разными словами и это же характерно для PERL.
И не надо смешивать в одну кучу стиль оформления кода, особенности кодирования и возможности языка. Это не правильно.
Есть разные задачи для которых более подходящим являются те или иные языки. Есть задачи для PERL, и их в общем числе задач стало относительно меньше, но они никуда не делись, о них стали меньше болтать. Примерно такая же ситуация с фортраном кода много, он используется, а болтавни фактически нет.
Вполне.
http://www.raidix.ru/vacancy/team-lead-perl/
> Ранее передача осуществлялась если в заголовке скрипта отсутствовало слово "perl" (например, "#!/bin/sh").не распарсил
>> Ранее передача осуществлялась если в заголовке скрипта отсутствовало слово "perl" (например, "#!/bin/sh").
> не распарсилman perlrun
Питон и перл - основа современных linux дистрибутивов. Только пакеты питона в убунте занимают 413 мегов. Это ценнейшая фишка! Если удалить - ничего не останется, нечему будет лагать, тормозить и забивать память. А так не интересно.
Например, CentOS 7 Minimal уже идёт без предустановленного Perl.
А ещё, CentOS 7 Minimal идёт с предустановленным systemd.
>Все ASCII-символы, используемые в именах переменных, должны быть видимымикэп, не могли бы вы разъяснить это нововведение? интересуют невидимые ASCII-символы
Названия переменных могли содержать управляющие сивмолы. Например переменную $^X - путь к текущему интерпретатору, можно было писать в виде $^X, где ^X - один символ, в vim-е можно ввести через CTRL_V CTRL_X в режиме вставки. Не бог весть какая фича, но кому она мешала, непонятно. В 5.22 вроде повесили варнинг на такие имена, что поломало например AnyEvent::Fork
\b & friends?
Пошёл стирать пыль с АМИГИ....
честно, я пытался, два раза осилить сабж, но не осилил. В итоге ушел на python.
> честно, я пытался, два раза осилить сабж, но не осилил. В итоге
> ушел на python.Молодец. Куда послали - туда и пошёл.
Я бы на твоем месте постеснялся публично расписываться в ниасиляторстве. Тем более, что на базовом уровне perl осваивали все быдлокодеры допыховой эпохи, да и среди сисадминов это довольно распространенный навык.
> Я бы на твоем месте постеснялся публично расписываться в ниасиляторстве. Тем более,
> что на базовом уровне perl осваивали все быдлoкодеры допыховой эпохи, да
> и среди сисадминов это довольно распространенный навык."Сисадмин" не синоним слова "идиoт". Для сисадминства достаточно шеллов. Выше крыши.
Эх ты! Даже девчонки смогли Perl осилить!https://www.youtube.com/watch?v=lhiyx_90_00
https://www.youtube.com/watch?v=zlf63A-lYaI
https://www.youtube.com/watch?v=dlIlp5nwuwo
Ура, лучший скриптовый язык с лучшей инфраструктурой!Максим, принимай исправление новости. Coro нуждается в упоминании. Это важно.
А что там с коро? Поменялось разве что-то?
> А что там с коро? Поменялось разве что-то?В тот момент, когда перед выпуском Perl 5.24 остались считанные дни, в рассылке perl5-porters внезапно вспомнили, что в новом Perl по-прежнему остаётся сломанным модуль Coro Марка Леманна. Одна из проблем была связана с тем, что в Perl 5.22 структура MGVTBL (магическая виртуальная таблица), формирующаяся во время компиляции perl, стала константной. Coro делал переопределение в таблице, поэтому и не мог работать с новым Perl 5.22. Было предложено откатить это изменение до выхода Perl 5.24.
Вносить подобные изменения в последние дни перед выпуском слишком рискованно, поэтому произошёл спонтанный мозговой штурм проблемы, в результате которого удалось выяснить очень много интересных деталей. Оказалось, что переопределение MGVTBL требовалось Coro только для того, чтобы переопределить работу с хендлерами сигналов __DIE__ и __WARN__ для магического хеша %SIG, что в свою очередь было сделано из-за бага Perl, когда присутствует рассинхронизация в PL_warnhook и $SIG{__WARN__}. Теоретически оба должны ссылаться на хендлер обработки предупреждений, но некоторые кривые XS-программы, в том числе входящие в базовый Perl (например, find в PerlIO::Layer), могут изменить только PL_warnhook, забыв про $SIG{__WARN__}. То есть это был банальный костыль в Coro для обхода реальной проблемы в Perl. Эта проблема была зафиксирована в баге #125349,
Более того, оказалось, что Coro можно было приспособить для работы с константной MGVTBL, Dave Mitchell и Father Chrysostomos продемонстрировали патч, который позволяет Coro работать без проблем на Perl 5.22.
Очевидно, что если бы этот мозговой штурм прошёл год назад, проблема была бы решена раньше и не возникло бы таких явлений как stableperl. Вероятно штурм бы и не потребовался, если бы Марк сообщил о проблеме в Perl, когда столкнулся с ней впервые.
P.S. Спасибо perlnews.ru за инсайдерские скандалы, интриги, расследования)
Это я читал уже пару дней назад, но на сколько я понял в 5.24 всё осталось по старому. Да и баг 125349 всё ещё открыт.
Здесь в irc народ пишет, что RURBAN запилил патч для coro и выпустил свою версию (https://metacpan.org/release/RURBAN/Coro-6.4801), которая, вроде, полностью рабочая.
Прочитал это http://blogs.perl.org/users/aristotle/2016/05/coro-vs-5022.htmlЧщорд, ты прав. Посыпаю голову пеплом.
> Прочитал это http://blogs.perl.org/users/aristotle/2016/05/coro-vs-5022.htmlО! Спасибо, что напомнили про этот линк, а то я отложил это в закладки и уже забыл про него)
Открыл для себя фичу metacpan:
> Открыл для себя фичу metacpan:
> https://metacpan.org/diff/file?target=RURBAN%2FCoro-6.4...Какой уродливый :D git log --decorate -p -1 -stat
Прямо вебдваноль какой-то
Там, поди, ещё и SVN унутре!?
Кстати, у какого языка еще есть такая документация?
$ perl --help
...
Run 'perldoc perl' for more help with Perl.
$ perldoc perl
и понеслась)
блестяще документирован. Работает быстро. Скриптуемость "на коленке" - отличная.Недавно получил сертификат "Base Python" однако этим языком пользоваться не тороплюсь
> блестяще документирован. Работает быстро. Скриптуемость "на коленке" - отличная.
> Недавно получил сертификат "Base Python" однако этим языком пользоваться не тороплюсьПонты не колоти. Напиши на чем угодно расшифровщик урлов ютуба, например.
> Тем более, что на базовом уровне perl осваивали все быдлокодеры допыховой эпохи, да и среди сисадминов это довольно распространенный навык.дело не в базовом уровне, а в удобстве работы с языком. Не знаю, может я странный, но не могу я принять синтаксис perl, какой то он "не правильный" :)
В python по начаду было не привычно из-за пробелов/табуляции, но к этому быстро привыкаешь. Ну и плюс, что python идет по дефолту в том же centos, а вот perl надо ставить дополнительно. Мелочь, а приятно
P.S.
Просто оставлю это здесь
Мне вот питон "не правильный". Точнее, слишком правильный - примерно как если бы, напоминая кому-то про незакрытую дверь, я вместо того, чтобы сказать "эй, дверь!" начал бы "Уважаемый господин, обратите внимание, что дверь, которую принято закрывать, осталась закрытой. Пожалуйста, закройте её плотно".А насчёт дефолтов - в моих дебиане с гентой перл из коробки. Питон, кажется, тоже, не интересовался.
А вообще - питонщикам пора на Go гнать, скорее всего именно он питон сменит.
>примерно как если бы, напоминая кому-то про незакрытую дверь, я вместо того, чтобы сказать "эй, дверь!" начал бы "Уважаемый господин, обратите внимание, что дверь, которую принято закрывать, осталась закрытой. Пожалуйста, закройте её плотно".Что мне нравится в perl, так это то, что можно в зависимости от "общества", выражаться то "эй, дверь!" - в делах сисадминских, или "уважаемый господин, ..." если в делах библиотечных. Все таки, это язык общего назначения. По крайней мере у меня.
