| |
| 2.2, Исай (?), 01:03, 10/05/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
Кхм.. Ну наверное вы пошутили, плюсую. Схоронил себе в блокнотик "чем ява не угодила?".
По сути - сабж был есть и будет лучшим языком.
| | |
| |
| |
| 4.4, Исай (?), 02:06, 10/05/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Обоснуй.
Жрет память и тормозит. Поэтому программы на жабе встречаются на 90% только в интерпрайзе, который затерпит. Программ на жабе, которыми все пользуются каждый день массово - нет. Это сделала сама природа - вытеснила это барахло туда, где его будут терпеть.
| | |
| 4.5, angra (ok), 02:55, 10/05/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Увы, это примерно то же самое, что обосновать "секс с любимым человеком дает высшее наслаждение". Пока не попробуешь никакие аргументы не помогут. Когда распробуешь perl, все остальные языки кажутся убогими.
| | |
|
|
|
| |
| |
| 3.10, ragus (ok), 14:09, 10/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
 т.е.
perl -e '$a="test"; print length($a); print "\n";'
4
perl -e '$a="тест"; print length($a); print "\n";'
8
- это нормально?
| | |
| |
| 4.15, arisu (ok), 16:43, 10/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > — это нормально?
нет, конечно. но почти все считают, что нормально. и что UTF-8 — не костыль, а великое изобретение.
| | |
| 4.17, angra (ok), 00:55, 11/05/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
читайте доки, они рулез.
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
| | |
| |
| 5.18, arisu (ok), 02:09, 11/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
интересно, в какие ещё общепринятые стандарты тупоперловку надо явно тыкать носом, потому что сама она родом из прошлого столетия и не понимает?
| | |
| |
| 6.20, angra (ok), 17:01, 11/05/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Причем здесь "не понимает"? С юникодом есть два варианта: либо мы все считаем юникодом, либо все считаем однобойтными кодировками. Perl позволяет управлять этим процессом, многие "современные" языки на такое не способны и будут правильно работать лишь в одном случае из двух.
| | |
| |
| 7.21, arisu (ok), 17:09, 11/05/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
а зачем нужен «неуникодный» режим вообще? хотя, конечно, если в языке нет byte arrays, то оно понятно…
| | |
| |
| 8.23, angra (ok), 17:15, 11/05/2013 [^] [^^] [^^^] [ответить] | +/– | Ну мы ведь живем не в идеальном, а в реальном мире Чтобы далеко не ходить возьм... текст свёрнут, показать | | |
| 8.24, Аноним (-), 17:59, 11/05/2013 [^] [^^] [^^^] [ответить] | +/– | То есть Вы не очень в курсе что там есть и чего нет, ясно Хотя бы в perldoc -f ... текст свёрнут, показать | | |
|
|
|
| 5.19, ragus (ok), 05:27, 11/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
> читайте доки, они рулез.
> 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, полученный извне + результат итерации по дереву каталогов). кракозябры?
| | |
| |
| 6.22, angra (ok), 17:13, 11/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> читайте доки, они рулез.
>> 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, полученный
> извне + результат итерации по дереву каталогов). кракозябры?
У меня нет, может потому, что я таки умею читать доку.
| | |
|
|
|
| |
| 4.30, aio (?), 11:59, 13/05/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Автор комментария на хабре, к сожалению, до конца не разобрался ни со стандартом Юникод, ни с его реализацией в Perl. Не такой уж это и тривиальный стандарт, чтобы его реализация занимала *цать килобайтов абсолютно чистого и ясного C-кода. Действительно, поддержка юникода реализована частично в виде Perl-модулей. Существуют и большие таблицы символов в виде perl-файлов с хэшами, сгенерированные непосредственно из официальных данных действующего стандарта Юникод. Но где в этом усматриваются костыли и почему это не считается "настоящей" поддержкой? Только потому что реализовано не на C?
В его случае была критична скорость загрузки кода, а не скорость его работы, поэтому действительно такой способ работы юникода его не устраивал. Но с другой стороны CGI уже давно ушёл на пенсию и большинство современного кода работает в виде постоянно запущенного приложения, в котором уже всё загруженно и работает достаточно быстро.
Факт в том, что на данный момент в Perl наиболее полная поддержка стандарта Unicode (на текущий момент - 6.2) среди любых других ЯП и библиотек. В отличие от многих из них, Perl использует внутреннее представление в кодировке UTF-8, и не требует постоянной перегонки из формата внутреннего представления в требуемый на выходе. Другие кодировки Unicode не имеют особых преимуществ по сравнению с UTF-8 (даже по скорости, т.к. тот же UTF-16 кодировка с переменной длиной символа).
| | |
| |
| 5.31, arisu (ok), 13:53, 13/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
> внутреннего представления в требуемый на выходе. Другие кодировки Unicode не имеют
> особых преимуществ по сравнению с UTF-8
особенно UCS-4 не имеет. ну совсем никаких преимуществ. подумаешь, всего-то одинаковый размер представления всех символов…
| | |
| |
| 6.32, aio (?), 14:18, 13/05/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> особенно UCS-4 не имеет. ну совсем никаких преимуществ. подумаешь, всего-то одинаковый размер представления всех символов…
У кодировок есть свои преимущества и недостатки. UCS-4 имеет реальный оверхед по занимаемому объёму текста по сравнению с UTF-8, не совместим с ASCII и зависит от порядка байт на платформе. Так что получив быструю скорость вычисления положения символа N в строке мы реально теряем на объёме памяти, занимаемой строкой, получаем геморрой с дополнительной конвертацией под нужную платформу. Кроме того есть составные символы и всё равно потребуется нормализация перед обработкой, чтобы корректно вычислить число символов в строке.
| | |
| |
| 7.33, arisu (ok), 14:23, 13/05/2013 [^] [^^] [^^^] [ответить]
| +/– | |
поэтому, когда на сиране «телефонах» гигабайты памяти, мы всё равно будем *внутреннее представление* держать в UTF-8. нам ли к костылям привыкать! у нас строки до сих пор нуль-терминированые, сколько десятилетий уже. и UTF-8 тоже будет. терабайты RAM станут стандартом — всё равно «UCS занимает много памяти, а UTF-8 совместим с ASCII!»
не удивлюсь, если в процессорах появятся спецкоманды для обработки UTF-8. ведь подкостылитивать костыли — давняя традиция.
| | |
|
|
| 5.34, Аноним (-), 18:42, 13/05/2013 [^] [^^] [^^^] [ответить]
| +/– | |
>Действительно, поддержка юникода реализована частично в виде Perl-модулей. Существуют и большие таблицы символов в виде perl-файлов с хэшами, сгенерированные непосредственно из официальных данных действующего стандарта Юникод. Но где в этом усматриваются костыли и почему это не считается "настоящей" поддержкой? Только потому что реализовано не на C?
Более того, вынос функциональности из ядра в модули - это давно уже официальная стратегия в Perl5, и правильно.
| | |
|
|
|
|
| 1.13, Аноним (-), 16:10, 10/05/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
"о современном языке программирования Perl"
Му-ахахха, ох-ох-ох-ох, порадовало
| | |
| |
| 2.28, kurokaze (ok), 22:00, 12/05/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > "о современном языке программирования Perl"
> Му-ахахха, ох-ох-ох-ох, порадовало
Вы адепты VB походу все укуренные =)))
| | |
|
| 1.29, kurokaze (ok), 22:02, 12/05/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Отлично, как раз сегодня надо было переименовать кучу скриншотов в куче разных подкаталогах, чтобы они последовательно нумеровались в имени с 0, в порядке увеличения значения mtime
find -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; };}'
| | |
|
