05.07.2012 00:39, Artem Chuprina пишет: > Артём Н. -> [email protected] @ 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, подразумевая, что тот уже прочитан. Да, возможно. > А может и просто о > словоохотливости автора. Читаю, как "много воды". -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
