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

Question

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

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

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

Редактировать: см. ответ ниже для более точного объяснения взглядов Дийсктра.

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

---

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

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

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

---

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

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

Answer 4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

Answer 9

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

Если бы Google принял программирование "Моцарт", не было бы Gmail или Google Reader.

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

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

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

Answer 10

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