Артём Н. -> debian-russian@lists.debian.org @ 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 debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txxmuoxg....@wizzle.ran.pp.ru