Предварительные соображения о лексиконе программирования

Академик А.П. Ершов, 1983 г.

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

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

Эти 200 тыс. профессионалов пишут в год порядка 1 млрд. машинных команд. Скорее всего процентов 90 из них – это разовые программы или, во всяком случае, программы, не выходящие за пределы первичного коллектива, в котором возникла задача на программирование. Порядка 100 млн. команд – это годовой выход программного продукта, который в той или иной форме отчуждается от его изготовителей.

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

Если считать, что одна модификация затрагивает порядка десяти команд текста программы, а также принять во внимание, что исправление программы обходится примерно на порядок дороже, чем составление новой, получим, что сопровождение и доработка 100 млн.команд годичного программного продукта эквивалентны разработке 50 млн.команд новых программ. Этот объем доработок уже сам по себе является тяжким бременем, однако это лишь малая часть тех потерь, которые возникают от нарушений режимов использования вычислительных средств, вызванных ошибками программного обеспечения. Эти потери очень трудно учесть, но некоторое представление дает следующий расчет. Будем считать, что одна программа применяется в среднем в 1000 экземпляров, ошибки проявляются лишь в десятой части тиража и производственный сбой, вызванный одной ошибкой в программе, обходится предприятию в скромную цифру 100 руб. Уже эта осторожная оценка дает

100 × 0,1 × 1000 × 100 000 = 1 млрд.руб. в год.

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

  • языке ассемблера 25 %
  • Фортране 30 %
  • Коболе 15 %
  • ПЛ/1 15 %
  • Алголе 10 %
  • Остальных 5 %
  • Итого 100 %

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

Существующие правила оформления и приемки программного продукта при всей их кажущейся строгости носят поверхностный характер, не затрагивающий существа продукта, и постоянно выхолащиваются формальными требованиями соблюдения плановых сроков и разнонаправленностью интересов разработчиков и хранителей фондов алгоритмов и программ. Рассмотрим теперь базу знаний профессиональных программистов. Добрых две трети указанных 200 тыс. специалистов были выпущены вузами по специальности «Прикладная математика» и ряду специальностей, ей родственных, в десятилетие с 1968 по 1977 г. Чему их учили, дает представление учебный план Минвуза СССР по указанным специальностям и отечественные наиболее массовые учебные пособия по программированию и практикуму на ЭВМ, выпущенные в 70-х гг. Не подвергая сомнению ни добросовестность авторов, ни необходимость обучения тем начальным сведениям по программированию, которые содержатся в этих книгах, следует все же признать, что то, чему учат сейчас в вузе, с позиций современной науки не выходит за пределы элементарной "компьютерной грамотности". Программированию как научно обоснованному методу составления программ не учат даже сейчас, не говоря уж о содержании образования в указанный период времени.

Конечно, каждый, кто захочет опротестовать нарисованную картину, найдет немало свидетельств противоположному.

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

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

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

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

Все наши рассуждения мы ведем для того, чтобы обосновать какие-то перемены в статус-кво. Взяв год на раскачку, будем все относить к периоду с 1986 по 2005 г. Итак, общий тираж программного продукта должен к 2005 г. вырасти в сто раз. Один порядок роста можно отнести за счет увеличения тиражности. Отсюда получаем контрольную цифру минимального объема программного продукта к 2005 г. в 1 млрд.команд. Рассчитывать более чем на двукратное увеличение числа профессиональных программистов, учитывая демографическую ситуацию, не приходится; отсюда получаем задание на пятикратный рост производительности труда. Но этого мало. Стократное увеличение "контактной поверхности" программного продукта при существующем уровне надежности доводит стоимость издержек из-за ошибок в программах до 100 млрд. руб. Это значит, что надежность программного обеспечения должна быть по крайней мере на два порядка выше. Другими словами, число ошибок должно быть в десять раз меньше так же, как и число авостов, случающихся в программах. Наконец, соотношение стоимости разработки к стоимости сопровождения должно быть не порядка 2 : 1 на первый год эксплуатации, а ближе к 10 : 1.

Итак, мы получаем следующую задачу, стоящую перед программированием на ближайшие двадцать лет: при умеренном росте (в 2–3 раза) числа профессиональных программистов не менее чем в пять раз повысить их производительность; повысить надежность программного продукта не менее чем на два порядка и примерно на столько же сократить удельные затраты на сопровождение. Будет полезно сравнить нашу исходную точку отсчета с состоянием двадцатилетней давности (с 1965 г.). Понятие программного продукта еще только складывалось, но ретроспективная переформулировка нашей деятельности в то время может быть выражена следующим образом.

  • Языки: машинный – 30 %
  • ассемблера – 30 %
  • Алгол – 30 %
  • остальные – 10 %

Число программистов – на порядок меньше, производительность – в пять раз меньше, примерно 1000 команд в год, надежность – на порядок ниже, затраты на сопровождение, грубо говоря, равнялись затратам на разработку, тиражность программ была на порядок-полтора ниже. Коротко проанализируем факторы перемен за истекшие двадцать лет. Рост производительности – наполовину за счет исключения восьмеричного программирования, наполовину за счет сервиса операционной системы. Рост надежности – наполовину за счет повышения уровня языка, наполовину за счет появления организационной дисциплины программирования. Динамику затрат на сопровождение можно интерпретировать как стабилизацию двух тенденций: позитивной – организационного выделения функции сопровождения и улучшения документирования программ, и негативной – роста затрат на сопровождение из-за увеличения тиражности при невысокой надежности. По кадрам ситуация тоже двунаправленная. Позитивная – усиление профессионального начала через специализацию "математическое обеспечение ЭВМ" и увеличение числа программистов, и негативная – некоторое понижение среднего иителлектуального уровня программиста. Аналогичная ситуация и в преподавании: усиление педагогически мотивированных программ и методов обучения, с одной стороны, и ослабление творческого, передового начала в учебном материале, с другой стороны.

В целом, если сравнить развитие программирования в первое десятилетие (1955–1964) и второе десятилетие (1965–1984), то оно будет явно не в пользу второго из-за определенной утраты темпа и глубины развития.

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

Рассмотрим существующие регуляторы программирования:

  • общий язык;
  • интерактивные средства построения программ;
  • организационную дисциплину программирования;
  • методологию построения программ.

Каждый из этих регуляторов заслуживает детального рассмотрения. Мы вынуждены провести анализ очень схематично.

Мечта об общем идеальном или, лучше сказать, априорном языке до сих пор не оставляет программистов. Главные вехи развития этой мечты: Алгол-60, Кобол, ПЛ/1, Алгол-68 и, наконец, Ада. Каждый из этих языков, а также многие другие становились заметными явлениями в эволюции программирования, но в целом они лишь повысили разнообразие языковой практики программирования. Пожалуй, только Фортран и Бейсик реально сдерживают напор "вавилонского столпотворения", но это ни у кого не вызывает удовлетворения.

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

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

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

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

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

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

Мы различаем три формы программирования:

  • синтезирующее;
  • сборочное;
  • конкретизирующее.

Синтезирующее программирование – это программирование в его наиболее натуральной сущности. Оно начинается с задачи и завершается программой ее решения на основе заданных элементарных средств.

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

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

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

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

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

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

Сборочное программирование: методы и техника модульного программирования на основе понятия абстрактного типа данных.

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

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

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

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

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

Не надо думать, что лексикон – это все и навсегда. Это тщательно отобранная, но развивающаяся система удачных обозначений. Степень его успеха определяется степенью общезначимости и общепонятности его нотации.

Давайте вообразим, как выглядит программирование в лексиконе. Синтезирующее программирование проходит полностью в лексиконе вплоть до получения алгоритма нужной степени детализации. Если это заготовка (модуль или универсальный алгоритм), то она в таком виде и остается. Если программа должна быть передана машине, то она подвергается особой процедуре "лингвизации" (фортранизации, паскализации, алголизации и т.п.). Лингвизация – это перековка программы, которая, сохраняя правильность, придает ей стилистические особенности рабочего алгоритмического языка, после чего прямая транслитерация превращает программу в текст на этом языке, который исполняется или пополняет рабочую библиотеку. Лингвизация может быть творческим процессом, выполняемым специалистом по данному рабочему языку. Творчество, однако, состоит не в сохранении правильности программы (она гарантированно сохраняется), а в придании программе особого шика, наиболее идущего этому рабочему языку.

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

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

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

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

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

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

Недавняя книга Д. Гриса "Наука программировать" (М.: Мир, 1984) является блестящим педагогическим свидетельством возможности учить доказательному программированию.

"Язык широкого спектра", созданный в проекте ЦИП под руководством проф. Ф. Л. Бауэра, является развернутой номенклатурой лексикона. Эта концепция, хотя и не названная явно, пронизывает его новый курс программирования, написанный вместе с Г. Весснером: "Алгоритмический язык и построение программ" (Шпрингер, 1983).

Язык PDL и поддерживаемая им технология построения программ, созданная в Отделении федеральных систем компании ИБМ, является явным шагом в сторону программировании на лексиконе с элементами доказательности.

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

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

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

Разработка лексикона, создание на его основе руководства программиста, свода фундаментальных алгоритмов, написание учебников – прекрасная основа для международного сотрудничества, активизации научной работы на местах, создания мощного "когерентного излучения" новых идей и формирования базы знания современного программирования.

Возвращаясь к задаче развития программирования в СССР на ближайшие двадцать лет, можно разбить эти годы на два десятилетия.

До 1992 г. можно рассчитывать на повсеместное внедрение терминальной интерактивной разработки программ, переход на более современные рабочие языки, укрепление организационной дисциплины программирования. Эти программные обстановки 1-го поколения позволяют, грубо говоря, сделать полдела при условии умеренного роста тиражности программирования. Следующий этап – выйти на доказательное программирование и придать производственный характер сборочному и конкретизирующему программированию.

Это означает, что к началу второго десятилетия основы лексикона должны быть построены и выработана педагогическая доктрина.

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

Другие статьи автора

Комментарии

Программирование без доказательств

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

Изображение пользователя ipanshin.

ха

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

ЗА ЧТО БОРОЛИСЬ

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

Изображение пользователя ipanshin.

добились

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

Я готов поздравить, как человек, Вас с очередной победой над американцами и европейцами. Но о чем мы говорим здесь и сейчас?

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

20 ЛЕТ СПУСТЯ

25 ЛЕТ НАЗАД никто у нас не знал - что такое "информатика"? и что такое "компьютерная грамотность"? Из-за разногласий с А.Ершовым пришлось писать свой вариант учебника "Информатика", который начинался с рассказов о персональных компьютеров и обучения компьютерной грамотности, а завершался обучению технике решения задач на ЭВМ с доказательством правильности решений. Наш учебник переиздавался более 10 раз и его можно найти в Интернет, библиотеках и книжных магазинах.
Самым сложным было добиться, чтобы во всех школах появились компьютеры и Интернет, при этом сменилось четыре правительства и три поколения персональных ЭВМ, президент страны стал поздравлять наших студентов-программистов - победителей чемпионатов мира по программированию.
А ведь еще десять лет назад горе-специалисты говорили, что мы отстали от Америки и американцев навсегда. Фиг-Вам - лучшие американские студенты-программисты - все родом из Китая. Если Медведев до конца доведет программу развития отечественного открытого программного обеспечения, которую он финансово поддержал в ровно год назад, россия станет конкурентно-способной компьютерной державой. Денежки только куда-то подевались вместе с Леней Рейманом.А та опять ищи Фиг-ВАМ.

Изображение пользователя ipanshin.

25 ЛЕТ НАЗАД

Это 1983. Вот и неправда. Уже в 1974 году я изучал в советской России правила построения трансляторов. А учились мы по Грису. И готовили нас как системных программистов. И называлась кафедра МО ЭВМ (математического обеспечения и применения ЭВМ) и, если я подниму диплом, то в выписке будет информатика, как дисциплина. А машина называлась Проминь, и руская тоже была БЭСМ-6б и болгарская Одраб и аналоговая МН-7.

Какие три поколения персональных ЭВМ? Вся теория была разработана программистами еще раньше на базе IBM 360 (аналог EC 1022, 1033), далее миниЭВМ (аналог PDP-11 /34 /79), далее микроЭВМ с операционкой CP/M (дальше она стала MS DOS). Кстати корни свободного обеспечения именно здесь и Юникса тоже здесь. Он разрабатывался одновременно с операционкой RSX11M,Rafos,MUMPS. Свободное программное обеспечение было создано на основе открытого сообщества программистов DECUS (DEC Users Society). Кстати одной из идей там был современный excel, который Майкрософт уже много лет эксплуатирует. А также псевдотерминальный драйвер, обеспечивающий перехват сигналов клавиатуры. Да и прочие идеи, которые собирались совершенно бесплатно всеми программистами. А теперь кто-то хочет это забыть? Я сам был участником этого сообщества и гдето на чердаке хранятся все труды этого сообщества на магнитной ленте TK-50. Если, конечно она еще читается.

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

ДАВНЯЯ ИСТОРИЯ

вам ПОВЕЗЛО - У ВАС в дипломе от 1979 года написано "ИНФОРМАТИКА". МНЕ не повезло А.Ершов показал мне рукопись первого учебника по информатике в январе 1985г.В рукописи Ершова цикл Дейкстры "do-od" был замещен на сокращение "цк-кц" по русски звучало как "ЦК" и "Конец-ЦК". Из-за политкорректности Ершов это сокращения изъял из учебника и появилась пара "нц-кц".ЕС ЭВМ и СМ ЭВМ в первом отечественном учебнике информатике и все соответствующее ПО отсутствовали. А вскоре ЕС ЭВМ и СМ ЭВМ оказались на помойке вместе со всеми магнитными бобинами для этих машин. Нам всем пришлось изучать эту технику. В учебниках информатики остались только инвариантные вещи и понятия, которые сохранили свое значение даже после полной смены оборудования и системного программного обеспечения.

Требовалось доказать

ТРЕБОВАЛОСЬ ДОКАЗАТЬ

Дискуссия на тему "доказательное программирование" возникла в80-=годах ХХ века и будет продолжаться достаточно долго.
Многие "авторитеты" от программирования (Шура-Бура и Терехов)зарабатывающих на продажах soft'а, прямо заявляют, что импотрный soft без ошибок и bag's не бывает.
Ученые от программирования (Дейкстра, Ершов, Каймин, Наур), разрабатывающие технику анализа и построения алгоритмов и программ с доказательствами правильности, продемонстрировали большое число примеров, монографий и учебников ДОКАЗАТЕЛЬНОГО ПРОГРАММИРОВАНИЯ.
ЧИСЛО примеров, монографий и учебников будет множиться, а число учеников будет увеличиваться.
Первая попытка изложить концепцию доказательного программирования в форме учебного пособия была предпринята в 1986 году в форме учебника по информатике.
Педагогически было важно начать изучение основ программирования с основ анализа и доказательства правильности программ. Каждая программма завершалась текстом анализа и доказательства правильности, Это совсем другой взгляд на информатику, программирование и математику. Откройте наши учебники по информатики - все программы излагаются с доказательствами правильности - другая речь, другое изложение.
И каждый пример завершается фразой - "что и требовалось доказать".
В.А. Каймин, проф., док.наук.

Изображение пользователя ipanshin.

что и требовалось доказать

Вопрос, а кто требовал доказывать? Это необходимое, но вовсе не достаточное условие. Или может быть утверждений "что и требовалось доказать" было два? для необходимости и достаточности? Вспомним Льюиса Кэррола. Что было в нем первичным его математический склад ума или художественный талант как писателя? Утвеждаю, что второе. Так же и писать программы может любой, но жить программа будет тогда, когда в ней появится чувство, а не доказательная основа ее работы. Я в институте аналитического приборостроения работал со Стародубцевым, который болел идеей создания самопроверяющихся электронных схем. Если эту идею прикрутить к программе, то мы получим некую обратную цепь, доказывающую правильность работы, но избыточность кода возрастет вовсе не линейно.

Уж больно мне все это напоминает педагогику. Раз мы не умеем писать, то будем учить как надо писать.

МАТЕМАТИЧЕСКАЯ ТЕХНИКА ДОКАЗАТЕЛЬСТВ

УМЕНИЯ писать программы - не есть первичное. ПЕРВИЧНЫМ должно стать умения писать программы с доказательством правильности. ЭТИ УМЕНИЯ опираются на аппарат математической логики и этим аппаратом нужно овладеть досконально и при написании программ и при написании текстов доказательств. Книги и учебники я сам лично начал писать параллельно с освоением техники доказательного программирования. Одновременно научился писать анекдоты и рассказы, которые нравятся женщинам, но нельзя публиковать.
Но нужный математический аппарат находится не в исчислении высказываний, а в исчислении предикатов. Боюсь, что Льюис Кэролл исчислением предикатов не овладел.

Изображение пользователя ipanshin.

научился писать анекдоты и рассказы

Опять извечный вопрос? Что первично? Яйцо или курица? Палка имеет два конца или два начала? Мы говорим об ошибках семантических или синтаксических? Так вот первые - это та точка опоры, которую искал Архимед, чтобы сдвинуть наш шарик. А вторые успешно находятся любым дебаггером, который есть под рукой.
Вот. Давайте начнем с конца.
Мой лично придуманный анекдот:

Чем отличается жена от вентилятора?
Вентилятор греется и дует, а жена дуется и греет.

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

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

МОНТАЖ ПРОГРАММ С ДОКАЗАТЕЛЬСТВАМИ

ПОСТРОЕНИЕ текстов программ с доказательством правильности Эдсгар Дейкстра называл "логическими поэмами", поскольку это более подбор рамок с заданным содержанием.Любимый пример - обобщение проблем "любовных треугольников" до "любовных тетраэдров" либо "любовных параллелогрраммов". Далее нужен человек с хорошей фантазией.
Доказательства правильности структурированных алгоритмов и программ имеют некоторые общие схемы и конструкции как в алгоритмическом, так и логическом плане. При этом слово "ритм" имеет глубокие связи со словами "алгоритмы", а композиция доказательств во многом индуцируется структурой алгоритмов.
Примеры взаимосвязей структур алгоритмов и структур доказательств Вы найдете много в книге Дейкстры "Дисциплина программирования" и в учебниках информатики с примерами доказательств правильности программ.Завершение доказательств словами "что и требовалось доказать" дает неизмеримое эстетическое удовольствие.

Изображение пользователя ipanshin.

Далее нужен человек с хорошей фантазией.

Нет, здесь нужен только врач. Вы взяли не очень верную предметную область. Например так. Пусть (e1,...,en) есть N мерный базис на который натянуто некоторое векторное пространство R bla-bla-bla ...
Тогда еще можно что-то доказать мне. Я же не женщина, да и как мужчина не склонен пускать слюни от любовного тетраэдра. А так получается какая-то порнография. Тогда уж лучше читать Ф.Энгельса "Происхождение семьи, частной собственности и государства".

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

Давайте по полочкам:
Вы хотите доказать свое утверждение(см.выше)
1. Ваше доказательство необходимости.
2. Ваше доказательство достаточности.

Лучше, если это будет с привлечением мат.аппарата, а не в любовных терминах. В любовные я и сам мастер переводить.

Зимний треугольник

Подчеркиваешь седину волос,
Подчеркивая выпрямляешь спину,
Как буд-то задаешь вопрос
И точно знаешь,
Что в ответ я кину...

И в отношеньях не страшит мороз,
Бесстрастность вьюги глаз - я просто стыну,
И тот губительный износ
Ты принимаешь также,
Как его причину.

Ты замечаешь: третьего уж не дано,
Из трех вершин – одной лишился,
Потом из двух останется одно,
И, Слава Богу,
круг твой завершился.