https://217.65.3.21/openforum/vsluhforumID3/60651.html В сети все больше появляется пророчеств о скором забвении языка Perl и выдвижения таких языков как Python, PHP и Ruby в качестве современных решений. Чтобы опровергнуть данное мнение, ресурс Royal Pingdom <br>опубликовал (http://royal.pingdom.com/2009/11/06/perl-far-from-dead-more-popular-than-you-think/) подборку крупнейших web-проектов, использующих для обеспечения своей работы язык Perl: Amazon.com, Livejournal.com, IMDB.com, Slashdot.org, Typepad.com, Guardian.co.uk, Salon.com, Ticketmaster.com, theregister.co.uk, BBC.co.uk. Из популярных инструментариев на Perl приводятся Bugzilla (http://www.bugzilla.org/), Catalyst (http://www.catalystframework.org/), Mason (http://www.masonhq.com/), SpamAssassin (http://spamassassin.apache.org/), Movable Type (http://www.movabletype.com/).<br><br><br>URL: http://royal.pingdom.com/2009/11/06/perl-far-from-dead-more-popular-than-you-think/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=24152<br> https://217.65.3.21/openforum/vsluhforumID3/60651.html#214 Sat, 17 Apr 2010 08:19:11 GMT Читаю и улыбаюсь!<br>Неужели, вам не пофигу на чём быдлокодят остальные???<br>Сидите, ваяйте свои нетленки... а то устроили холивар тут)<br> https://217.65.3.21/openforum/vsluhforumID3/60651.html#213 Wed, 11 Nov 2009 16:06:27 GMT &gt;&gt;за такое я программистов сначала предупреждал, а потом прощался. два элемента <br>&gt;&gt;из множества (tr, sed, grep, awk) соединенные пайпами это желтая карточка. <br>&gt;<br>&gt;Это чем же Вам пайпы не угодили?? <br><br>Ну он в чем-то прав, можно короче. Например сходу поменять первую пару awk/tr и тогда второй awk не поднадобиться, потом просто все после grep заменить на awk. <br><br>С другой стороны оптимизация того, что пишется в командной строке с той скоростью с которой набирается текст и выполняется в течении нескольких нескольких абсолютно некритичных милисекунд это фетишь и право не стоит на это обращать внимание.<br> https://217.65.3.21/openforum/vsluhforumID3/60651.html#212 Wed, 11 Nov 2009 02:57:34 GMT &gt;&gt; пока язык допускает те ужасы, как определена $b - всё будет плохо.<br>&gt;&gt; пока нет разницы между строкой и числом - тоже плохо.<br>&gt;&gt; Ибо заставляет либо втыкать кучу проверок входных параметров, либо получаем рабочий код, но не всегда работающий правильно.<br>&gt;&gt; (заменяем $a="1200" на $a="perl" и имеем 0 на выходе).<br>&gt;&gt; Это отвратительное поведение, т.к. когда стек вызовов большой, ловить ошибку становится крайне трудно.<br><br>Подобные ужасы допускаете вы, а язык только позволяет. Мне страшно представить какую кашу вы пишите на "строгом" питоне, если типизация перла вызывает у вас такую реакцию.<br><br><br><br>&gt;&gt; и какая связь embedded perl с libpcre? python можно как расширять модулями на C/C++, так и встраивать в свой код на C/C++<br>&gt;&gt; И в ваших "прогах" используется сторонние модули? или вы их статически линкуете?<br><br>Связь такова, что в базовом перле есть именно, то, что мне нужно. А в случае питона я бы скорее всего написал само приложение на нем, чем стал возиться с его встраиванием и подборкой модулей.<br> https://217.65.3.21/openforum/vsluhforumID3/60651.html#211 Tue, 10 Nov 2009 22:14:07 GMT &gt;В курсе, я даже в курсе, что в перле их нет. <br>&gt;Зачем они мне в web-программировании, системном админситрировании, датапроцессинге? <br><br>это личное дело каждого.<br><br>&gt;Кстати замыкания я тоже <br>&gt;не использую, хотя они и есть в перле ;) <br><br>я по необходимости. бывают ситуации, когда они упрощают код.<br><br>&gt;&gt;&gt; неявные преобразования типов - большое зло.<br>&gt;Вы обвиняете перл в том, что не читали документацию по преобразованиям, оригинально-с <br>&gt;:) <br><br>читал. <br><br>#!/usr/bin/perl<br><br>sub f {<br>my($x, $y) = @_; <br>print "Called with $x, $y\n";<br>return ($x / $y); <br>}<br><br>my $bx=2;<br>my $by=4;<br>my $a="1200";<br>my $b="$bx$by+$bx.$by+$by.$bx";<br>print "$b\n";<br>print f($a,$b),"\n";<br><br>пока язык допускает те ужасы, как определена $b - всё будет плохо.<br>пока нет разницы между строкой и числом - тоже плохо.<br>Ибо заставляет либо втыкать кучу проверок входных параметров, либо получаем рабочий код, но не всегда работающий правильно.<br>(заменяем $a="1200" на $a="perl" и имеем 0 на выходе).<br>Это отвратительное поведение, т.к. когда стек вызово https://217.65.3.21/openforum/vsluhforumID3/60651.html#210 Tue, 10 Nov 2009 16:52:45 GMT &gt;&gt; этот вариант уже лучше.<br>&gt;&gt; но показывает, что про ленивые вычисления вы не в курсе :)<br><br>В курсе, я даже в курсе, что в перле их нет. <br>Зачем они мне в web-программировании, системном админситрировании, датапроцессинге? Кстати замыкания я тоже не использую, хотя они и есть в перле ;) <br><br>&gt;&gt; неявные преобразования типов - большое зло.<br><br>Вы обвиняете перл в том, что не читали документацию по преобразованиям, оригинально-с :)<br><br>&gt;&gt; а модульность - это как раз очень хорошо.<br><br>как концепция - да, но в питоне она реализована убого. запихнуть базовую математику и IO в модули - извращение. <br><br>&gt;&gt; в перле регекспы прибиты гвоздями к libprcre.<br><br>И благодаря этому я регулярно встраиваю перл в свои C++ проги, не теряя ничего. Ещё один влевок в сторону питоновской модульности. Хотя вам же циферки дробить надо ...<br><br>&gt;&gt; гм... совершенно неверно. формат/тип возвращаемых данных диктуется данными.<br><br>Формат данных дикутется алгоритмом, для обработки которых он написан. Но наверное в питоне есть искусстенный интеллект, котор https://217.65.3.21/openforum/vsluhforumID3/60651.html#209 Tue, 10 Nov 2009 16:09:24 GMT &gt;На самом деле, в Perl можно легко узнать все, что угодно о <br>&gt;разобранной программе в памяти. Мне просто интересно, докапается до этого ДобрыйДохтур <br>&gt;самостоятельно в доках? Авось так всю документацию изучит и станет лучше <br>&gt;понимать с чем спорит. <br><br>Уважаемый Stanislaus!<br>Чтобы понять, что в perl плохо, достаточно посмотреть что будет изменено/добавлено в perl6.<br><br>http://www.perlfoundation.org/perl6/index.cgi?the_long_perl_6_super_feature_list<br><br>Да, интроспекция в perl есть, но в зачаточном состоянии.<br>Узнать, что нам передали в кач-ве аргумента в perl можно, но крайне геморройно.<br>Отсутствие возможности указать типы аргументов(позвать функцию, вычисляющую факториал с аргументом "vasya") и отсутсвие единообразного способа итерации по последовательностям сильно усложняют написание кода и отладку.<br><br>класс + ручное дергание getNext() как тут показывали - весьма забавный костыль.<br>Отсутствие функций с переменным числом аргументов, именнованных аргументов, аргументов по умолчанию, нормального механизма иск https://217.65.3.21/openforum/vsluhforumID3/60651.html#208 Tue, 10 Nov 2009 15:05:14 GMT &gt;Это по-длиннее, <br><br>этот вариант уже лучше.<br>но показывает, что про ленивые вычисления вы не в курсе :)<br><br>&gt;но с лихвой компенсируется временем, которое я сэкономлю за счет <br>&gt;человеческой интерполяции, которой, увы, в питоне нет, и которая в отличие <br>&gt;от генераций последовательностей мне нужна постоянно. и модули не надо подключать <br>&gt;на каждый чих. <br><br>неявные преобразования типов - большое зло. а модульность - это как раз очень хорошо.<br>в перле регекспы прибиты гвоздями к libprcre.<br><br>Смотрим сюда: http://softwareramblings.com/2008/08/c-regular-expression-performance.html<br><br>Мне достаточно написать обертку над boost:regex или boost::expressive,<br>сказать import mynice_regexlib as re<br>и понеслось. больше нигде править не нужно.<br><br>&gt;Мне кажется слишком рискованным такой метод исследования неизвестного класса, я бы предпочел <br>&gt;использовать: <br>&gt;cat module.pm &#124; egrep "^[ ]*sub[ ]*" <br>&gt;чтобы выяснить его методы. <br><br>omg... <br><br><br>&gt;&gt;&gt;да-да-да! а если у нас вперемешку строки/числа/списки/хеши...<br>&gt;значит нужно https://217.65.3.21/openforum/vsluhforumID3/60651.html#207 Tue, 10 Nov 2009 14:33:24 GMT &gt;Анонимные аналитики с ЛОРа сомневаются, что многопоточное чтение файлов, лежащих на одном <br>&gt;физическом носителе с большим временем доступа (HDD)<br><br>идите в пень, друзья ЛОРовские. Там FC до EMC Symmetrix.<br><br>$ time dd if=/dev/zero of=testfile bs=4M count=512<br>512+0 records in<br>512+0 records out<br><br>real 0m7.528s<br>user 0m0.001s<br>sys 0m4.657s<br> <br><br>, которые еще не закэшированы <br>&gt;операционной системой в оперативную память, будет работать быстрее, чем последовательное чтение <br>&gt;этих же файлов из одного потока. Объясните анонимным аналитикам с ЛОРА, <br>&gt;зачем решать IO-bound задачу методами, которые подходят для решения CPU-bound задач? <br><br>потому что задача именно cpu-bound.<br>Даже на одном SATA-диске я ускорился почти в 2 раза(ибо dualcore).<br><br>Лучше бы анонимные аналитики с лора продемонстрировали перловый код с поиском по набору регекспов и утилизирующий несколько cpu.<br><br><br><br> https://217.65.3.21/openforum/vsluhforumID3/60651.html#206 Tue, 10 Nov 2009 12:31:08 GMT &gt;[оверквотинг удален]<br>&gt; File "taskcoachlib\thirdparty\lockfile\lockfile.pyo", line 309, in __init__ <br>&gt; File "ntpath.pyo", line 102, in join <br>&gt;UnicodeDecodeError: 'ascii' codec can't decode byte 0xf5 in position 1: ordinal not <br>&gt;in range(128) <br>&gt;<br>&gt;&gt;10 минут на изучение сборки в py2exe хватит? Вперед!<br>&gt;<br>&gt;Я уже год не программирую на Python, ибо нужды такой не возникало. <br>&gt;<br>&gt;Буду очень благодарен, если поможете автору. Очень полезная программулька. <br><br>У меня виндусу нет. А ошибка простая 'UnicodeDecodeError: 'asci codec can't decode byte 0xf5' и лечится просто: добавьте в начало файла ntpath.py строчку #-*-сoding:utf8-*-<br>