Re: Нужен ли bash
Hello!
В сообщении от Thursday 25 September 2008 22:01:21 Dmitry E. Oboukhov
написал(а):
> AP> Так намного лучше. Хотя вот в таком эскейпинге - \@ очень легко
> ошибиться. Ну AP> и $@ или $_ читабельности не добавляют, а совместо с ; в
> конце строки AP> становятся малочитаемыми.
> так это вопрос выбора имен переменных
> речь идет о том что читает код всеж таки специалист
Специалист тоже человек и на конструкциях вида $#@ ошибиться немудрено
каждому. Хм, а я правильно написал получение количества элементов? :-)
>
> вот отвлечься от Perl, взять Makefile, там полно всяких $@, $<, $> итп
> никто же не говорит что makefile масдай все пишут/используют
> альтернатив в общем-то никто и не брался придумывать ;)
Мэйкфайл это набор вызовов внешних утилит, это "сборочный шелл", а не язык
программирования.
> а стандартные имена стандартных временных переменных это как бы
> стандартное и соответственно претензии к нечитабельности идут только от
> тех кто этим не пользуется.
А зачем их так много? А зачем они такие короткие? Наверное, чтобы легко было
перловый код отличить - до и после обфускатора одинаково выглядит :-)
>
> например когда вижу java'вский
> bla_bla.krya_krya.ha_ha.kva_kva.be_be.bi_bi.ko_ko.kukareku(10);
>
> меня жуть берет, но я не специалист в javam поэтому не знаю что каждая
> фигатень значит.
> однако java повсюду очень хвалят именно как язык строгий нерасполагающий
> к ашипкам итп
На ява я писал мидлеты для телефонов и многословность кода просто убивала
порой. А наиболее защищены от ошибок функциональные языки, объектные имеют
другие задачи - позволить сляпать что-то, но зато кому угодно.
> AP> На тикле я его в catch засуну на продакшене да еще в защищенный
> интерпретатор AP> упакую. В тикле средства защиты динамического кода
> предусмотрены. ну и в перле я его в eval завернул (что тоже что твой catch)
> и в перле есть рестриктед перл-песочница
Как я понимаю, перловый eval это не перехватчик ошибок, а передача кода на
выполнение. Когда-то пробовал в перле такой метод - быстро бросил, потому что
вложенный эскейпинг жуткий просто становится. Скажем, если нужно написать
код, кодорый будет выполнен и передан в код, где он еще раз будет выполнен, в
перле это страшно смотрится.
> AP> Да все не нравится. Вот выдернуть кусок кода из контекста
> AP>>> eval "foo_$$_[0](\$\$_[1])";
> AP>>> foo_unknown($$_[1]) if $@;
> выдернуть твой кусок из контекста с {}-ми \/-ми запятыми итп
Прямой слэш я привык эскейпить, хотя это и не обязательно. {} можно заменить
на "" - это пустая строка. Ну и чуть по-другому записать
set replist {to: "" :CV: "" ( "" ) "" : "" , "" / "" -> "" $ "" [ "" ] ""}
Так вот понятнее?
> так оно хуже регекспов тобой же приведенных выглядит
> только что покороче чуток
>
> set replist [list to: {} :CV: {} ( { } ) { } : { } , { } \/ { } -> { } $ {}
> \[ {} \] {}]
Правило трансляции входных данных - выкидываем все незначащие символы
разметки. Принципиально отличается от регекспов, которые в общей куче ищут
полезные данные, что и делает их более тяжелыми для восприятия и более
подверженными ошибкам. При выполнении же полученного тиклевского кода при
несоответствии чиисла аргументов в функции я тут же ошибку увижу, что
позволяет не думать о правильности обработки, а заниматься именно логикой -
работать с последовательностью вызовов и набором аргументов каждого вызова.
> совсем нифига не понятно. кстати если распихивать по функциям парсер
> то нафиг в главном парсить аргументы? пусть каждая функция и разгребает
> что ей там на вход пришло :)
Не так. Сначала фигню на входе я превращаю в тиклевский код. А потом его
выполняю. Вот сам парсер:
proc parse {} {
set line [gets stdin]
if { $line ne {} } {
set line [string map [list \[ {} \] {}] $line]
eval $line
}
}
Все остальное - набор тиклевских функций для предметной области. Они к парсеру
отношения не имеют, равно как и парсер к ним.
>
> AP> и уже не разберешь, что это и зачем. А если нужно быстро просмотреть
> модуль в AP> сотню килобайт такого кода, написанного пару лет назад?
>
> то просматриваешь и всего делов.
> любой код должен быть откоментирован, perldoc perldoc на эту тему есть
> ;)
Хорошие комментарии не спасут плохой код, зато хороший код может не иметь
комментариев. Комментарии нужны из предметной области - рассказать, какую
задачу решаем, а отнюдь не для того, чтобы объяснять, что же делает этот код.
Best regards, Alexey.
Reply to: