ru.perl

 
 - RU.PERL ----------------------------------------------------------------------
 From : Konstantin Tokar                     2:5020/400     14 Aug 2002  19:43:02
 To : Artem Chuprina
 Subject : Re: Perl, ООП и критика
 -------------------------------------------------------------------------------- 
 

 ru> <ajd1g3$j65$1@host.talk.ru> <3D5A2086.80005@apmsun.mpei.ac.ru>
 ru> <ajdj0n$27v9$1@gavrilo.mtu.ru> <3D5A5F1F.1030001@apmsun.mpei.ac.ru>
 ru> <slrnalksb2.pi5.ran@banquet.lan.ice.ru>
 
 From: Konstantin Tokar <tokar@apmsun.mpei.ac.ru>
 
  > KT> Да не поэтому, а потому что в перле задать список из пары
  > миллионов KT> элементов длиной в один байт можно не на всякой машине,
  > а в С такой KT> масив займет ровно 2Мб. Плюс скорость доступа.
  >
  > Hу да. И сколько у тебя таких реальных задач? Ах, целая одна? XS тебе
  > в руки. Скорость доступа? В какой задаче? Доступа к паре миллионов
  > элементов длиной в один байт? Hе бывает таких задач иначе как в
  > учебных целях. Вообще. Бывают задачи содержательной работы с ними. И
  > тут выяснится, что то substr+unpack почти не уступает в скорости
  > сишному доступу (во всяком случае узкое место отчетливо не здесь), то
  > вообще удобнее работать регексом, и тут получается выигрыш по
  > скорости. А если таки нет, то данная конкретная подзадача решается на
  > C.
 
 Пожалуйста, скоро возникнет у Serge Pekarsky (spider) проблема хранить
 список найденных в документах слов, сразу расход памяти будет заметен 
 при нескольких десятках тысяч документов. Hе в один байт, в среднем 6-7. 
 Или реализация множеств. Так как это сейчас в перле сделано - 
 неинтересно. У меня несколько раз возникала проблема хранения большого 
 числа маленьких данных, приходилось использовать берклевские базы с 
 огромной наверно потерей производительности.
 
 ...
 
  > В том и дело, что на надуманном. Hа надуманном я и сам могу в 100
  > раз. Развлекуха в том, что на реальных задачах ускорение в 10 раз по
  > скорости разработки по сравнению с максимум полуторакратными
  > интегральными потерями по скорости работы при имеющихся
  > вычислительных возможностях куда важнее.
 
 Автор наверно реальных программ не писал и недостаток его труда в том,
 что язык для достаточно специализированного применения он тестирует как
 язык общего (С) применения. Тут возразить нечего.
 
  >
  > KT> А наследие - использование всяких чудных символов в KT> именах
  > переменных, кучи глобальных переменных с хитрыми исключениями, KT>
  > например
  >
  > KT> $_ = 10; KT> print "init:",$_,"\n"; KT> foreach(1..2){ KT> $_=1;
  > } KT> print "for:",$_,"\n"; KT> while(1){ KT> $_ = 1;  last; } KT>
  > print "while:",$_,"\n";
  >
  > KT> демонстрирует сохранение значения $_ в for и потерю в while (хоть
  > и KT> документировано, но где логика?), или разное понимание
  > while($a=<>) в KT> разных версиях перла. Или то, что писалось про
  > $a'b
  >
  > backward compatibility. Что возьмешь?
 
 Hаписали бы просто напросто компилятор старых текстов в новое
 представление. Hа стадии синтаксического разбора это почти всегда 
 удалось бы сделать. Или заставить авторов или тех, кому это надо, 
 переписать старые тексты вручную.
 --- ifmail v.2.15dev5
  * Origin: Demos online service (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор