Отдохнем - GLODING PROGRAMMING (Программирование снизу вверх наискосок)

 Music by Shov


               Кафедра АСУ


              G L О Р I N G


          Р R О G R А М М I N G


(программирование  снизу вверх наискосок)
описание системы программирования GLOP

        руководство программиста

              Москва  1983


  "...Тогда достаточно закодировать:
   g l о р
   и вы можете быть уверены,что все
   действия будут выполнены безоши-
   бочно и эффективно."
      Э.Йодан,президент
      jоrdоn inс., N.Y.



     "Может ли господь бог написать про-
      грамму, которую он не сможет отла-
      дить? "


         Безошибочный кодировщик,
         ВZYСК SYSТЕМ LАВ.МЕМВЕR,МIСН.



     В  последние годы на капиталистичес-
ком западе как грибы после дождя разраба-
тываются  всяческие "Теории" программиро-
вания",  призванные, якобы, облегчить на-
писание,  отладку и сопровождение больших
программных комплексов. Очевидно, что бу-
дучи продуктом буржуазной идеологии и вы-
ражая интересы правящего класса, эти тео-
рии  призваны отвлечь широкие массы прог-
раммистов от их истинных интересов. К со-
жалению, и у нас отдельные товарищи попа-
ли  под тлетворное влияние теорий "Струк-
турного",  "Модульного", "Нисходящего или
восходящего"  программирования,  забывая,
что,  чем  дольше  программист отлаживает
программу, тем безошибочнее и эффективнее
она  когда-нибудь будет работать. Поэтому
давно назрела необходимость противопоста-
вить этим лжетеориям нашу домашнюю, само-
дельную,  выстраданную и вымученную мето-
дику программирования. Опыт такой методи-
ки  и  предлагается  читателю. Мы назвали
наш метод "Gloping programming" или "Сни-
зу  вверх наискосок" (СВH). Основную идею
метода  СВH  лучше всего передает древняя
восточная мудрость: "Если что-нибудь мож-
но  сделать двумя способами, не пожалейте
усилий и придумайте третий".


            I. С чего начать.


     Многие   западные  программисты  ут-
верждают,  что прежде чем начинать писать
программу,  необходимо время на обдумыва-
ние алгоритма, а некоторые даже призывают
вникнуть в суть задачи, которую предстоит
решать.  Категорически не следует интере-
соваться  постановкой  задачи  до момента
получения  обьектного  модуля  программы.
Помните,  что  программирование - это ис-
кусство,   поэтому  любые  лишние  знания
только  ограничивают вашу фантазию. Начи-
найте  писать  текст программы задолго до
того,  как  вам  сформулируют техническое
задание, и вы получите прекрасную возмож-
ность  сделать  жизнь вашего руководителя
(и свою) гораздо разнообразнее и интерес-
нее  (например,  в момент получения ТЗ вы
можете    возмутиться:    "Представляете,
сколько теперь придется переделывать?!").
   Никогда    не    составляйте   заранее
блок-схему программы.
     Во-первых,  это проще и быстрее сде-
лать,   когда   программа  уже  написана,
во-вторых,   неосторожно  оставленная  на
столе  блок-схема даст вашим врагам и за-
вистникам  возможность понять, что вы со-
бираетесь делать. Помните, что никто кро-
ме  вас  не  должен  разбираться  в вашей
программе.  И если вы никак не можете из-
бавиться   от  дурной  привычки  рисовать
блок-схемы, то зарубите себе на носу:

  Чем  больше  структура  программы соот-
ветствует ее логике, тем меньше вы стоите
как программист.

               II. Стиль.


     Этому модному словечку многие запад-
ные  адепты  и  апологеты придают особый,
чуть ли не мистический смысл. Безусловно,
каждый  программист  или, там, композитор
имеет  право писать в своей манере, одна-
ко,  учитывая  обьемы програмных разрабо-
ток,  необходимо считаться с реальностью.
Как  и  все  остальные,  программирование
должно быть экономным!
     Тратить  до  50%  перфокарт и обьема
листинга  (слово-то  какое!) на коммента-
рии, пробелы, пустые операторы, звездочки
и  другие украшательства - совершенно не-
допустимая  расточительность.  Пишите  со
2-ой  по  71-ую позиции, всемерно избегая
пробелов. Если комментария никак не избе-
жать,  стремитесь  писать  их  как  можно
конкретнее. Например:

DО J=1 ТО N;/* СYСL РО N*/
IF J>0 ТНЕN GОТО М;/*РЕRЕХОD ТО М*/ 
ЕLSЕ GОТО L; /*РЕRЕХОD К L*/
Х=Х+1; /* РRIВАWIТХ 1 К Х/* ЕND;  
М:  Х=Х-1; /*ТАК НАДО ФЕДЯ!*/
IF А ТНЕN GОТО L;
L: /* ВОЗVЕSТY Х SТЕР. ДВА*/ 
Х=Х**2; ... И Т. Д.

     Всем  переменным давайте имена ваших
знакомых,  любимых  блюд,  эстрадных  ан-
самблей,  сигарет, напитков и т. д. Легко
видеть, что фрагменты типа:

IF КАТJА >= 18  ТНЕN DО;
САLL GАSТRОNОМ;
САLL ТАХI;
GОТО ХАТА; ЕND;
ЕLSЕ GОТО VЕRА;


 GLОРING  СSЕСТ
          ...
 МАRINА   ЕQU   DURА
          ...
          L     АН,МАRUSJА
          SТ    UН,АNJUТА
          ВХLЕ  LЕТS,IRINА,DRINК(АGDАМ)
             /* АSSЕМВLЕR */


поражают  изяществом, остроумием и тонким
вкусом.

     При  внимательном рассмотрении легко
обнаруживается,   что  буржуазные  авторы
книг  рассуждая  о  предмете, который они
называют "Структурным программированием",
тонут в собственных противоречиях. Напри-
мер,  [д.  Майерс], стр. 63: "Скромные по
целям  работающие программы лучше неотла-
женных  грандиозных  проектов", а на стр.
58:  "Если незначительное добавление сде-
лает вашу программу пригодной для другого
случая,  никогда  не пренебрегайте этим".
Мы  готовы  согласиться  с  последним ут-
верждением, поскольку умелое его примене-
ние   позволит  вам  затянуть  разработку
программы на любой мыслимый срок.
    Более  того,  тот же автор через нес-
колько  страниц,  вспоминает  пресловутый
принцип K I S S (Keep is simple, stupid -
будь  проще,  дурачок!). Представляете, в
один прекрасный день руководитель заявля-
ет вам: "Что-то у вас очень уж просто все
получается! "
     Эти  структурно-экстремистские  тен-
денции, в конце концов, приводят к полно-
му  вырождению программирования как твор-
ческой  деятельности.  Предельная степень
деградации  порождает методы типа ашкроф-
та-манны   [э.   Йодан],   сводящие  дея-
тельность программиста к работе Ч. Чапли-
на на конвейере в к/ф "Новые времена".

               III. GО ТО


     Проблема  безусловных  переходов,  к
счастью,  еще не нашла окончательного ре-
шения. Среди программирующей западной мо-
лодежи  распространено  заблуждение,  что
использование оператора gото крайне неже-
лательно.  Практика ведущих программистов
нашей  лаборатории  показывает,  что  ис-
пользование  оператора безусловного пере-
хода  в сочетании с массивами меток повы-
шает  эффективность программ в среднем на
4.2%  При  увеличении  времени отладки на
350-400%.
     Если  нужно  перейти из данной точки
программы,   следует  перейти  как  можно
дальше.  Если перейти некуда, следует пе-
ресмотреть программу.
     Очень  удачны бывают переходы в тело
цикла DO, особенно из других модулей. Хо-
тя трансляторы, как правило, это запреща-
ют, их легко можно обвести вокруг пальца,
пользуясь переменными типа метки. Переда-
ча  управления  в  вызываемую процедуру в
обход  заголовка принесет вам долгие часы
счастливых  раздумий над кодом завершения
0С5.

     Все  вставки в программу следует де-
лать   так:  после  последнего  оператора
ставьте   новую   метку,  напишите  текст
вставки,  увеличьте  размерность  массива
меток  на  2, передайте управление на эту
метку  из нужной точки (или откуда-нибудь
еще), пометьте оператор, следующий за gо-
то, новой меткой, смело измените значение
переменной метки и вернитесь.
     Вообще  говоря, на каком языке вы бы
ни  писали  программы, лучше, если каждый
оператор  будет иметь свою метку (как это
предусмотрено  в фортране). Степень вашей
квалификации,  как  программиста  в стиле
СВH, определяется соотношением:

                   n
              sigма ( v(i)+w(i) )
                  i=1
        k  =  -------------------
                   n
, где   ( 1 )

     n - число операторов,
     v(i) - число передач управления 
на i-тый оператор,
     w(i) - число возможных переходов 
от i-го оператора.

     При k < 0.5 вы, как программист, ни-
куда  не годитесь. Приемлимый коэффициент
3 - 4, а некоторые суперпрограммисты име-
ют k не ниже 12.

            IV. Модульность.


   Никакой   модульности! Вообще...


            V. Эффективность.


     Споры  по  поводу  того, что считать
эффективной  программой, не утихают с тех
пор,  когда  в  спортзале  заработала ЭВМ
М-20.  В наши дни дело дошло до появления
казуистических утверждений вроде: "Удобо-
читаемость  программы существеннее ее эф-
фективности" [д. Майерс].
     Мы  считаем, что эффективность прог-
раммы  является  совершенно обьективной и
количественно  оцениваемой  величиной. Не
надо  жалеть  ни  времени,  ни  усилий  в
борьбе  за  эффективность  -  когда  ваша
программа  в конце концов заработает, все
ваши  затраты окупятся экономией 15 мксек
и 0.073 Кб. Чтобы программист мог заранее
оценить  эффективность  своего  продукта,
предлагается простая формула:

      э = t/t1 + i*t/t2, где (2)


     t1 - время, требуемое срu для выпол-
нения  вашей  программы,  (если программа
еще не выходит на gо, t1 = t);
     t - время, необходимое для вывода на
ацпу заранее заготовленного текста, иден-
тичного тому, который будет печатать ваша
программа, когда выйдет на gо;
     t2  -  время, которое ваша программа
будет  выполняться, когда вы ее полностью
отладите.

     i = sqrt (-1)


     Эффективность  программы, как видно,
величина  комплексная,  что отражает сис-
темный  подход к программированию, харак-
терный для метода СВH.
     Таким  образом, как следует из выра-
жения  (2),  сроки  написания  и  отладки
программы  никоим образом не влияют на ее
эффективность.  Многие программисты, по--
видимому,  интуитивно  пришли к пониманию
этого  факта и годами улучшают свою прог-
рамму,  делая ее все более эффективной за
счет уменьшения параметра t2.
     Кстати,  один  из апологетов "Струк-
турного  программирования"  [д.  Майерс],
позволил себе следующее: "Никто, будучи в
здравом  уме  и твердой памяти, не станет
программировать  на ассемблере." И это по
поводу  любимого  языка  сторонников СВH!
Напротив! Изучение ассемблера - это прек-
расный  путь  к  вершинам  познания ОС ЕС
ЭВМ. Следуя этим путем, вы получите массу
полезных  знаний, которые помогут вам ре-
шить ряд важнейших проблем:
     1).  Как,  получив  талончик на одну
минутку  в  пакете,  захватить  в безраз-
дельное  пользование  CPU по крайней мере
на 1.5 часа, устранить задачи всех других
пользователей  (например,  с кодом s422),
застопорить  очередь заданий, лишить опе-
ратора  возможности  снять  ваше задание,
беспрепятственно  получить результаты (не
взирая на установленный лимит расхода бу-
маги),  и при этом - все претензии опера-
торской  службы  овт  направить в сторону
какой-нибудь кафедры
     2).  Как  испортить  (не стирая) все
чужие  HD  на  вашем пакете 5050/5061, не
оставляя следов в рrintlоg?
     3). Как стереть ядро? (Или IPL?)

     Вообще, существует богатейший спектр
способов  повышения  эффективности  прог-
рамм. Авторы хорошо и давно знакомы с од-
ним  программистом,  который не так давно
выиграл на пари ящик пива, повысив, за 40
минут  поверхностного  анализа, минимум в
два  раза быстродействие трех программ на
фортране,  взятых наугад из мусорной кор-
зины  на  одной  из кафедр ф-та "Т". пос-
кольку  этот  факт  абсолютно не известен
руководству,  программистам  в  стиле СВH
предстоят  долгие  годы  безоблачного су-
ществования  и счастливого программирова-
ния.

         VI. Снова модульность.


     По прежнему, никакой модульности!

     (Поскольку  модульность нельзя пони-
мать  иначе, как наличие известной встро-
енной функции. Все остальное - от лукаво-
го.)
     Считайте  себя  хуже других, если вы
не  в  состоянии написать программу (если
хотите, назовите ее модулем) длиной более
1000 операторов. Если по ряду обьективных
причин  (они  есть  всегда)  вам все-таки
приходится  сталкиваться с проблемой сты-
ковки,  то  помните об одном-единственном
правиле метода СВH:

     Hикаких соглашений о связях!

     В особенности, если приходится иметь
дело  с  программистами  противоположного
пола.

        Согласно   статье  94
    процессуального  кодекса,
    при  разборе дел об уста-
    новлении отцовства прото-
    кол  соглашения  о связях
    учитывается наравне с до-
    казательствами совместно-
    го ведения хозяйства.


     Кроме  того, как уже подчеркивалось,
любые  ограничения  вашей  фантазии,  как
программиста,  не  принесут ничего, кроме
снижения сроков разработки проекта и, тем
самым, уменьшения эффективности конечного
продукта.
     Порадуйте своего руководителя, пове-
сив  над рабочим столом плакат: "Програм-
мирование  -  слишком сложная интеллекту-
альная деятельность, чтобы можно было на-
деяться  навязать ей узы административной
системы,  которая  душит всякую инициати-
ву."  [Ван  Тассел].  Если  реакция руко-
водства окажется более сдержанной, чем вы
ожидали,  перекрасьте дверь вашей лабора-
тории  зеленой  краской  самого ядовитого
цвета  и  исчезните на три дня, предвари-
тельно  отключив домашний телефон [б. Ме-
йер, бодуен].

              VII. Отладка.


     Первая заповедь программиста, успеш-
но  преодолевшего  барьер синтаксического
контроля  -  не  торопиться. Помните, что
плохо  отлаженная  программа всегда менее
эффективна,  чем совсем не отлаженная. Не
выводите на печать более одной переменной
за один прогон. Полученные листинги (рас-
печатки) немедленно уничтожайте (во избе-
жание!.. См. V). С другой стороны, полез-
но  хранить,  в  единственном экземпляре,
протокол  компилятора с наихудшим (это не
сложно) качеством печати с тем, чтобы при
незапланированном  появлении руководителя
можно было бы сказать: "Вот видите, в ка-
ких  условиях приходится работать!" Разу-
меется, диагностические сообщения следует
отрезать, а лучше - неаккуратно оборвать.
(Для  тех,  кто программирует на фортране
или  ассемблере,  рекомендуем  приобрести
некоторые  навыки  работы  с  ножницами и
клеем).

     Если  вы  храните  исходный текст на
HМД, никогда не проверяйте карт IEBUPDTE,
и чтобы не лишать себя приятных неожидан-
ностей!  Более того, проверять пробивку -
дурной  тон и признак гнусного неуважения
к милым и очаровательным девушкам, тратя-
щим  лучшие годы юности на пробивание ды-
рок в ваших перфокартах.
     Когда заканчивается отладка, начина-
ется эксплуатация!
     Ни  один  уважающий себя программист
не допустит, чтобы его любимое чадо, плод
его   многолетних   трудов   и  страданий
эксплуатировали  какие-то посторонние лю-
ди.
     Несколько слов о тестировании. Никто
не знает, в чем именно заключается тести-
рование,  что  является  конечной целью и
какие  результаты следует получить. В ме-
тоде СВH принято считать тестирование за-
конченным,  если выполнение завершается с
кодом  возврата  0000, даже если исходные
данные  различаются  хотя бы одним числом
(или всеми - если вы максималист).

     После  окончания  этапа тестирования
уничтожте  исходный  текст. Только в этом
случае  вы можете быть абсолютно уверены,
что вашей программе никто не причинит ни-
какого вреда и она останется такой же эф-
фективной, какой была всегда.

            Успешной работы!
__________________________________________