Артём Н. -> [email protected] @ Thu, 05 Jul 2012 19:46:36 +0400:
>> >> >> >>>> >> Впрочем,
>> >> >> >>>> >> "как на шелл" - это лучше на шелле же и писать. Ну, с
>> привлечением sed
>> >> >> >>>> >> и/или awk. perl позволяет писать совершенно третьим
>> способом, и вот
>> >> >> >>>> >> именно им и надо писать надежные программы на нем.
>> >> >> >>>> АН> Эээ.... Каким?
>> >> >> >>>> use strict;
>> >> >> >>>> eval {...}; (не путать с eval "...")
>> >> >> >>> Гы-гы... Это мне о многом говорит. :-D Нет, правда. :-D
>> >> >> >> Не вижу ничего смешного, даже краткого знакомства с Perl
>> достаточно,
>> >> >> >> чтобы понять различие поведения для строки ("") и блока кода
>> ({}).
>> >> >> АН> Я понимаю различие. {} - выполним, строка - нет. Мне само
>> >> >> АН> предложение нравится. :-)
>> >> >> Нифига ты не понимаешь :-)
>> >> АН> Я-то, как-раз понимаю. :-D
>> >> Если бы понимал, ты бы не высказывал неверных утверждений.
>> АН> Посмотрел для чего используют eval {}.
>> АН> Т.е., чтобы отловить синтаксические ошибки на этапе "компиляции" (в
>> случае с
>> АН> eval "" - выражение просто строка, поэтому и ошибки не отлавливаются),
>> но не
>> АН> допустить выброса исключений (поскольку выражение в {} выполняется ей,
>> как
>> АН> автономная программа)?
>> АН> Но всё-равно, выглядит диковато...
>> Неверно утверждение, что {} выполним, а строка - нет. И то, и другое
>> выполнимо, если попросить, и не выполнимо, если не просить. Различие,
>> собственно, во времени компиляции кода, и это очень существенное
>> различие.
АН> "Выполним" в плане того, что он трактуется интерпретатором, как код.
АН> В случае с eval "" - трактуется, как строка, со всеми вытекающими.
АН> Я это хотел сказать.
Не интерпретатором, а компилятором. Интерпретатор как раз трактует их
одинаково - как код.
>> >> >> >>>> Для задач, которые можно решать на sh, этого достаточно. Ну,
>> может, еще
>> >> >> >>>> IPC::Open2 и IPC::Open3, когда надо и на вход подавать поток,
>> и на
>> >> >> >>>> выходе его забирать, да еще (в случае Open3) stderr
>> анализировать.
>> >> >> >>> Не знаю, может Perl и хорош. Но Camel Book, о котором тут
>> писали на 1000 с
>> >> >> >>> копейками страниц? И тогда уж сравните с книгой K&R...
>> >> >> >>
>> >> >> >> Так с момента выхода содержание K&R не особо менялось, а теперь
>> сравните
>> >> >> >> годы выпуска Camel Book и K&R и вспомните, сколько всяких разных
>> >> >> >> mainstream- и не очень технологий и концепций появилось.
>> >> >> АН> Ага. И, тем не менее, книга K&R по сей день актуальна. Ну,
>> >> >> АН> естественно, кое-что устаревает (в т.ч. немного поменялся
>> >> >> АН> синтаксис), но в общем....
>> >> >> Да, ты до сих пор можешь писать на C, и даже, если хорошо попросить
>> gcc,
>> >> >> на K&R C. Но с тех пор появилась возможность тратить свое рабочее
>> время
>> >> >> более эффективно.
>> >> АН> Опять вы о своём. Не понимаете основного: я не хочу сказать, что
>> "нужно
>> >> АН> вернуться к C" (от которого в некоторых задачах и не уходили).
>> >> АН> Просто размер основного руководства по языку говорит о многом.
>> >> Может быть. Но явно не о том, о чем ты подумал.
>> АН> И о чём?
>> Может говорить о том, что язык богаче (как в данном случае). Может - о
>> том, что его использовать сложнее (как в случае C++). Может о том, что
>> язык неудачно спроектирован (возьми руководство по PHP, да впрочем, я и
>> про C++ то же скажу).
АН> Вот мне почему-то сразу подумалось об этих вариантах.
АН> Кстати, сфера применения Perl сейчас весьма ограничена.
АН> И нельзя сказать, что там есть "интеллектуальный ценз", поскольку раньше...
Ну, в общем, да, в открытые перлом ниши со временем придумали и более
удобоподдерживаемые вещи, и более мейнстримные, мать их... Жизнь-то
идет вперед. А вот для написания скриптов с хорошей обработкой ошибок
кроме него да tcl приткнуть и некого. Шелл удобнее для запуска команд,
но плох в обработке ошибок, а всякие питоны и руби слишком многословны
для скриптования.
При том, что перл изначально-то был придуман для обработки текста там,
где awk уже оказывался слишком awkward - и в этой нише он по-прежнему
непревзойден.
>> А может и просто о
>> словоохотливости автора.
АН> Читаю, как "много воды".
Не обязательно. Сжатые формальные описания обычно очень трудно понять,
а чтобы описанным пользоваться, нужно наработать интуицию. Это наш мозг
умеет делать только через высокий уровень избыточности. Если автор
хорошо владеет словом, то его более толстая книга может быть усвоена
быстрее.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
