Re: Несколько вопросов вразброс
05.07.2012 00:39, Artem Chuprina пишет:
> Артём Н. -> debian-russian@lists.debian.org @ Wed, 04 Jul 2012 22:24:18 +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 сейчас весьма ограничена.
И нельзя сказать, что там есть "интеллектуальный ценз", поскольку раньше...
> Может просто об объеме материала - тот же Стивенс
> тоже про программирование на C, и куда как толще K&R, причем он не
> повторяет K&R, подразумевая, что тот уже прочитан.
Да, возможно.
> А может и просто о
> словоохотливости автора.
Читаю, как "много воды".
Reply to: