ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Fedor Zuev                           2:5070/156.89  23 May 2003  16:50:02
 To : Vladimir Bormotov
 Subject : Re: Линукс
 -------------------------------------------------------------------------------- 
 

 .RFC-X-Complaints-To: usenet@bearloga.home
 .RFC-NNTP-Posting-Date: Fri, 23 May 2003 07:50:04 +0000 (UTC)
 .RFC-In-Reply-To: <m3r86upw31.fsf@vb.dn.ua>
 On Mon, 19 May 2003, Vladimir Bormotov wrote to Fedor Zuev:
 
 VB>>> А спектрумистов...  Таки я думаю что для разработчика софта важно не
 VB>>> умение копаться в битах, а умени понимать цели и выбирать оптимальные
 VB>>> пути их достижения.  Причем не через 10 лет, а сразу, как только цель
 VB>>> четко прорисовалась.
 
 FZ>>   Оно, в принципе, как бы да.
 
 FZ>> Проблема только в том, что мы не можем поставить эксперимент по
 FZ>> или-или,
 
 VB> кто не может?  Почему?  При нисходящем проектировании задача так
 VB> или иначе распадает на более простые.  Макет _целой_ ситсемы
 VB> можно начинать написать уже на финальных стадиях анализа задачи,
 VB> еще до перехода к постановке технического задания.  И сразу
 VB> можно ставить эксперементы.  Есть ведь цели?
   Hе зная, какие функции машина умеет хорошо, какие средне,
 какие хреново, а какие и вовсе не умеет - ничего умного ты не
 напишешь. Это точно. Это в любой книге по управлению разработкой
 софта написано - планирование сверху вниз в чистом виде, как
 правило, не работает.
 
   Или - требует привлечения суперспециалиста, который
 построит в уме модель _всей_ системы, включая ассемблерный код
 (важнейших участков), а потом _запишет_ на бумагу верхний слой этой
 системы - типа план.
 FZ>> потому что те, кто _умеет_ цели и пути (а не только говорит о них),
 FZ>> как правило (в xUSSR, по крайне мере) и с битами особых проблем не
 FZ>> имеет.
 
 VB> именно поэтому они и не имеют проблем с битами, что умеют.
 
   Что умеют и с битами.
 
   Поэтому их заявления о том, что "с битами уметь не надо" -
 мы отметаем, как не основанные на опыте, досужие рассуждения.
 
   Я думаю, ты не найдешь компетентного системного архитектора,
 который при этом был бы некомпетентен на уровне битов и регистров.
 Все, приходящие мне на ум - от Билла Гейтса до Линуса Торвальдса, с
 ассемблером знакомы отнюдь не понаслышке.
 FZ>>   Обратное, к сожалению, верно не всегда.
 VB> я про обратное не говорю, я говорю что совершенно не нужно
 VB> залезать в биты сразу, и выдвигать этот путь как "один из
 VB> правильных".
 
   Это называется "программирование снизу вверх". Вполне
 законная стратегия для многих случаев.
 
 VB> При необходимости опускаясь вплоть до битов никтож не против.
 
   Отчего же. Именно это ты и говорил.
 
   Достаточной телепатической подготовкой, чтобы выяснять, что
 ты при этом _думал_ - обладают далеко не все.
 VB> Hо, впротивовес этому приросту производительности программы давай
 VB> посмотрим ЗАТРАТЫ:
 
   1)
 
 VB>   1 минута написания простого цикла
 
   2)
 
 VB>   2 минуты написания "непростого цикла"
 
   3)
 
 VB>   пусть ЧАС (реально больше) написания "в битах".
 
   Из этого реестрика можно сразу видеть, что 1) ты умеешь
 программировать 2) имеешь опыт обращения со сложными алгоритмами
 и структурами данных 3) не слишком интересовался в прошлом
 ассемблером, булевой алгеброй, устройством процессора и прочими
 специфическими вещами? Так?
 
   Кто-то уже второй шаг сочтет непомерно сложным, требующим
 часов и дней на отладку. А кому-то вообще в голову не сразу придет,
 что могут быть какие-то варианты, кроме третьего. И напишет он его
 ну пусть не за одну (я думаю, что и в твоем-то случае это некоторое
 преувеличение), но за 5-10 минут.
 
   Каждый легко и эффективно пользуется теми средствами,
 которыми он умеет. И медленно и с трудом - теми, которыми не умеет.
 Hо любыми средствами нужно когда-то _начать_ пользоваться, не так
 ли?
 
 VB> Всегда ли ОПРАВДАHА потеря ЧАСА, на которую идут "спектрумисты"
 VB> (люди которые сразу начинают колупаться "в битах")?
 
   Ради обучения, ради создания привычки - да, оправдана.
 Причем тут уж не так и важно, что именно тут оптимизируется.
 
   А  иначе зачем вообще писать любительские (AFAIK, речь шла
 именно о них) проекты?
 
 VB> Да, в xUSSR, при цене часа рабочего времени = "недорого" - наверное
 VB> пофиг, и сразу копают вглубь   Hо ведь это не везде так, да?  Ведье сть
 VB> люди, котоыре считаю деньги, в смысле время работу высококвалифицированых
 VB> специалистов, который умеют копаться в битах...
 
   Специалисты, которые не будут постояно писать чуточку (а
 может и не чуточку) лучше и эффективнее, чем это вынуждено
 обстоятельствами, не скоро станут высококвалифицированными и
 высокооплачиваемыми. IMHO.
 
   А причин упростить задачу, воспользоваться быстрым решением
 вместо эффективного, в индустриальном программировании всегда
 найдется более чем достаточно. Hо не надо добавлять к ним еще и
 "принципиальные".
 
 --- ifmail v.2.15os7
  * Origin: Это так просто - быть дураком (2:5070/156.89@fidonet)
 
 

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