Понимание стиля программирования Mozart Dijkstra

Стиль программирования Mozart является полным мифом (все должны отредактировать и изменить их первоначальные усилия), и хотя "Mozart" является по существу метафорой в этом примере, стоит отметить, что Mozart был существенно мифом сам.

Mozart был воображаемым волшебным вундеркиндом, который сочинил его первую сонату в 4 (ему было на самом деле 6 лет, и она высосала - Вы никогда не будете слышать, что она работала где угодно). Редко упоминается, конечно, что его родительский элемент считали самым великим учителем музыки Европы, и что он вынуждал всех своих детей к проигрыванию практики и составу в течение многих часов каждый день, как только они могли взять инструмент или перо.

Сам Mozart старался увековечить иллюзию, что его музыка появилась целая из его ума путем уничтожения большинства его проектов, хотя достаточно выживают, чтобы показать, что он был редактором как все остальные. Beethoven был просто более честным о процессе (возможно, потому что он был глухим и не мог сказать, крался ли кто-либо на нем так или иначе).

Я даже не упомяну теорию, что Mozart получил свои мелодии от слушания певчих птиц. Или то, что он создал систему, которая использовала игру в кости для случайной генерации музыки (который на самом деле довольно прохладен, но мог бы также объяснить, сколько из музыки Mozart, казалось, прибыло из ниоткуда).

Мораль истории: не верьте шумихе. Программирование является работой, сопровождаемой большим количеством работы для фиксации ошибок, которые Вы сделали в первый раз вокруг, сопровождаемый большим количеством работы для фиксации ошибок, которые Вы сделали во второй раз вокруг, и т. д. и т. п. пока Вы не умираете.

Я думаю, что возможно, казаться, нанять Mozart, программирующего. Я знаю об одной компании, Снежной буре, которая не выпускает программный продукт, пока они не хороши и готовы. Это не означает, что Diablo 3 будет пружинное целое и завершаться от чьего-то ума на одной сессии великолепно блестящего кодирования. Это действительно означает, что это - то, как это появится к остальной части нас. Снежная буря протестирует heck из их игры внутренне, не показывая его остальной части мира, пока у них не будет всех разработанных петель. Большинство компаний не проявляет этот подход, предпочитая вместо этого выпускать программное обеспечение, когда это достаточно хорошо, чтобы решить проблему, затем исправить ошибки и добавить опции, поскольку они подходят. Этот подход работы (в различных степенях) для большинства компаний.

Ну, мы не можем все быть столь же хорошими как Mozart, не так ли? Возможно, Beethoven, программирующий, легче.

Edsger Dijkstra обсуждает свои представления о Mozart по сравнению с Beethoven, программирующим в этом видео YouTube, наделенном правом "Дисциплина в Мысли".

Люди в этом потоке в значительной степени обсудили, как представления Dikstra непрактичны. Я собираюсь попытаться защитить его некоторые.

• Dijkstra против компаний, по существу "тестирующих" их программное обеспечение на их клиентах. Выпуск версии 1.0 и затем сразу исправляет 1.1. Он чувствовал, что программа должна полироваться в известной степени, что патчи "текущих исправлений" являются неэтичной границей.
• Он не думал, что программное обеспечение должно быть записано одним махом или что изменения никогда не должны были бы вноситься. Он часто обсуждает свои идеалы дизайна, одного из них являющийся модульным принципом и простотой изменения. Он часто думал, что отдельные алгоритмы должны быть записаны таким образом однако после завершенного понимания проблемы. Это было частью его дисциплины.
• Он нашел после всего своего обширного опыта с программистами, что программисты не счастливы, если они не раздвигают границы своего знания. Он сказал, что программисты не хотели программировать что-то они полностью и 100%, понятых, потому что не было никакой проблемы в нем. Программисты всегда хотели быть на грани своего знания. В то время как он понял, почему программисты похожи на это, он заявил, что это не было представительным для программирования допуска низкой ошибки.

Существуют некоторые отрасли промышленности или приложения программирования этого, я полагаю, что "дисциплина" Dijkstra гарантирована также. НАСА Роверы, медицинская Промышленность встроила устройства (т.е. распределите лечение, и т.д.), определенное программное обеспечение Financial, которые передают наши деньги. Эти области не имеют роскоши возрастающего изменения после выпуска, и больше "Подхода Mozart" необходимо.

Я думаю, что история Mozart путает то, что поставляется по сравнению с тем, как она разрабатывается. Beethoven не проводил бета-тестирование своих симфоний на общественности. (Было бы интересно видеть, насколько он изменил любые из очков после первого публичного выступления.)

Я также не думаю, что Dijkstra настаивал, чтобы все это было сделано в Вашей голове. В конце концов, он записал книги по дисциплинированному программированию, которое включило разработку его на бумаге, и до той же степени, что он хотел видеть дисциплину математического качества, Вы заметили, сколько бумага и математики классной доски могут использовать при работе над проблемой?

Я одобряю ответ Simucal, но я думаю, что метафора Mozart-Beethoven должна быть отброшена. То, что настойчивость Dijkstra рожков для обуви на дисциплине и понимающий в угол, где это действительно не принадлежит.

Дополнительные комментарии:

Телевизионная популяризация не является настолько горячей, и она путает некоторые вещи о музыкальном составе и что делает компоновщик и что делает программист. В собственных словах Dijkstra, от его Лекции Премии Turing 1972 года: "Мы не должны забывать, что это не наш бизнес для создания программ; именно наш бизнес для разработки классов вычислений отобразит желаемое поведение". Компоновщик может отсутствовать для обнаружения желаемого поведения.

Кроме того, в понятии Dijkstra, что версия 1.0 должна быть окончательной версией, мы слишком легко путаем, как желаемое поведение и функциональность развиваются со временем. Я полагаю, что он упрощает в размышлении, что все будущие версии - то, потому что первый не был продуман и сделан строго и надежно.

Даже без безотлагательности времени выхода на рынок, я думаю, что мы теперь понимаем намного лучше, что важные виды программного обеспечения развиваются наряду с пользовательским опытом с нею и утилитарной целью, которую они имеют для нее. Очевидные контрпримеры являются играми (также рассматривают, как театральные изображения движущихся объектов разрабатываются). Вы думаете, что Beethoven, возможно, записал Симфонию № 9 безо всего его предыдущего опыта и исследования? Вы думаете, что аудитория, возможно, услышала его для того, каково это было? Он должен был ожидать, пока у него не было идеальной Сонаты? Я уверен, что Dijkstra не предлагает это, но я действительно думаю, что он заходит слишком далеко с Mozart-Beethoven для высказывания его мнения.

Кроме того, рассмотрите играющее шахматы программное обеспечение. Новые версии - то, не потому что предыдущие не играли правильно. Это об использовании усовершенствований в играющей шахматы эвристике и доступной производительности компьютера. Для этого и многих других ситуаций, идея, что версия 1.0 быть окончательной версией от основы. Я понимаю, что он законно возражает против выпуска ненадежных known-to-be и возможно программное обеспечение, которому повреждают, с дефицитами, которые будут составлены в обслуживании и будущих выпусках. Но моцартовский контрдовод не держит для меня.

Так, Dijkstra продолжал управлять первым автомобилем, который он купил, или клоны точно того автомобиля? Возможно, существует запланированное устаревание, но многое из него имеет отношение к улучшениям и надежности, которая, возможно, не возможно была доступна или даже продумана в предыдущих поколениях автомобильной технологии.

Я - крупный поклонник Dijkstra, но я думаю, что вещь Mozart-Beethoven является слишком упрощенной, а также несоответствующей. Я - крупный поклонник Beethoven также.

Классическая история из Usenet, об истинном программировании Mozart.

Настоящие Программисты пишут в Фортране.

Возможно, они делают теперь, в эту декадентскую эру Облегченного пива, вручают калькуляторы и "удобное для пользователя" программное обеспечение, но назад в Добрые старые времена, когда термин "программное обеспечение" звучал забавным и Реальные Компьютеры, были сделаны из барабанов и вакуумных ламп, записали Настоящие Программисты в машинном коде. Не Фортран. Не RATFOR. Не, даже, ассемблер. Машинный код. Сырые данные, неукрашенные, непостижимые шестнадцатеричные числа. Непосредственно.

Чтобы совершенно новое поколение программистов не растет в незнании этого великолепное прошлое, я чувствую себя обязанным для описания, как лучше всего я могу через конфликт поколений, как Настоящий Программист написал код. Я назову его Mel, потому что это было его именем.

Я встретился в первый раз с Mel, когда я пошел для работы на Royal McBee Computer Corp., ныне несуществующий филиал компании печатающего устройства. Фирма произвела LGP-30, маленькое, дешевое (по стандартам дня) компьютер памяти барабана, и только что начала производить RPC-4000, очень улучшенный, большее, лучше, быстрее - компьютер памяти барабана. Ядра стоят слишком много и не установились, так или иначе. (Вот почему Вы не услышали о компании или компьютере.)

Я был нанят для записи компилятора Фортрана для этого нового чуда, и Mel был моим руководством по его чудесам. Mel не одобрил компиляторы.

"Если программа не может переписать свой собственный код", спросил он, "что хороший это?"

Mel записал, в шестнадцатеричном, самая популярная компьютерная программа принадлежавшая компания. Это работало на LGP-30 и играло в блэк джек с потенциальными клиентами на компьютерных шоу. Его эффект был всегда поразителен. Стенд LGP-30 был упакован на каждом шоу, и продавцы IBM стояли вокруг того, чтобы говорить друг с другом. Не обсуждало ли это, на самом деле проданные компьютеры были вопросом мы, никогда.

Задание Mel состояло в том, чтобы переписать программу блэк джека для RPC-4000. (Порт? Что это означает?) Новый компьютер имел одну плюс одну схему адресации, в которой каждая машинная команда, в дополнение к коду операции и адресу необходимого операнда, имела второй адрес, который указал, где на автоматически возобновляемом барабане следующая инструкция была расположена. Говоря современным языком каждым инструкциям следовало ДВИЖЕНИЕ К! Помещенный это в канал и дым Паскаля это.

Mel любил RPC-4000, потому что он мог оптимизировать свой код: то есть, найдите инструкции относительно барабана так, чтобы так же, как каждый закончил его задание, следующее будет просто прибывать в "считывающую головку" и доступное для непосредственного выполнения. Была программа, чтобы сделать то задание, "ассемблер оптимизации", но Mel отказался использовать его.

"Вы никогда не знаете, куда это собирается поместить вещи", объяснил он, "таким образом, необходимо будет использовать отдельные константы".

Это было долгое время, прежде чем я понял тот комментарий. Так как Mel знал численное значение каждого кода операции и присвоил его собственные адреса барабана, каждую инструкцию, которую он записал, можно было также считать числовой константой. Он мог взять более раннее, "добавляет" инструкция, скажем, и умножается им, если это имело правильное числовое значение. Его код не был легок для кого-то еще изменить.

Я сравнил оптимизированные рукой программы Mel с тем же кодом, массажировавшим оптимизирующей ассемблерной программой, и Mel всегда работал быстрее. Это было то, потому что "нисходящий" метод проектирования программы еще не был изобретен, и Mel не будет использовать его так или иначе. Он записал самые внутренние части своих программных циклов сначала, таким образом, они получат предпочтительный вариант оптимальных местоположений адреса на барабане. Ассемблер оптимизации не был достаточно умен, чтобы сделать это тот путь.

Mel никогда не писал циклы с временной задержкой, также, даже когда упрямый Флексорайтер потребовал, чтобы задержка между выходными символами работала правильно. Он просто определил местоположение инструкций относительно барабана так каждый, какой последовательный просто прошел считывающую головку, когда это было необходимо; барабан должен был выполнить другой полный оборот для нахождения следующей инструкции. Он ввел незабываемый термин для этой процедуры. Хотя "оптимум" является свободным членом, как "уникальный", это стало общей словесной практикой для создания этого родственником: "не совсем оптимальный" или "менее оптимальный" или "не очень оптимальный". Mel назвал максимальные местоположения с временной задержкой "большей частью пессимума".

После того, как он закончил программу блэк джека и заставил ее работать, ("Даже инициализатор оптимизирован", сказал он гордо), он получил Запрос на изменение от отдела продаж. Программа использовала изящный (оптимизированный) генератор случайных чисел для перестановки "карт" и соглашения из "деки", и некоторые продавцы чувствовали, что это было слишком справедливо, с тех пор иногда потерянные клиенты. Они хотели, чтобы Mel изменил программу так при установке пультового переключателя на консоли, они могли изменить разногласия и позволить клиенту победить.

Mel мешают. Он чувствовал, что это было очевидно нечестно, которым это было, и что это посягнуло на его персональную целостность как программист, которого это сделало, таким образом, он отказался делать это. Главный Продавец говорил с Mel, также, как и Крупный Босс и, при убеждении босса, нескольких Коллегах - Программистах. Mel наконец сдал и написал код, но он получил тест назад, и, когда пультовый переключатель был включен, программа обманет, побеждая каждый раз. Mel был восхищен этим, утверждая, что его подсознание было неудержимо этично, и непреклонно отказалось фиксировать его.

После того, как Mel оставил компанию для более зеленого pa$ture$, Крупный Босс попросил, чтобы я посмотрел на код и видел, мог ли я найти тест и инвертировать его. Несколько неохотно я согласился посмотреть. Отслеживание кода Mel было реальным приключением.

Я часто чувствовал, что программирование является видом искусства, действительное значение которого может только цениться другим сведущим в том же тайном искусстве; существуют прекрасные драгоценные камни и блестящие перевороты, скрытые от человеческого представления и восхищения, иногда навсегда, самой природой процесса. Можно узнать много о человеке только путем прочтения его кода, даже в шестнадцатеричном. Mel был, я думаю, незамеченный гений.

Возможно, мой самый большой шок прибыл, когда я нашел невинный цикл, который не имел никакого теста в нем. Никакой тест.Ничего. Здравый смысл сказал, что это должен был быть замкнутый цикл, где программа окружит, навсегда, бесконечно. Программное управление передало прямо через него, однако, и безопасно другая сторона. Мне потребовались две недели для понимания этого.

Компьютер RPC-4000 имел действительно современное средство, названное индексным регистром. Это позволило программисту писать программный цикл, который использовал индексируемую инструкцию внутри; каждый раз через, число в индексном регистре было добавлено к адресу той инструкции, таким образом, это будет относиться к следующей данной величине в ряду. Он должен был только увеличить индексный регистр каждый раз через. Mel никогда не использовал его.

Вместо этого он вытянул бы инструкцию в регистр машины, добавить тот к его адресу и сохранить его назад. Он затем выполнил бы измененную инструкцию прямо от регистра. Цикл был записан так, это дополнительное время выполнения было принято во внимание - так же, как эта законченная инструкция, следующий был правильным под считывающей головкой барабана, готов пойти. Но цикл не имел никакого теста в нем.

Жизненная подсказка прибыла, когда я заметил, что индексный регистр укусил, бит, которые кладут между адресом и кодом операции в командном слове, был включен - все же, Mel никогда не использовал индексный регистр, оставление его обнуляет все время. Когда свет продолжался, он почти ослепил меня.

Он определил местоположение данных, он продолжал работать около вершины памяти - самые большие места, к которым инструкции могли обратиться - так, после того, как последняя данная величина была обработана, увеличивание адреса команды заставит его переполниться. Перенос добавил бы тот к коду операции, изменив его на следующий в системе команд: команда перехода. Конечно же, следующая инструкция по программе была в нуле местоположения адреса, и программа пошла счастливо продвигающаяся.

Я не поддержал контакт с Mel, таким образом, я не знаю, признавал ли он когда-нибудь лавинную рассылку изменения, которое нахлынуло на методы программирования с тех давно ушедших дней. Мне нравится думать, что он не сделал. В любом случае я был впечатлен достаточно, что я вышел из поиска незаконного теста, говоря Крупному Боссу, я не мог найти его. Он не казался удивленным.

Когда я покинул компанию, программа блэк джека все еще обманула бы, если бы Вы включили правильный пультовый переключатель, и я думаю, что это - то, как это должно быть. Я не чувствовал себя комфортно, изрубив код Настоящего Программиста.

Я думаю, что идея состоит в том, чтобы запланировать заранее. У Вас должна, по крайней мере, быть некоторая схема того, что Вы пытаетесь сделать и как Вы планируете добраться там. Если Вы просто садитесь в клавиатуре и надеетесь, что "муза" приведет Вас туда, где Ваша программа должна пойти, результаты склонны быть довольно неровными, и она возьмет Вас намного дольше для получения там.

Это верно с любым видом для записи. Очень немного авторов просто садятся в печатающем устройстве без идей и начинают стучать далеко, пока пользующийся спросом роман не производится. Heck, мой тесть (английский учитель средней школы) на самом деле пишет основы для его буквы .

Если бы Apple приняла "Mozart", программирующего, то не было бы никакого Mac OS X или iTunes сегодня.

Если бы Google принял "Mozart", программирующего, то не было бы никакого Gmail или Google Reader.

РАЗ ТАК разработчики приняли "Mozart", программирующего, будет не ТАК сегодня.

Если бы Microsoft приняла "Mozart", программирующего, то не было бы никакого Windows сегодня (хорошо, я думаю, что это было бы хорошо).

Таким образом, ответ просто НЕТ. Ничто не прекрасно, и ничто никогда не предназначается, чтобы быть прекрасным, и это включает программное обеспечение.

Прогресс вычислений стоит жертвы в славе или гении тут и там.