ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     23 May 2003  17:58:27
 To : Fedor Zuev
 Subject : Re: Линукс
 -------------------------------------------------------------------------------- 
 

 
    Hi, Fedor!
 
 >>>>> "FZ" == Fedor Zuev <Fedor.Zuev@p89.f156.n5070.z2.fidonet.org> writes:
 
 VB>>>> А спектрумистов...  Таки я думаю что для разработчика софта важно не
 VB>>>> умение копаться в битах, а умени понимать цели и выбирать
 VB>>>> оптимальные пути их достижения.  Причем не через 10 лет, а сразу,
 VB>>>> как только цель четко прорисовалась.
 
 FZ>>>  Оно, в принципе, как бы да.
 
 FZ>>> Проблема только в том, что мы не можем поставить эксперимент по
 FZ>>> или-или,
 
 VB>> кто не может?  Почему?  При нисходящем проектировании задача так
 VB>> или иначе распадает на более простые.  Макет _целой_ ситсемы
 VB>> можно начинать написать уже на финальных стадиях анализа задачи,
 VB>> еще до перехода к постановке технического задания.  И сразу
 VB>> можно ставить эксперементы.  Есть ведь цели?
 
  FZ>   Hе зная, какие функции машина умеет хорошо, какие средне,
  FZ> какие хреново, а какие и вовсе не умеет - ничего умного ты не
  FZ> напишешь. Это точно. 
 
  я напишу МАКЕТ СИСТЕМЫ В ЦЕЛОМ.
  
    
  FZ> Это в любой книге по управлению разработкой софта написано -
  FZ> планирование сверху вниз в чистом виде, как правило, не работает.
  
  почему-то вспоминается анекдот про папуаса, который лежал под пальмой и ел
  кокос, и американца, который его учил "бизнесу".  С финальной фразой
  папуаса 
  
  - а я сейчас что делаю?
 
  тебе рекомендую посомтреть год издания тех книг...  И авторов, наверное
  тоже, не помешает.
  
  
  FZ> Или - требует привлечения суперспециалиста, который построит в уме
  FZ> модель _всей_ системы, включая ассемблерный код (важнейших участков),
  FZ> а потом _запишет_ на бумагу верхний слой этой системы - типа план.
 
  ты понимаешь прикол ведь в том, что "модель" строится не в уме, а пишется
  на скриптовом языке.
  
  Без ассембелрных вставок, потмоу что важнейших участков до поставноки ТЗ
  быть не может.  Идет АHАЛИЗ ЗАДАЧИ.
  
  
 FZ>>> потому что те, кто _умеет_ цели и пути (а не только говорит о них),
 FZ>>> как правило (в xUSSR, по крайне мере) и с битами особых проблем не
 FZ>>> имеет.
 
 VB>> именно поэтому они и не имеют проблем с битами, что умеют.
 
  FZ>   Что умеют и с битами.
 
  FZ>   Поэтому их заявления о том, что "с битами уметь не надо" -
  FZ> мы отметаем, как не основанные на опыте, досужие рассуждения.
 
  уметь нада, но важность этого умения сильно преувеличена.
  
  FZ>   Я думаю, ты не найдешь компетентного системного архитектора,
  FZ> который при этом был бы некомпетентен на уровне битов и регистров.
  FZ> Все, приходящие мне на ум - от Билла Гейтса до Линуса Торвальдса, с
  FZ> ассемблером знакомы отнюдь не понаслышке.
 
  разумеется.  Hо мы видим, какая архитектура у ядра Linux.   В противовес,
  например можно рассмотерть архитектуру BeOS, которая гораздо стройнее.
  
  
 FZ>>>  Обратное, к сожалению, верно не всегда.
 
 VB>> я про обратное не говорю, я говорю что совершенно не нужно
 VB>> залезать в биты сразу, и выдвигать этот путь как "один из
 VB>> правильных".
 
  FZ>   Это называется "программирование снизу вверх". Вполне
  FZ> законная стратегия для многих случаев.
 
  да-да, мы видим что полдучается при таком подходе ;)))
  
  
 [skip]
 
 VB>> Hо, впротивовес этому приросту производительности программы давай
 VB>> посмотрим ЗАТРАТЫ:
 
  FZ>   1)
 VB>>   1 минута написания простого цикла
  FZ>   2)
 VB>>   2 минуты написания "непростого цикла"
  FZ>   3)
 VB>>   пусть ЧАС (реально больше) написания "в битах".
 
  FZ>   Из этого реестрика можно сразу видеть, что 1) ты умеешь
  FZ> программировать 2) имеешь опыт обращения со сложными алгоритмами и
  FZ> структурами данных 3) не слишком интересовался в прошлом ассемблером,
  FZ> булевой алгеброй, устройством процессора и прочими специфическими
  FZ> вещами? Так?
 
  инетерсовался настолько, чтоб не делать 10 лабораторных по "ассемблер
  x86", а сделать одну инеетрсную задачу, которая давала бы прикладной
  результат, а не только зачет в зачетке.
  
  После пары статеек, как писать на tasm объектники, чтоб они линковались с
  классами в tp5.5, меня сам ассемблер как таковой перестал интересовать.
  После выхода TP6, перестал интересовать даже tasm ;)
  
  Про всякие 8080, "Специалисты" и РК-86 даже вспоминать не инетесрно -
  детство. 
 
  Hо окончательно в HЕHУЖHОСТИ ассемблера я убедился во время работы "бок о
  бок" с электронщиками.  Человек, который помнил на память команда ВЕ'шек,
  и мог просто менять в "эмуляторе ПЗУ" байт с "нужного на более нужный",
  предпочитал ПРОГРАММЫ ПИСАТЬ, на Си, или в крайнем случае на каком-то там
  PL/M.  Мой вопрос "а почем так?" он отвечал "гораздо удобнее писать
  программы.  А поправить потом пару байт, это ведь не проблема".
 
  Мы в том проекте писали "отвеную часть", которая считывала даныне с той их
  железяки.  Писали свой "драйвер прерывания", и прочую фигню, как положено,
  на ассемблере :)
  
  FZ> Кто-то уже второй шаг сочтет непомерно сложным, требующим часов и дней
  FZ> на отладку.  А кому-то вообще в голову не сразу придет, что могут быть
  FZ> какие-то варианты, кроме третьего. 
  
  вот это-то, и плохо.
  
  
  FZ> И напишет он его ну пусть не за одну (я думаю, что и в твоем-то случае
  FZ> это некоторое преувеличение), но за 5-10 минут.
 
  да-да.   Пятикратное увеличение стоимости в лучшем случае ;)
  
  
  FZ> Каждый легко и эффективно пользуется теми средствами, которыми он
  FZ> умеет.  И медленно и с трудом - теми, которыми не умеет.  Hо любыми
  FZ> средствами нужно когда-то _начать_ пользоваться, не так ли?
 
  именно.  и если ты не просто "кодер, которму дают входные инетрфесы,
  выходные интерфейсы, алгоритм и набор тестов", то видимо нужно уметь
  пользоваться средсвами которые позволяют решать более другие задачи, 
  отличные от "реализация такого-то модуля".
  
  
 VB>> Всегда ли ОПРАВДАHА потеря ЧАСА, на которую идут "спектрумисты"
 VB>> (люди которые сразу начинают колупаться "в битах")?
 
  FZ> Ради обучения, ради создания привычки - да, оправдана.  Причем тут уж
  FZ> не так и важно, что именно тут оптимизируется.
 
  конечно.  Вот, у нас есьт гора кода на C, которую мы постепенно
  прееписываем.  Да, таки снова на Си.  Потмоу что человек, котоырй писал,
  хороший пргарммер, но... Его код в нашем бизнесспроцессе идет по разряду
  unsopported.  Там многое классно оптимизировано, то чего не нужно было
  оптимизировать..  Hо хуже то, что многе непонятно.  Просто непонятно.
  
  FZ> А иначе зачем вообще писать любительские (AFAIK, речь шла
  FZ> именно о них) проекты?
 
  честно говоря, я не понимаю зачем писать любительские проекты :)
  Особенно, если результат не то что на творчество, даже на ремесло.
  
  
 VB>> Да, в xUSSR, при цене часа рабочего времени = "недорого" - наверное
 VB>> пофиг, и сразу копают вглубь Hо ведь это не везде так, да?  Ведье сть
 VB>> люди, котоыре считаю деньги, в смысле время работу
 VB>> высококвалифицированых специалистов, который умеют копаться в битах...
 
  FZ> Специалисты, которые не будут постояно писать чуточку (а может и не
  FZ> чуточку) лучше и эффективнее, чем это вынуждено обстоятельствами, не
  FZ> скоро станут высококвалифицированными и высокооплачиваемыми. IMHO.
 
  конечно.  Hо писать-то можно, хооршо, улучшая навыки, или плохо, забивая
  на всё.
  
  Посмотир сколько еще не то что нерешенных здач, задач за которые даже и не
  брался никто!   И вроде, и специалистов много...  А толку, мало ;)
  
  
  FZ> А причин упростить задачу, воспользоваться быстрым решением вместо
  FZ> эффективного, в индустриальном программировании всегда найдется более
  FZ> чем достаточно.  Hо не надо добавлять к ним еще и "принципиальные".
 
  "Всё гениальное - просто".  Упрощение задачи, это такой основной
  движитель.  Если посмотреть на развитие отрасли IT, даже не отрасли, а на
  вот то "любительское программирование" - люид че-то делают для того, чтоб
  упростить себе решение той или иной задачи.
 
  И мне, честно говоря, енпонятно зачем что-либо УСЛОЖHЯТЬ.
  
  И unix-way, какраз более нравится тем, что тут стараются упростить и
  унифицировать, всё что только можно. 
  
  И, возвращаясь к пинанию ассемблера - отцы юникса сделали очень сильный
  шаг с переходом на Си.  Они УПРОСТИЛИ перенос системы на другое железо. 
  Время идет, наука не стоит на месте, и на мой взгляд, давно пора
  переходить на еще более высокоуровневые инсрументы, а Си, займет место
  ассемблера ;)
  
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

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