Re: perl syntax
- From
- Artem Chuprina (2:5020/400)
- To
- Alexei Ivanov (2:5054/37.63)
- Date
- 2005-04-01T11:56:10Z
- Area
- RU.PERL
From: Artem Chuprina <ran+news@ran.pp.ru>
Alexei Ivanov -> Artem Chuprina @ Thu, 31 Mar 2005 22:52:42 +0000 (UTC):
>> Это в первую неделю. Потом проходит. Правда, при условии, что ты
>> умеешь программировать, а не кодить на C.
AI> Для меня это синонимы. И я не понимаю разницы.
Если не понимаешь разницы - значит, не умеешь программировать. Советую
поучиться.
>> Для начала лучше то, что понятнее читать. "Преждевременная оптимизация
>> [по скорости - A.C.] - корень всех бед" (c) кто-то из великих. C это
>> тоже касается.
AI> Наверно. Но я пока никак не могу.
AI> Вот хотел написать простой поиск фалов по маске начиная
AI> с текущего директорая и глубже или просто в текущем дире.
AI> Казалось бы надо прочесть параметры командной строки.
AI> Выдать список файлов текущего и нетолько каталогов
AI> сравнить со списком масок или маской и выдать оставшиеся
AI> в список. Можно еще поиграться по поводу каталога
AI> или нет...
AI> инет же предлагает такую штуку как File::Find,
AI> которая насколько я успел понять является интерфейсом
AI> к find
Нет. Аналогом.
AI> и программирование заключается в подборе параметров к find. Причем
AI> из-за интерпретируемости второй вариант будет работать быстрееза
AI> счет того что на долю самого перла остается меньше шагов. Хотя
AI> find более сложная штука чем которую хочется сделать. Получается
AI> логическое упрощение задачи приводит к увеличению времени работы.
Проигрыш во времени работы за все время жизни этой программы, скорее
всего, не превзойдет выигрыша во времени ее написания. Даже если
считать, что твое время не дороже процессорного. Не говоря уже о том,
что ой, не факт, что написанная тобой программа на C будет работать
быстрее - работу с маской эффективно написать еще суметь надо. Сравним
по скорости будет вариант с execl("/usr/bin/find", ...). Если надо
только вывести результаты, то /usr/bin/find обгонит perl. Если же
что-то более интересное сделать (когда для find потребуется -exec) - тут
уже как сказать, накладные расходы на fork/exec в случае с find могут и
проигрыш дать, а xargs можно и не суметь применить.
>> Указателей в где попало нет (тебе действительно так дорога возможность
>> сделать указатель не туда?). Распаковать float из бинарного файла
>> можно, и в глаголе содержится название функции :-) Но делать так без
>> крайней необходимости (а именно - необходимости работы с чужими
>> бинарными форматами) также не следует.
AI> А как же простите делать следует?
AI> разве можно как-то инчаче - по моему нет.
Следует писать в архитектурно-независимом виде. В норме - в текстовом.
В каком-либо ином - только когда есть основания так делать. В любом
случае с сохранением независимости от архитектуры и настроек
компилятора. Благо средства есть - network byte order, DER, база данных...
>> Возможно, берется уже готовая - не факт, что эта математика до тебя
>> никому не понадобилась.
AI> Савитский Голай фильтр?
Возможно. Если знать, как оно правильно по-английски пишется, то можно
CPAN спросить.
>> Но вообще, если тебе нужен язык высокого уровня для математики, то perl
>> - не самый подходящий выбор. Стоит смотреть в сторону всяческих лиспов
AI> Да ведь хотелось бы это через XML в базу загнать...
Слово "XML" тут, скорее всего, лишнее.
AI> Как-то внутренне кривовато выглядит...
AI> Одна программа другая...
Совершенно нормально выглядит. В виндах это будет непривычно (но я не
говорил "неправильно"!), а в юниксе - совершенно естественно.
>> - Common Lisp, Scheme, Ocaml... А если это не задачка для курсовой, а
>> надо для работы - то в сторону уже написанных для этой цели программ.
AI> С...
Если программа уже написана, то совершенно пофигу, на каком она языке.
Если она делает то, что надо, но неудобно давать ей данные и получать
результаты - вот тут применяется обертка на удобном тебе скриптовом
языке (есть даже такой термин - glue language).
>> "Преждевременная оптимизация - корень всех зол".
AI> Ну почему. На С никто не оптимирует а быстрее выходит.
AI> Почему например нет компилируюшего языка высокого уровня.
"Common Lisp, Scheme, Ocaml..." Читать в школе учили? Или чукча писатель?
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Современной называется технология, которую пытаются совать во все дырки
независимо от того, заточена она под них или нет.
Д. Белявский
--- ifmail v.2.15dev5.3
* Origin: Leninsky 45 home network (2:5020/400)
SEEN-BY: 50/203 520 400/462 450/159 186 208 451/30 452/25 100 454/9 455/15
SEEN-BY: 461/33 43 74 106 132 640 464/34 465/204 467/24 469/125 999 478/44 65
SEEN-BY: 550/150 5068 4600/126 4614/9 4616/3 4623/56 4625/8 9 4626/100 4627/10
SEEN-BY: 4632/10 4635/4 99 1024 4641/444 4642/27 48 4657/50 5000/76 5001/50
SEEN-BY: 5001/5001 5002/76 5002 5003/34 5006/1 5007/1 5010/53 70 146 5011/13
SEEN-BY: 5012/8 5015/4 28 214 5019/5 5020/52 115 118 128 133 150 154 175 194
SEEN-BY: 5020/400 486 545 549 600 642 715 744 758 794 830 921 958 968 982 1057
SEEN-BY: 5020/1100 1169 1212 1234 1523 1604 1626 1642 1653 1665 1826 1829 1922
SEEN-BY: 5020/1930 2013 2020 2044 2142 2200 2238 2345 2590 2908 4400 4441
SEEN-BY: 5021/2 3 5022/128 5023/11 5024/1 73 5025/19 750 5026/14 49 5030/49 69
SEEN-BY: 5030/195 382 436 556 611 920 966 1016 1039 1063 1339 1688 1900 5031/7
SEEN-BY: 5031/47 63 70 5032/11 20 5033/21 35 5034/8 5035/3 38 63 5036/1 13
SEEN-BY: 5037/21 36 5038/4 5040/33 47 5041/4 5042/13 5045/7 42 5047/47 5049/1
SEEN-BY: 5049/6 157 5050/9 41 47 5051/15 35 5053/16 38 5054/1 8 9 35 36 37 45
SEEN-BY: 5054/50 66 67 81 85 5055/177 5056/16 5057/1 5058/77 5059/2 9 20
SEEN-BY: 5060/88 90 5061/15 5062/1 4 7 5063/41 51 5064/7 35 36 39 5066/18
SEEN-BY: 5070/26 66 948 1222 5071/22 5075/5 37 5077/70 80 5079/49 5080/80 1003
SEEN-BY: 5081/2 5082/6 5083/13 21 5090/23 105 108 113 5093/4 27 33 5096/18
SEEN-BY: 5100/113 6001/3 6023/1 6033/2727 6035/9 6070/5 6083/11 6096/10
PATH: 5020/400 4441 52 5054/1 37