[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: