Представлен третий выпуск Pragmatic Perl (http://pragmaticperl.com/), русскоязычного журнала о современном языке программирования Perl.
В номере:- Три правила тестирования кода, написанного с использованием ORM-фреймворка;- Pinto — собственный CPAN из коробки;- Введение в Perl XS;- Введение в разработку web-приложений на PSGI/Plack. Часть 2;- Обзор CPAN за апрель 2013 г.;- Интервью с Sawyer X.
URL: http://pragmaticperl.com/
Новость: http://www.opennet.me/opennews/art.shtml?num=36891
Чем ява не угодила??
Кхм.. Ну наверное вы пошутили, плюсую. Схоронил себе в блокнотик "чем ява не угодила?".
По сути - сабж был есть и будет лучшим языком.
Обоснуй.
> Обоснуй.Жрет память и тормозит. Поэтому программы на жабе встречаются на 90% только в интерпрайзе, который затерпит. Программ на жабе, которыми все пользуются каждый день массово - нет. Это сделала сама природа - вытеснила это барахло туда, где его будут терпеть.
RSSOwl, увы, на Java :( Пользуюсь каждый день.
Ну, 1 программу нашли.
Увы, это примерно то же самое, что обосновать "секс с любимым человеком дает высшее наслаждение". Пока не попробуешь никакие аргументы не помогут. Когда распробуешь perl, все остальные языки кажутся убогими.
> По сути — сабж был есть и будет лучшим языком.для чего?
Как пишушщий на жабке и на перле смеюсь с твоей наивности
а как в perl с юникодом?
Очень очень очень хорошо!!!
т.е.perl -e '$a="test"; print length($a); print "\n";'
4
perl -e '$a="тест"; print length($a); print "\n";'
8- это нормально?
Если перед этим прочитать документацию, то да, все верно.
> — это нормально?нет, конечно. но почти все считают, что нормально. и что UTF-8 — не костыль, а великое изобретение.
читайте доки, они рулез.
perl -e 'use utf8;$a="тест"; print length($a)."\n";'
4
Также для понимания рекомендую хоть раз посмотреть исходник через hexdump или сменить кодировку в терминале. Perl не может никак догадаться, что в строковом литерале вы имели ввиду utf8, а не просто странную последовательность ascii символов. use utf8 как раз сообщает ему, что все литералы должны интерпретироваться как utf8. Замечу, что это никак не влияет на данные, полученные из внешних источников, только на интерпретацию текста программы.
Вот еще примеры для понимания
$ perl -e 'use utf8;$ы="тест"; print length($ы)."\n";'
4$ perl -e '$ы="тест"; print length($ы)."\n";'
Unrecognized character \x8B; marked by <-- HERE after $�<-- HERE near column 3 at -e line 1.
$ perl -e 'use utf8;$ы="тест"; print length($ы)."\n";no utf8;$a="тест";print length($a)."\n"'
4
8
интересно, в какие ещё общепринятые стандарты тупоперловку надо явно тыкать носом, потому что сама она родом из прошлого столетия и не понимает?
Причем здесь "не понимает"? С юникодом есть два варианта: либо мы все считаем юникодом, либо все считаем однобойтными кодировками. Perl позволяет управлять этим процессом, многие "современные" языки на такое не способны и будут правильно работать лишь в одном случае из двух.
а зачем нужен «неуникодный» режим вообще? хотя, конечно, если в языке нет byte arrays, то оно понятно…
Ну мы ведь живем не в идеальном, а в реальном мире. Чтобы далеко не ходить возьмем opennet:
text/html; charset=koi8-r
у меня тоже далеко не UTF-8. но это к делу не относится в данном случае.
То есть Вы не очень в курсе что там есть и чего нет, ясно.
Хотя бы в perldoc -f vec на досуге загляните.
я очень в курсе, что большинство «фич» там — legacy crap.
> читайте доки, они рулез.
> perl -e 'use utf8;$a="тест"; print length($a)."\n";'
> 4ага. и ломаем Digest::MD5 и ещё целую пачку модулей, т.к. теперь у всех строковых переменных тип utf8.
> Также для понимания рекомендую хоть раз посмотреть исходник через hexdump или сменить
> кодировку в терминале. Perl не может никак догадаться, что в строковом
> литерале вы имели ввиду utf8, а не просто странную последовательность ascii
> символов.угу. а теперь на сцену выходит windows, где иногда CP866, а иногда - CP1251.
теперь вопрос: пути к файлам(как hardcoded в исходнике, так и полученные извне) - они в какой кодировке будут на windows?>use utf8 как раз сообщает ему, что все литералы должны
> интерпретироваться как utf8. Замечу, что это никак не влияет на данные,
> полученные из внешних источников, только на интерпретацию текста программы.а теперь конкатенируем строчки в utf8 и полученные извне(например, некий basepath, полученный извне + результат итерации по дереву каталогов). кракозябры?
>> читайте доки, они рулез.
>> perl -e 'use utf8;$a="тест"; print length($a)."\n";'
>> 4
> ага. и ломаем Digest::MD5 и ещё целую пачку модулей, т.к. теперь у
> всех строковых переменных тип utf8.Мне вам еще и доку к Digest::MD5 зачитать? Там этот вопрос рассматривается, объясняются причины и дается простое решение.
> угу. а теперь на сцену выходит windows, где иногда CP866, а иногда
> - CP1251.
> теперь вопрос: пути к файлам(как hardcoded в исходнике, так и полученные извне)
> - они в какой кодировке будут на windows?windows известна своими проблемами, но как раз с путями в perl ни разу не наблюдал, как на activeperl так и на strawberry. Ну а вообще по вопросам кроссплатформенности man perlport
Вот работа с сокетами или форками на винде это натуральный ад. Ну и с запуском ее собственных утилит, которые данные могут принять в cp1251, а результат выдать в ibm866 и разумеется нигде это не описано.
> а теперь конкатенируем строчки в utf8 и полученные извне(например, некий basepath, полученный
> извне + результат итерации по дереву каталогов). кракозябры?У меня нет, может потому, что я таки умею читать доку.
ну я как бы об этом: http://habrahabr.ru/post/53578/#comment_1444788
Автор комментария на хабре, к сожалению, до конца не разобрался ни со стандартом Юникод, ни с его реализацией в Perl. Не такой уж это и тривиальный стандарт, чтобы его реализация занимала *цать килобайтов абсолютно чистого и ясного C-кода. Действительно, поддержка юникода реализована частично в виде Perl-модулей. Существуют и большие таблицы символов в виде perl-файлов с хэшами, сгенерированные непосредственно из официальных данных действующего стандарта Юникод. Но где в этом усматриваются костыли и почему это не считается "настоящей" поддержкой? Только потому что реализовано не на C?В его случае была критична скорость загрузки кода, а не скорость его работы, поэтому действительно такой способ работы юникода его не устраивал. Но с другой стороны CGI уже давно ушёл на пенсию и большинство современного кода работает в виде постоянно запущенного приложения, в котором уже всё загруженно и работает достаточно быстро.
Факт в том, что на данный момент в Perl наиболее полная поддержка стандарта Unicode (на текущий момент - 6.2) среди любых других ЯП и библиотек. В отличие от многих из них, Perl использует внутреннее представление в кодировке UTF-8, и не требует постоянной перегонки из формата внутреннего представления в требуемый на выходе. Другие кодировки Unicode не имеют особых преимуществ по сравнению с UTF-8 (даже по скорости, т.к. тот же UTF-16 кодировка с переменной длиной символа).
> внутреннего представления в требуемый на выходе. Другие кодировки Unicode не имеют
> особых преимуществ по сравнению с UTF-8особенно UCS-4 не имеет. ну совсем никаких преимуществ. подумаешь, всего-то одинаковый размер представления всех символов…
> особенно UCS-4 не имеет. ну совсем никаких преимуществ. подумаешь, всего-то одинаковый размер представления всех символов…У кодировок есть свои преимущества и недостатки. UCS-4 имеет реальный оверхед по занимаемому объёму текста по сравнению с UTF-8, не совместим с ASCII и зависит от порядка байт на платформе. Так что получив быструю скорость вычисления положения символа N в строке мы реально теряем на объёме памяти, занимаемой строкой, получаем геморрой с дополнительной конвертацией под нужную платформу. Кроме того есть составные символы и всё равно потребуется нормализация перед обработкой, чтобы корректно вычислить число символов в строке.
поэтому, когда на сиране «телефонах» гигабайты памяти, мы всё равно будем *внутреннее представление* держать в UTF-8. нам ли к костылям привыкать! у нас строки до сих пор нуль-терминированые, сколько десятилетий уже. и UTF-8 тоже будет. терабайты RAM станут стандартом — всё равно «UCS занимает много памяти, а UTF-8 совместим с ASCII!»не удивлюсь, если в процессорах появятся спецкоманды для обработки UTF-8. ведь подкостылитивать костыли — давняя традиция.
>Действительно, поддержка юникода реализована частично в виде Perl-модулей. Существуют и большие таблицы символов в виде perl-файлов с хэшами, сгенерированные непосредственно из официальных данных действующего стандарта Юникод. Но где в этом усматриваются костыли и почему это не считается "настоящей" поддержкой? Только потому что реализовано не на C?Более того, вынос функциональности из ядра в модули - это давно уже официальная стратегия в Perl5, и правильно.
Отлично!
"о современном языке программирования Perl"
Му-ахахха, ох-ох-ох-ох, порадовало
> "о современном языке программирования Perl"
> Му-ахахха, ох-ох-ох-ох, порадовалоВы адепты VB походу все укуренные =)))
Отлично, как раз сегодня надо было переименовать кучу скриншотов в куче разных подкаталогах, чтобы они последовательно нумеровались в имени с 0, в порядке увеличения значения mtimefind -type f | perl -ne '{chomp; push @all, $_;} END{ @als = sort{ @sa=stat($a); @sb=stat($b); $sa[9]<=>$sb[9] } @all; for $i(0..@als-1){ $nn=sprintf "sshot%04d.webp", $i; rename $als[$i], $nn; };}'