Здравствуйте, YК, Вы писали:
a>>>> Теперь сравним Java с PHP и придём к выводу, что Java нафиг a>>>> никому не сдалась. Ущербность подхода не чувствуешь? YК>>> А ты не чуствуешь различия между причинами и следствиями? Объем YК>>> разработки — это уже следствие. a>> А что причина? YК>Я уже написал, и не один раз. Устал повторять одно и тоже, честно.
Значит непонятно написал.
YК>>> Сравнивать PHP и Java это вообще нонсенс, учитывая количество YК>>> говностраничек и говносайтов, написанных на PHP. a>> На Perl тоже много говностраничек. С Java не будем сравнивать? YК>Будем, ты ж его для больших проектов прочишь.
Значит и с PHP можно сравнивать, на нём тоже большие проекты пишут.
A>А потом оказалось, что веб — это текст, а язык для обработки текста — это Perl, и Perl знают большинство unixоидов. Не CGI сделал Perl.
Что-то мне это утверждение кажется до крайности спорным. То что Web основан на текстовых протоколах вовсе не говорит о том что веб-это текст. Или до сих пор кто-то протокол HTTP ручками парсит? Или XML? Хотя, я видел ручной парсинг XML на перле — в системе автобилда ACE/TAO — но назвать такое решение удачным у меня язык не повернётся.
Здравствуйте, Left2, Вы писали:
A>>А потом оказалось, что веб — это текст, а язык для обработки текста — это Perl, и Perl знают большинство unixоидов. Не CGI сделал Perl. L>То что Web основан на текстовых протоколах вовсе не говорит о том что веб-это текст.
Не только протоколы, но и контент, почти вся видимая часть веба является текстовой.
L>Или до сих пор кто-то протокол HTTP ручками парсит? Или XML?
Для этого давно написаны библиотеки на том же Perl, но если очень хочется, то можно и "ручками". В конце концов есть веб-сервера на Perl, а у них обязанность такая — парсить HTTP.
Из описания Perl 1.000:
DESCRIPTION
Perl is a interpreted language optimized for scanning arbi-
trary text files, extracting information from those text
files, and printing reports based on that information.
Что такое HTTP-запрос/ответ как не текстовый файл? То же и с остальным.
L>Хотя, я видел ручной парсинг XML на перле — в системе автобилда ACE/TAO — но назвать такое решение удачным у меня язык не повернётся.
Всё зависит от задачи. Если формат XML заранее известен и жёстко задан, то часто лучшим решением будет как раз такой ручной разбор вместо использования полноценного всеядного XML-парсера.
A>Для этого давно написаны библиотеки на том же Perl, но если очень хочется, то можно и "ручками". В конце концов есть веб-сервера на Perl, а у них обязанность такая — парсить HTTP.
в том-то и дело что библиотеки написаны не только для перл, а для практически всех известных языков. и якобы "заточеность" перла под работу с текстом (кстати — в чём она выражена?) тут становится преимуществом сомнительным.
A>Всё зависит от задачи. Если формат XML заранее известен и жёстко задан, то часто лучшим решением будет как раз такой ручной разбор вместо использования полноценного всеядного XML-парсера.
Единственное место где я бы посчитал такой подход оправданным — это какой-то жуткопроизводительный код, где тем не менее от XML никак не избавиться. Но как только речь заходит о производительности, не только Perl но и разбор на основе регулярных выражений в любом другом языке нервно курят в сторонке. Во всех остальных случаях — я не найду слов сочувствия для того программиста который это написАл
Здравствуйте, Left2, Вы писали:
A>>Всё зависит от задачи. Если формат XML заранее известен и жёстко задан, то часто лучшим решением будет как раз такой ручной разбор вместо использования полноценного всеядного XML-парсера. L>Единственное место где я бы посчитал такой подход оправданным — это какой-то жуткопроизводительный код, где тем не менее от XML никак не избавиться. Но как только речь заходит о производительности, не только Perl но и разбор на основе регулярных выражений в любом другом языке нервно курят в сторонке. Во всех остальных случаях — я не найду слов сочувствия для того программиста который это написАл
my $xml = get('/path/to/xml');
$xml =~ /<first-name>(.*?)<\/first-name>/;
my $name = $1;
И это будет работать быстрее, чем разбор XML в парсере, и ресурсов потребует меньше. Для наглядности приведу результаты тестов:
use Benchmark;
use XML::Simple qw(XMLin);
use XML::Parser;
my $xml = '<person><first-name>John</first-name><last-name>Smith</last-name></person>';
my $parser = XML::Parser->new('Style' => 'Objects');
Benchmark::cmpthese(
100000,
{
'XML::Parser' => sub
{
my $data = $parser->parse($xml);
my $name = $data->[0]->{'Kids'}->[0]->{'Kids'}->[0]->{'Text'};
},
'XML::Simple' => sub
{
my $data = XMLin($xml);
my $name = $data->{'first-name'};
},
'RegExp' => sub
{
$xml =~ /<first-name>(.*?)<\/first-name>/;
my $name = $1;
},
}
);
Даст разницу минимум на 2 порядка при том, что XML::Parser написан на Си:
A>Поэтому, если хочется красиво и всё, то выбираешь парсер, если же хочется быстро, то делаешь всё "ручками".
Ага, только мы забыли про:
1. Encodings
2. CDATA
3. то что first-name может иметь атрибуты
4. про то что &, " и т.п. внутри first-name нам ещё надо преобразовать в соотв. символы
5. знатоки XML поправят — может, я ещё что-то забыл?
в итоге — решение настолько ограниченное и изобилующее подводными камнями что я не рискнул бы с ним связываться практически нигде. Поскольку это уже не XML — это свой собственный проприетарный формат ПОХОЖИЙ на XML.
Здравствуйте, Left2, Вы писали:
A>>Поэтому, если хочется красиво и всё, то выбираешь парсер, если же хочется быстро, то делаешь всё "ручками". L>Ага, только мы забыли про:
Мы не забыли, у нас частный случай, т. е. по определению ограниченный, и эти ограничения нам известны.
A>>>Поэтому, если хочется красиво и всё, то выбираешь парсер, если же хочется быстро, то делаешь всё "ручками". L>>Ага, только мы забыли про:
A>Мы не забыли, у нас частный случай, т. е. по определению ограниченный, и эти ограничения нам известны.
А где мы пропишем эти ограничения? В XML? В код программы? И туда и туда? А то эти "нам известные" ограничения уж слишком смахивают на спрятанные в траве грабельки.
Здравствуйте, Left2, Вы писали:
L>5. знатоки XML поправят — может, я ещё что-то забыл?
Я ни разу не знаток, но забыли еще и про элементарную обработку ошибок.
Т.к. быстрое и неправильное решение на регеэкспах съест любую ерунду, в которой встречается искомая строка.
Здравствуйте, Left2, Вы писали:
A>>Для этого давно написаны библиотеки на том же Perl, но если очень хочется, то можно и "ручками". В конце концов есть веб-сервера на Perl, а у них обязанность такая — парсить HTTP. L>в том-то и дело что библиотеки написаны не только для перл, а для практически всех известных языков. и якобы "заточеность" перла под работу с текстом тут становится преимуществом сомнительным.
Про частные решения частных задач я уже написал.
L>"заточеность" перла под работу с текстом (кстати — в чём она выражена?)
Встроенные в язык регулярные выражения, синтаксис которых считается наиболее удачным.
Здравствуйте, palm mute, Вы писали:
L>>5. знатоки XML поправят — может, я ещё что-то забыл? PM>Я ни разу не знаток, но забыли еще и про элементарную обработку ошибок. PM>Т.к. быстрое и неправильное решение на регеэкспах съест любую ерунду, в которой встречается искомая строка.
Здравствуйте, Left2, Вы писали:
A>>>>Поэтому, если хочется красиво и всё, то выбираешь парсер, если же хочется быстро, то делаешь всё "ручками". L>>>Ага, только мы забыли про: A>>Мы не забыли, у нас частный случай, т. е. по определению ограниченный, и эти ограничения нам известны. L>А где мы пропишем эти ограничения?
В техническом задании. Если в ТЗ написано, что входные данные такие-то, а приходит нечто иное, то программа не обязана это корректно обрабатывать.
L>А то эти "нам известные" ограничения уж слишком смахивают на спрятанные в траве грабельки.
L>>А то эти "нам известные" ограничения уж слишком смахивают на спрятанные в траве грабельки. A>Тебе о проектировании что-нибудь известно?
Я наверное не слишком большой гуру в проектировании, но всегда считал что:
L>>А где мы пропишем эти ограничения? A>В техническом задании. Если в ТЗ написано, что входные данные такие-то, а приходит нечто иное, то программа не обязана это корректно обрабатывать.
если программе пришли некорректные данные — то программа должна выдать ошибку о том что данные некорректны. А работать с некорректными данными "как Бог на душу положит" (а именно так будет работать кусок с regexp-ом, и тебе уже об этом сказали) — это как-то не пахнет профессионализмом.
Здравствуйте, Left2, Вы писали:
L>>>А где мы пропишем эти ограничения? A>>В техническом задании. Если в ТЗ написано, что входные данные такие-то, а приходит нечто иное, то программа не обязана это корректно обрабатывать. L>если программе пришли некорректные данные — то программа должна выдать ошибку о том что данные некорректны. А работать с некорректными данными "как Бог на душу положит" (а именно так будет работать кусок с regexp-ом, и тебе уже об этом сказали) — это как-то не пахнет профессионализмом.
Под "не обязана это корректно обрабатывать" я имел в виду, что ты не получишь корректных выходных данных. А уж должна программа просто выдать сообщение об ошибке или аварийно завершиться, обговаривается отдельно.
Тот "кусок с regexp-ом" всего лишь пример, так что не надо о профессионализме. И он не работает "как Бог на душу положит", мы либо получим в $name нужное значение, либо $name будет пуст, и в реальном проекте проверка будет произведена.
Здравствуйте, Mamut, Вы писали:
M>Интересно, что когда я переходил на Линукс, я думал, что, мол, надо будет подучиься Perl'у, скриптики писать. Как оказалось, каждое второе приложение расширяемо Питоном, а в качестве скриптового языка Питон ввобще руль. Perl в линуксе я пока так и не видел (правда, и не искал)
Первое что приходит в голову -- autotools, dh_* скрипты и кусочки dpkg в Debian.
M>Он не умер, он просто так пахнет (с) про Лисп
В оригинале: "jazz is not dead, it just smells funny", классическая цитата Френка Заппы.
А теперь коротенькая история про Perl. Однажды мы с одним Java-программистом делали регрессионные тесты некой системы. Данных было много, их надо было загрузить, подготовить и сравнить со старыми данными. Так получилось, что мы одновременно, не зная друг о друге, стали писать эту самую сравнивалку. Через 30 минут у меня были результаты, а сотоварищ только научился разбирать файлы с дампом. При том, что я очень плохой программист на Perl, а мой товарищ -- очень хороший программист на Java.
К чему это я?
К тому, что Perl вполе себе хорош для своих целей. Он быстрый, достаточно бесшабашный и еще больше tricky. Он незаменим, когда надо нарисовать скриптик по-быстрому и что-нибудь посчитать. Не уверен насчет больших программ, но для скриптов Perl -- самое оно. Единственно что мне прямо сейчас не хватает на Perl -- нормальной и поддерживаемой реализации CORBA.
И самое главное, на Perl приятно писать
P.S. А сейчас я пойду и поставлю минусы всем, кто постил картинки с гробами и говорил что Perl -- говно. Доброжелательнее и терпимее надо быть, товарищи.
BZ>я надеюсь, что его вытеснит руби — это "perl done right"
Я думаю, что только Larry Wall знает, каким должен быть Perl, и вряд ли Larry Wall хотел сделать что-то типа Ruby -- это становится ясно если прочитать пару глав из Programming Perl.
"Perl done right" -- всего лишь не очень удачный рекламный слоган.
