Re: Несколько вопросов вразброс
Артём Н. -> 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 - и в этой нише он по-прежнему
непревзойден.
>> А может и просто о
>> словоохотливости автора.
АН> Читаю, как "много воды".
Не обязательно. Сжатые формальные описания обычно очень трудно понять,
а чтобы описанным пользоваться, нужно наработать интуицию. Это наш мозг
умеет делать только через высокий уровень избыточности. Если автор
хорошо владеет словом, то его более толстая книга может быть усвоена
быстрее.
Reply to: