Понимание стиля программирования Дейкстры Моцарта

Я встретил эту статью о стилях программирования, которые видел Эдсгер Дижсктра. Чтобы быстро перефразировать, основное отличие - это Моцарт, когда аналогия делается для программирования, полностью понимаемая (спорная) проблема перед тем, как писать что-либо, в то время как Бетховен принял свои решения, написав заметки на бумаге, создавая много изменений на этом пути. С программированием Моцарта версия 1.0 была бы единственной версией для программного обеспечения, которая должна стремиться работать без ошибок и максимальной эффективности. Кроме того, Дейкстра говорит, что программное обеспечение не на этом уровне утонченности и стабильности не должно публиковаться.

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

Мои мысли. Похоже, что для решения растущей сложности программного обеспечения мы перешли от этого метода к таким вещам, как гибкая разработка, публичное бета-тестирование и постоянные изменения, методы, которые определяют веб-разработку, где скорость имеет наибольшее значение. Но когда я думаю обо всех версиях, веб-программное обеспечение может пройти, особенно во время обслуживания, когда часто исправления применяются поверх патчей, а затем уточняются через утомительный процесс рефакторинга. Моцарт выглядит очень привлекательно. Это по меньшей мере уменьшит эти досадные обновления программного обеспечения, например. Digsby, Windows, iTunes и т.д., Что является результатом непредвиденных уязвимостей, требующих новой и немедленной версии.

Изменить: см. ответ ниже для более точного объяснения представлений Dijsktra.

Ответы

Ответ 1

Он не масштабируется.

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

Теперь попробуйте представить команду Моцартов. Всего несколько секунд.


Тем не менее это мощный инструмент. Если вы можете понять целую линию в своей голове, сделайте это. Если вы можете найти небольшую рутину со всеми ее забавными делами, сделайте это.

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

Более глубокое значение (head fake?) можно объяснить, изучая другой человеческий язык. Долгое время вы думаете, какие слова представляют ваши мысли, и как упорядочить их в правильном предложении - что транскрипция стоит много циклов переднего плана.
Однажды вы заметите освобождающее чувство, которое вы просто говорите. Может показаться, что "думать на переднем языке", или как будто "слова приходят естественным образом". Иногда вы будете спотыкаться, ища определенное слово или идиому, но большую часть времени перевод выполняется в огромных ресурсах "подсознательного процессора" .


"Высокая цель" - это разработка ментальной модели решения, которая (в основном) не зависит от языка реализации, отделяет решение проблемы от переписывания проблемы. Транскрипция проста, повторяется и легко обучается, а абстрактные решения могут быть повторно использованы.

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

Ответ 2

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

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

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

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

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

Ответ 3

Эдсгер Дейкстра обсуждает свои взгляды на программирование Моцарта против Бетховена в этом видео на YouTube под названием " Discipline in Thought".

alt text

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

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

Есть некоторые отрасли или приложения программирования, которые, как мне кажется, также заслуживают "дисциплины" Дейкстры. NASA Rovers, встроенные устройства для индустрии здравоохранения (например, раздаточные лекарства и т.д.), Определенное финансовое программное обеспечение, которое передает наши деньги. Эти места не имеют роскоши инкрементных изменений после выпуска, и необходим более "подход Моцарта".

Ответ 4

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

Реальные программисты записывают в Fortran.

Может быть, сейчас, в этом декадентском эры пива Lite, ручных калькуляторов и "удобное" программное обеспечение, но добрые старые дни, когда термин "Программное обеспечение" звучало смешно и реально Компьютеры были сделаны из барабанов и вакуумные трубки, Real Programmers написал в машинный код. Не Фортран. Не RatFor. Нет, даже, язык ассемблера. Машинный код. Сырые, без прикрас, неиспользуемые шестнадцатеричные числа. Непосредственно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 5

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

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

Я пользуюсь Simucal response, но я думаю, что метафора Моцарта-Бетховена должна быть отброшена. Это обувные рожки Дейкстры настаивают на дисциплине и понимании в углу, где это действительно не принадлежит.

Дополнительные замечания:

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

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

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

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

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

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

Ответ 6

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

Ответ 7

Ну, мы все не можем быть такими же хорошими, как Моцарт, не так ли? Возможно, программирование Бетховена проще.

Ответ 8

Если Apple примет программирование "Моцарта", сегодня не будет Mac OS X или iTunes.

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

Если разработчики SO приняли "Моцарт", сегодня не было бы SO.

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

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

Ответ 9

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

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

Ответ 10

Прогресс в вычислениях стоит жертвы в славе или гении здесь и там.