Эдгар Дейкстра. Два взгляда на программирование. Часть 3…

продолжение:

Однако ни эти наблюдения, ни указания на провал попытки Кобола выжить среди профессиональных программистов не произвели никакого впечатления на правоверных. Они объяснят вам, что традиционные языки программирования высокого уровня потерпели крах из-за их «процедурности», и что провал Кобола очевиден, поскольку ввиду недостаточной интерактивности он на самом деле не является простым человеческим языком. Но вот через пять или десять лет дальнейший прогресс в области Искусственного Интеллекта (для посвященных — AI, т.е. Artificial Intellect) позволит нам построить «контекстно-зависимые», «основанные на знаниях», «автоматизированные системы для мышления и понимания», такие, что «пользователю достаточно будет только побеседовать с ними». Должно быть, я неизлечимый скептик, но мне весьма трудно поверить, что подобным надеждам суждено сбыться. Имеются некоторые видимые подтверждения таких ожиданий. Я цитирую отрывок из недавно полученного письма: «в общем, передача более совершенному компьютеру того, что мы сегодня называем человеческими навыками, знанием и разумом». Я не намерен повторять здесь фрагменты горячих дискуссий, которые мы проводили по поводу значимости Искусственного Интеллекта, да здесь это и ни к чему. Во-первых, оглядываясь назад, приходим к неизбежному заключению: смешивать надежды на будущее AI с завтрашней реальностью было бы безрассудством. Весьма безответственно жить в таком розовом тумане, учитывая, что мечты по поводу AI могут так и остаться мечтами, по крайней мере, на протяжении нашей жизни. Или, говоря другими словами, глядя на серьезность сегодняшних проблем программирования, обычная осторожность заставляет нас не забывать о взгляде В.

Во-вторых, первоочередная задача программиста, если он хочет, чтобы его творения заслуживали доверия, состоит в том, чтобы делать их максимально понятными, так чтобы он мог нести за них ответственность. Независимо от ответа на вопрос, как много из его нынешней деятельности может быть переложено на машину, мы должны всегда помнить, что ни «понимание», ни «ответственность» не могут быть классифицированы как деятельность: это скорее «состояние разума», и оно в принципе не может быть передано машине. Я считаю неразумным, в особенности для ученого-компьютерщика, недооценивать влияние психологической школы, которая, считая человеческий разум слишком сложным и трудно поддающимся изучению, занялась вместо этого изучением крыс, и даже ограничивает это изучение — как я слышал недавнюю формулировку — «наиболее механической формой поведения — зачастую настолько механической, что даже крысам не дают проявить свои высшие возможности».
Представляя свои грубые, механические модели в качестве допустимого приближения к человеческому разуму, они опасно усложнили вопрос о различиях между человеком и машиной, и мы наблюдаем два взаимно дополняющих друг друга феномена: антропоморфный взгляд на машины и механический взгляд на людей.
Эта неразбериха, вне всякого сомнения, — плод усилий верховных жрецов AI. Преобладание в основном антропоморфной терминологии в компьютерной науке — «память», «интерпретатор», «язык программирования», «рукопожатие», «диалог» — и это лишь частные примеры — это предупреждение, которое не следует игнорировать. Я не знаю, как думать и разговаривать, обходясь без метафор; я знаю также, что каждая метафора несет в себе опасность скрытого подтекста. В данном случае благодаря антропоморфной терминологии в компьютерной науке мы давно уже достигли стадии, когда опасность путаницы перевешивает достоинства аналогии. Кроме того, кажется, что механический подход к людям среди компьютерных ученых (и их руководителей) распространен шире, чем представляется мне нормальным. Ибо я подозреваю, что именно этот механический подход ограничивает деятельность программистов механическими действиями по написанию кода и затем измеряет «производительность труда программиста» количеством произведенных им строк кода. (Когда весьма широко известный и очень уважаемый ученый-компьютерщик использовал недавно эту меру производительности труда программиста в своей лекции, от слушателей поступило предложение говорить не о «количестве произведенных строк кода», а о «количестве израсходованных строк кода», и что лектор, следовательно, занес их не в ту графу учета баланса расходов и доходов. Лектор ответил, что он вынужден использовать эту меру производительности, поскольку не располагает альтернативой, которая позволяла бы вести точный учет!) Это не может больше рассматриваться как безобидное заблуждение, поскольку такая бессмысленная «мера производительности» гарантированно стимулирует профессиональных программистов к написанию рыхлого кода. Влияние психологии было рассмотрено здесь, поскольку оно объясняет цепкость, с которой так много людей склонны держаться взгляда А. В основном это не вина производителей компьютеров, которые желают вести дела так, будто они продают простейшую продукцию; и не вина руководителей программных проектов, которые предпочитают рассматривать деятельность программистов как простой и предсказуемый процесс; и не вина учебных заведений, которые хотели бы дать студентам гарантию в достижении профессионального. Это следствие комфортной иллюзии, что Человек — это лишь сложный автомат. Эта иллюзия, подобно наркотику, приносит своим жертвам кажущееся освобождение от бремени ответственности. Признание программирования серьезным вызовом интеллекту вернуло бы полный вес этой ноши обратно на плечи людей.
prof. dr. Edsger W. Dijkstra
Burroughs Research Fellow

PS: мною найден интересный блог - Цифровая жизнь. Много полезных ссылочек и постов на тему блоггинга и продвижения. Плюс заметки о прогах и инет-сервисах. Рекомендс.

PPS: перечитал название одного моего поста и родилось: “Говорят брокер - не ипотечный!!!” (via Ivan Vasil’evich change work =)

Эдгар Дейкстра. Два взгляда на программирование. Часть 2…

Откуда взялся взгляд В? Были люди, которые чувствовали, что появление больших и быстрых машин заменит тесные башмаки хотя бы на башмаки по размеру, и что, несмотря на это, эффективность выполнения программ останется серьезной заботой программиста. Заботой, которая станет даже более важной по мере роста машин и приложений, а более сложные установки поставят перед нами еще более трудные проблемы. Также было замечено, что переключение с машинного кода на языки высокого уровня вовсе не гарантирует тех преимуществ, на которые возлагали столько надежд. В частности, программисты продолжали столь же охотно выдавать большие куски непонятного кода, и единственное различие было в том, что теперь они делали это в
более грандиозных масштабах, а высокоуровневые ошибки пришли на смену низкоуровневым. Люди также поняли, что появление языков программирования высокого уровня не уменьшает потребности в скрупулезности: избыточность языков высокого уровня лишь уменьшает вредный эффект от некоторых видов небрежности. И тогда появился взгляд В. (Взгляд В не является реакцией на кризис программного обеспечения, который стал очевиден в 1968 г., тогда как на самом деле он намного старше. Фактически сторонники взгляда В предсказали этот кризис, что не менее не истребило взгляда А.)
После этой интермедии по поводу появления взгляда В вернемся к нашему вопросу: как и почему наряду с очевидными проблемами программного обеспечения взгляд А (а именно: программирование по сути — вещь несложная) все еще здравствует. Вот ответ: из-за веры, причем не веры в лучших программистов, а веры в лучшие языки программирования или (диалоговые?) системы программирования, а также веры в лучшие технологии программного менеджмента. Я придерживаюсь мнения, что программирование — один из наиболее сложных разделов прикладной математики, поскольку оно также является одним из наиболее сложных направлений инженерии, и наоборот. Когда я попытался разъяснить одному из моих коллег-математиков, почему я придерживаюсь этого мнения, он довольно бесцеремонно отказался выслушать мои доводы и вместо этого обвинил меня и моих единомышленников-компьютерщиков в том, что мы до сих пор не создали язык программирования, который сделал бы программирование настолько простым, насколько ему и подобает быть! Возможно, мне стоило бы спросить его, почему математики до сих пор не разработали руководство, которая позволила бы любому, невзирая на отсутствие профессиональной подготовки, заниматься математикой? Копнув чуть глубже, выясняется, что сторонники взгляда А не отрицают потенциальной сложности программ и их разработки, но верят, что жизнь программистов будет становиться все легче, поскольку все наиболее сложные части задачи будет брать на себя машина. Они указывают на появление языков программирования высокого уровня, которые уже сделали программирование гораздо легче, чем во времена старых машин, и опрометчиво утверждают, что в будущем программирование станет вовсе тривиальным. Но оправданы ли такие заявления? Я много программировал как в машинных кодах, так и на языках высокого уровня, и последние, несомненно, более удобны, поскольку в этом случае многие решения, относящиеся к внутренним деталям программы, такие как распределение памяти, не приходится принимать явно, поскольку ими занимается алгоритм распределения памяти компилятора. Переход к языкам высокого уровня освобождает нас от многих обычных забот. Это вывело из программирования большую часть нудной работы и очень многое стало зависеть от изобретательности: именно та часть работы, которая занимала целые дни, исчезла! Вывод, который следует из появления языков программирования высокого уровня, — о том, что необходимы программисты большего интеллектуального калибра, — полностью подтвердился наблюдениями в Западной Европе (где я мог следить за разработками последнего времени): в конце 1960-х гг. многие крупные организации испытывали проблемы в подборе подходящей работы для программистов, нанятых 1950-е гг., поскольку профессия
переросла их интеллектуальные возможности.

PS: наткнулся на блог Евгения Степанищева - bolknote.ru. Очень позитивный, душевный и приятно оформленный “прямыми” руками блог =)). Рекомендую. А ящерицу я чето сразу заприметил =)

Эдгар Дейкстра. Два взгляда на программирование. Часть 1…

Я уже как-то публиковал статью Дейсктры. Вот новая. Перевод с англ. Олег Хачкинаев (Alf), 14 августа 2004:

Существует два расхожих и радикально противоположных взгляда на программирование:
• Взгляд А: Программирование по сути — вещь несложная.
• Взгляд В: Программирование — это очень сложно.
Такое противоречие можно объяснить тем, что в этих двух утверждениях само слово «программирование» употребляется в двух совершенно различных значениях, и на этом успокоиться. Тем не менее этого все-таки недостаточно. От того, какой из взглядов считается более предпочтительным, зависят не только кадровая политика организаций, использующих компьютеры, и учебные программы высших учебных заведений, но и направление развития и исследований в самой компьютерной науке. Таким образом, имеет смысл более детально рассмотреть природу различий между этими двумя убеждениями и по возможности очертить обстоятельства, в соответствии с которыми люди выбирают один подход, а не другой. В этом и есть назначение данного документа.
В этом исследовании мне видится одно препятствие: в этой дискуссии я не являюсь нейтральной стороной. Я — убежденный сторонник взгляда В и рассматриваю взгляд А как основную причину многих печальных заблуждений.

С другой стороны, я не считаю, что наличие собственного мнения дисквалифицирует меня как автора, особенно если я заранее предупрежу об этом своих читателей и не буду притворяться нейтральным. В процессе анализа мы раскроем, как эти различные взгляды на программирование (которое является человеческой деятельностью!) связаны с различными человеческими убеждениями. Влияние предрассудков и мнений — уже само объясняет то почти религиозное рвение, с которым ведутся сражения между сторонниками разных лагерей. Начальный период истории автоматических вычислений делает взгляд А очень понятным. До того как у нас появились компьютеры, программирование вообще не являлось проблемой. Затем появились первые машины: по сравнению с нашими нынешними компьютерами они были просто игрушками, и по сравнению с тем, что мы пытаемся делать сейчас, они использовались лишь для «микроприложений». Если на этом этапе программирование и было проблемой, то весьма незначительной. Добавьте к этому источники трудностей, которые в то время поглощали — или лучше
сказать узурпировали? — большую часть нашего внимания:
1. Арифметические устройства были слишком медленные по отношению к тому, что мы хотели делать с их помощью: эти башмаки почти всегда оказывались слишком тесными, и ради эффективности программы допускались все возможные трюки кодирования (и очень немногие из них реально не использовались).
2. Разработка и конструирование арифметических устройств были настолько новой и, следовательно, трудной задачей, что, если очередная аномалия в коде инструкции могла избавить от каких-либо кульбитов, от них обычно избавлялись — разумеется и потому, что у нас было так мало опыта в программировании, мы не могли хорошо распознавать «аномалии в программном коде»; в результате нам не было необходимости использовать трюки в коде, но также у нас была великолепная возможность их применять.
3. Памяти всегда было слишком мало, и это вместе с ненадежностью первого оборудования препятствовало более разумному использованию машин.

В это время программирование представлялось в первую очередь как битва с ограничениями машины, битва, которую нужно было выиграть хитростью. Это было систематическое использование специфических особенностей каждой машины: это был расцвет виртуозного кодирования. В течение следующих 10—15 лет процессоры стали в тысячи раз быстрее, памяти стало в тысячи раз больше, и языки программирования высокого уровня вошли в обиход. И именно в это время, с одной стороны, программирование все еще прочно ассоциировалось с тесными башмаками, в то время как с другой — чувствовалось, что башмаки жмут все меньше и меньше, и ожидалось, что
еще через пять лет технического прогресса проблемы в программировании вовсе исчезнут. Именно в это время сформировался взгляд А. В конце этого периода, на волне популярности взгляда А, был разработан Кобол с тем посылом, что он должен сделать программирование как вид деятельности профессиональных программистов ненужным, позволив «пользователю» (не в это ли время слово «пользователь» стало общеупотребимым?) записывать то, что он хочет, на «простом языке», который любой может прочесть и понять.

Все мы знаем, что эта прекрасная мечта так и осталась мечтой. Следующие пять лет принесли нам вместо исчезновения всех проблем, связанных с программированием, кризис программного обеспечения, и Кобол вместо того чтобы выжить профессиональных программистов стал грандиозным инструментом программирования для еще большего их числа; и по прошествии десяти лет мы все еще имеем машины, в которых ошибки базового программного обеспечения вызывают в среднем час простоя на каждые 15 часов работы. Очевидно, что серьезные проблемы программирования до сих пор налицо…

Забавная вещь: несмотря на полную очевидность обратного, взгляд А все еще жив. Некоторые объясняют этот странный факт, с укоризной указывая пальцем на большие организации. Также можно апеллировать к организациям, которые, привлекая специалистов, разделяющих взгляд А, из-за этого потеряли возможность свободно расстаться с ним, либо к фирмам-производителям компьютеров и образовательным институтам, которые поддерживают широко распространенный взгляд А, поскольку должны представлять его как основной для их рынка. Даже если этот упрек заслуженный, я не могу принять его как достаточное объяснение живучести взгляда А, и вынужден предположить, что подход А соответствует каким-то более глубинным потребностям человеческого сознания.

PS: смотрел буклеты в турагенстве - пляжи Хорватии и Черногории просто сногсшибательны. Все-таки красиво, там где нас нет! =))) Но мы скоро и туда доберемся.

Джоэл Спольски. Лучшие примеры разработки ПО. Сколько работников Microsoft нужно для того, чтобы сменить лампочку? Часть 2…

продолжение:

• По крайней мере один разработчик, один тестер и один РП, чтобы провести
  «мозговой штурм» для выявления потенциальных проблем безопасности.
• Один РП, чтобы включить модель безопасности в спецификацию.
• Один тестер, чтобы написать план тестирования.
• Один руководитель группы тестирования, чтобы обновить график тестирования.
• Один тестер, чтобы написать контрольные примеры и включить их в ночную автоматическую проверку.
• Три или четыре тестера, чтобы участвовать в выявлении ошибок именно для данного случая.
• Один технический автор, чтобы написать документацию.
• Один технический рецензент, чтобы проверить документацию.
• Один редактор, чтобы проверить документацию.
• Один руководитель отдела документации, чтобы интегрировать новую документацию в существующий текст, обновить содержание, алфавитные указатели и т. д.
• Двадцать пять переводчиков, чтобы перевести документацию и сообщения об ошибках на все языки, поддерживаемые Windows. Руководители переводчиков живут в Ирландии (европейские языки) и Японии (азиатские языки); оба места существенно сдвинуты по времени относительно Редмонда , поэтому общение с ними иногда создает непростые организационные проблемы.
• Группа старших руководителей, чтобы координировать работу всех этих людей, выписывать чеки и объяснить смысл дополнительных затрат вице-президенту.

Ни одна из этих задач по отдельности не занимает много времени, но они быстро накапливаются — и это для очень простой возможности. Обратите внимание: я исхожу из того, что все работает идеально; а если в пяти строках кода окажется ошибка? Придется прибавлять затраты на поиск ошибок, написание регрессионных тестов и т. д.
Исходные пять минут программирования оборачиваются многими человеко-неделями работы и огромными затратами — и только потому, что одному человеку лень за несколько минут склепать на VB6 элемент, выполняющий нужную задачу. Простите, но в коммерческом отношении это не имеет ни малейшего смысла.
Мы в Microsoft очень, очень стараемся не выпускать полусырые программы. Довести программу до ума — что среди прочего означает, чтобы близорукий испанец, говорящий на каталонском, мог легко использовать любую функцию, не опасаясь создать дефект в системе безопасности — весьма недешево! Но мы должны довести ее до ума, потому что при поставке новой версии сценарного ядра сотни миллионов людей будут использовать этот код, а десятки миллионов будут для него программировать. Любая новая возможность, не удовлетворяющая потребностей широкого круга пользователей, фактически крадет ценные ресурсы, которые могли бы быть по
трачены на реализацию функций, исправление ошибок или поиск дефектов безопасности, влияющих на жизнь миллионов людей.

и это реальная ж…. - от себя =)))

PS: Какой склад сейчас обходится без погрузчиков? Правильно, никакой! СоюзКомплектАвтоТранс занимается продажа погрузчиков и поставляет навесное оборудование погрузчик. Выгодные цены и качественный сервис гарантированы!