Век галантности проходит. Ему на смену приходит
век софистов, экономистов и вычислителей; Слава
Европы исчезнет навсегда.
Э.Бек (Англия, 1792)

Зачем?

Прожив не короткую жизнь программиста спрашиваю себя: “Было ли в ней чего интересного от программирования и если да, то, что больше всего поразило и осталось в памяти?”. В зависимости от литературного таланта ответ мог бы вылиться в роман, философский трактат, поэму, анекдот. С талантом Чехова можно было бы написать целую серию рассказов о серой/яркой жизни обыкновенных программистов, которым виртуальная жизнь убивает/рождает реальную. Но где он Чехов-программист?

В меру своих способностей ограничусь очерком-смесью в стиле «диванной медитации». И хотя основному тексту уже много лет я все-таки рискну…

Место действия — Минск.

Как я стал программистом

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

Программирование начиналось курсом ССК – Системой Символического Кодирования для машины Минск-32. И в начале был какой-то загадочный регистр базы. Много позже я неплохо программировал на ассемблере, но представьте себе человека, ничего не знающего о программировании и который начал учить программирование с Ассемблера, причем не по учебнику, а по какому-то техническому описанию. После стройной системы физики это был какой-то бред (Я подозреваю, что это был и в самом деле бред). Душа физика с этим предметом смириться не могла. А тут еще навалились житейские трудности и я почти не ходил на занятия. В общем, ССК я не знал абсолютно. Но вот пришла пора сдавать экзамен. До этого экзамена все пять лет я честно хорошо готовился к экзамену. А что делать сейчас? И тут я встречаю знакомого по сибирской шабашке (Он мне запомнился своим веселым нравом и, что все трое суток нашего путешествия в Сибирь, день и ночь упоенно рассказывал анекдоты). Поделился с ним горем за кружкой пива. Решение нашли быстро и смело – он сдает за меня экзамен за бутылку водки (дело облегчалось отсутствием зачеток). Все прошло на O’key.

Попытка оправдаться. «Не я один тому виной». Виноваты и преподаватели. Качество преподавания во многом было отвратительным. Один преподаватель, как преимущество ЭВМ Минск-32 над IBM c системой OS/360 указывал на то, что IBM работает только с 8 битами (байт), а Минск-32 в четыре раза больше – 32(слово). И, вроде бы, отсюда следовало, что Минск-32 в четыре раза лучше компьютеров IBM. Оказалось, что это относилось только к адресации. Это все меняло с точностью до наоборот.

Впрочем, описанная ситуация была характерна не только для программирования. На четвертом курсе физфака БГУ целый год преподавалась дисциплина “Квантовая теория поля”. И за целый год мы ничего не услышали о ней, а излагались нам собственные результаты преподавателя-академика, относящиеся к его оригинальной параметризации группы Лоренца. Может это и важно, но где же квантовая теория поля основной аппарат фундаментальной физики? Кстати, любую группу можно, как мне кажется, параметризовать бесконечным числом способов и каждый из них будет обладать некоторыми достоинствами. Представляете сколько можно написать диссертаций! В связи с тем, что сейчас в республике Беларусь несколько университетов, я в еще большем сомнении о качестве их образования. Если преподавателей не хватало на один, то откуда их наскребли на несколько – неясно. С “качеством” спецов пришлось встречаться и позднее. Например, в НПО Агат. Один доктор наук повышал так нашу квалификацию: он, предполагая, что “… вектор a больше вектора b…” делал большие выводы. Но ведь векторы неупорядочены: никто не определял для них отношение больше/меньше. Второй неявно пользовался неверным соотношением “сумма произведений равна произведению суммы: $\$inline\$?\_i?\_ja(i,j)\; =?\_j?\_ia(i,j)\$inline\$$. Из этого он получил массу следствий. И хотя он и признал ошибку, следствия, почему-то, считал правильными(“это мне нужно, поэтому это правильно”). А следующий случай вообще паталогический. Радиотехник рассматривал электрический вектор электромагнитного поля. Он, вообще говоря, вращается. Вспоминая механику Ньютона, радиотехник ввел центробежную силу, действующую на конец вектора электрического поля и развил отсюда целую теорию, опровергая какого-то Гоноровского – видимо авторитета в области радиотехники.

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

Продолжение. Но жизнь мстит нам за уловки. Я распределился в институт физики и начал напрягаться в области аксиоматической квантовой теории поля (Ух ты!). Но скоро понял, что, получая на руки 86р и отдавая 30 из них за квартиру, аксиоматическая квантовая теория поля не очень то поддается, а все больше встает проблема “Как жить?”. Вывод: “Так жить нельзя”. Кстати, мой одноклассник троечник, работая на Интеграле наладчиком, получал в три раза больше чем я c красным дипломом БГУ. Так как же жить дальше? И вот опять помогает кружка пива. На встрече с подружками я знакомлюсь с постановщиком из ЦНИИТУ — при дамах наши мужики беседуют ведь о работе. И вот он мне рассказывает, чем занимается и мне начинает казаться, что я могу быть неплохим постановщиком задач. Ведь ставить задачи это не решать их, – не правда ли? И вот я в ЦНИИТУ. Хотя, увы, не постановщиком, а начинающим программистом. Ну а как же “высокая” физика? Я утешил себя, что буду заниматься “высоким” программированием – всякого рода научными расчетами. Главное – подальше от всяких дебетов и кредитов бухучета. Бухгалтерия и банки были символом занудства и хотелось от них держаться подальше. Но жизнь упрямо тычет наш снобизм в реалии. И реально именно дебетом и кредитом пришлось впоследствии и заняться. Вот такая эволюция от кварков к программированию бухучета. Да, именно бухучет и пришлось программировать. Ведь “социализм – это учет и контроль “. Ну, а так как место контроля было уже занято (у нас все контролировала партия), то пришлось заняться учетом.

Мораль. Мы не любим только те науки, которых не понимаем. Нужно видеть фундамент, Уважение к предмету приходит с пониманием основ, если это, конечно, Основы.

Что такое программирование и главная проблема математики

Есть такого рода занудство – спрашивать “Что такое программирование?”, “Что такое физика?”, “Что такое математика?”. Точного ответа, на такого рода вопросы, быть не может. Природа не делит мир на физику, химию,… Поэтому границы между науками условны. Их поставила не природа, а люди. Кстати, кажется, Энгельс сказал, что, в конце концов, будет две науки – физика и психология (материя и сознание). Один физик, разозлившись, на вопрос “Так что же такое физика?” ответил так: «Физика – это то, чем занимаются физики”. И это совершенно серьезно.

Тогда чем же занимаются программисты? В чем суть их занятий? Как мне представляется, главное занятие программиста — большую нерешенную проблему представить как композицию маленьких решенных. Эта композиция есть путь от постановки к решению. Записанный на заданном формальном языке этот путь называется программой. Тогда композиция должна быть текстом на заданном формальном языке – это и есть программа. Формально-текстуальным воплощением алгоритма программирование и отличается от других конструктивных дисциплин. Итак, две особенности программирования: 1) Предельная конструктивность 2) Жесткие синтаксические рамки.

Раз программирование есть конструктивная дисциплина, то для него не столько интересно есть ли решение, а само решение. В математике полно теорем существования, которые утверждают, что есть решение, но ничего не говорят о том, как его найти. Физик-нобелист Ландау предлагал вообще изгнать из курса математики для физиков всякое упоминание о теоремах существования. Что толку для физика знать, что дифференциальное уравнение имеет решение. Нужно знать решение, а не то, что оно есть. Как раз на тему “есть ли решение?” о Ландау есть такая интересная история. Когда физики ехали куда-нибудь на тусовку, то по дороге развлекались тем, что, наблюдая за четырехзначным номером впереди идущей машины нужно было как можно быстрее уловить закономерность в номере, пользуясь только элементарными(школьными действиями) не переставляя цифр и используя их только по разу. Например, для номера 73-85 имеем 7-3=8-5, для номера 38-53 имеем $$. Ландау был большой авторитет в этом деле. Возник вопрос для любого ли номера можно найти закономерность – это и есть вопрос о теореме существования. Ландау ответил, — “Нет, не для любого”. – “Почему, неужели вы, Ландау, доказали теорему несуществования!?” – “Ну нет, просто потому, что, я, Ландау, не для всякого номера нашел эту закономерность. Например, для номера 75-65”. Гениально. Но один из молодых математиков совершенно серьезно подошел к теореме существования и доказал, что любое целое число можно “приравнять” другому, так как существует формула сведения N+1 к N: $$
Увы, после доказательства теоремы существования игра потеряла остроту. Вот оно: “Чем больше знания, тем больше печали”.

В конструктивном решении выделяются две стадии:

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

Примеры частных конструктивных задач

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

Вот они классические задачи на построение:

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

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

Вот тут то, подход “к черту теоремы существования – давайте сразу решение” и дает осечку. Предполагая, что решение есть, его искали много веков. А оказалось, что решения то и нет.

Над этими задачами бились многие математики и дилетанты (и я в детстве предложил свое решение квадратуры круга, которое оказалось приближенным с точностью примерно 10% — но это уже выяснилось в юности). Предлагалось масса решений, но все они оказывались приблизительными. В 19-м веке было доказано, что задачи не имеют решения. Для трисекции угла это можно показать теперь и школьнику(См. например книгу Куранта и Роббинса “Что такое математика”), а для квадратуры круга – студенту. Причем дело обстоит так, что можно найти приближение сколь угодно точное, но точного решения быть не может. Результат, если вдуматься, странный. Как будто перед искомым квадратом стоит как бы стена, которую нельзя преодолеть. Но стоит разрешить еще и другие операции, как решение становится элементарным. Это сделал еще Архимед в отношении трисекции угла.

Формализация понятия алгоритма

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

Было предложено несколько формулировок онаучивания понятия алгоритма(или по-научному — экспликации): рекурсивные функции, алфавитные подстановки Маркова, машина Поста, машина Тьюринга. Постепенно была доказана эквивалентность этих формулировок. В конце концов, математики приняли за аксиому, что указанные формулировки адекватны понятию алгоритма – это тезис Черча. Машина Тьюринга по своим терминам приближается к реальным вычислительным машинам. Ее элементарно смоделировать, но эти модели не нужны в силу своей примитивности и, следовательно, медленности. Но как теоретический аппарат он незаменим. Например, удалось формализовать понятие алгоритмической сложности. И тут опять всплыли удивительные вещи. Так интуиция программиста говорит о том, что умножение сложнее чем умножение. Умножить число a на число n — это значит выполнить n сложений. Так что кажется умножение в несколько раз сложнее. А что дает теория?

Пусть есть два n-разрядных числа и машина Тьюринга выполняет их умножение за U(n), а сложение за S(n). Тогда интуиция говорит о том, что U(n))/(S(n)>?. Но теоретический анализ показал, что для любого сколь угодно малого ? имеем $\$inline\$U(n))/[S(n)(S(n))^?]\; >0\$inline\$$. А это и говорит о том, что ближе чем умножение к сложению уже и нет ничего — они по сложности рядом.

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

Схожую ситуацию имеем в Великой теореме Ферма: уравнение $$ не имеет решения в целых числах при n>2.

Этому утверждению можно придать такой характер, что хочется сказать «Этого не может быть».
Разделив на правую часть, перейдем к рациональным числам: уравнение $$ не имеет решения в рациональных числах <>0.

Далее ограничимся только четными n. Для них имеем картинку:



На рисунке изображены кривые Ферма для n=2 (окружность) и n=бесконечность (квадрат). Все остальные кривые при n=2k>2 лежат между окружностью и квадратом и при увеличении n они все плотнее приближаются к квадрату. И, если взять все такие кривые, то они будут все плотнее заполнять пространство около квадрата. И там лежит бесконечно много точек с рациональными координатами так, что если все рациональные точки окрасить в темный цвет, то все пространство квадрата будет черным — множество точек с рациональными координатами всюду плотно. И, тем не менее, ни одна из кривых Ферма не проходит через рациональные точки. Казалось бы, что для этого нужно безумно петлять. Однако теорема Ферма говорит, что совершенно гладкая кривая не проходит ни через одну рациональную точку. Ну, невозможно поверить. Что-то тут не так.
Похожая ситуация обстоит и во всей математике. Хорошо бы к математическим задачам и подойти математически. Например, представить нахождение решения математической задачи «Если A, то B» как движение в некотором пространстве математических объектов от исходных данных к требуемым. Вот пример конструктивного пути от A к B:



При движении по пути используются только аксиомы арифметики.

Вот бы для любой теоремы “Если A, то B”, можно было бы построить конструктивными методами траекторию, ведущую от A к B. Это был бы триумф математики. Можно ли это сделать? Существует ли такая траектория?

Великий математик Гильберт (многими считается самым великим в 20-м веке) с энтузиазмом приступил к реализации программы Лейбница – формализовать, алгоритмизовать любую математическую проблему. Эта программа получила название формализации математики – под всю математику подвести аксиоматический базис, все математические проблемы выразить на формальном языке как следствия аксиом и все теоремы выводить по правилам математической логики. Была проделана огромная работа по полной формализации математики. Желающие могут посмотреть два толстых тома «Основания математики» Гильберта и Бернайса. Но в самый разгар работы появились работы Курта Геделя, который, кроме всего прочего, доказал, что в любой формальной теории, содержащей арифметику можно высказать осмысленную теорему, которая будет невыводима. И ее, (или, с не меньшим основанием, ее отрицание) можно взять за новую аксиому. Обращаем внимание на слово «формальная». Для неформальной теории можно всегда сказать что-то вроде «очевидно что...» и всякие преграды будут сняты. Поэтому всякие приложения теоремы Геделя к неформальным теориям некорректны. Особенно это относится к философии, которая любит порассуждать на эту тему.

Итак, ФОРМАЛЬНАЯ МАТЕМАТИКА СУЩЕСТВЕННО НЕПОЛНА И НИКОГДА ПОЛНОЙ НЕ БУДЕТ. Это роднит ее с физикой, которая никогда на формализацию и не претендовала в силу своего естественного положения (и более того дух формализации чужд физику, который привык что все аксиомы временны).

Казалось бы можно выйти из положения, взяв невыводимую теорему(или ее отрицание) за аксиому, добавить ее к первоначальной системе аксиом и уже из этой расширенной формальной системы выводить следствия-теоремы. Но ведь теорема Геделя применима и к этой расширенной формальной системе. Получаем бесконечный процесс. Только в бесконечной системе, можно найти универсальность. Но вот как работать с бесконечным набором аксиом? Дело осложняется еще и тем, что самая безобидная аксиома может дать совершенно неожиданные следствия. К примеру, возьмем аксиому выбора: если задана совокупность непересекающихся множеств, то из каждого множества можно выбрать по одному элементу и собрать их в множество. Казалось бы о чем тут можно спорить. Но, используя аксиому выбора, Банах и Тарский доказали, что две сферы S1 и S2 различных радиусов можно разбить на одно и то же конечное число попарно непересекающихся множеств:

S1=A1+A2+…+An и S2=B1+B2+…Bn

так что для всех i: Ai= Bi. Итак, неодинаковые сферы разбили на одинаковые части. Что за чушь? Но все логично Чему верить, что отвергать? Складывая по одному, получаем одну сферу, а по другому – большую.

Джон фон Нейман с помощью аксиомы выбора доказал, что отрезок A прямой при конечном разбиении меньше отрезка B прямой, имеющего меньшую чем он длину. Вот и верь после этого математике. Если принять безобидную аксиому выбора(а что может быть более очевидным чем то, что из первого класса можно выбрать одного ученика, из второго одного ученика и т.д.), то получаются совершенно парадоксальные следствия.

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

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

Возвращаясь к теореме Геделя заметим, что язык программирования есть формальная система. Значит можно написать программу, для которой не существует программы, доказывающей ее правильность или неправильность. Неужели это так? Написанную программу или ее отрицание можно взять за аксиому программирования.

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



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



Ба! — А ведь это программа на Prologe. Сам Prolog выступает в качестве вышеозначенной параметрической функции. Описание предметной области — текст на Prologe, кодирующий предметную область. Цель — параметр.

Я был приятно поражен когда попытался реализовать на Prologе задачи поиска на множестве отношений. Этот поиск был реализован сначала на Delphi, а потом на C#. Так вот то, что реализовывалось несколькими немаленькими программами на Delphi(C#), на Prologe уложилось в компактное описание отношений и функций на них. А потом к этому описанию можно было запрашивать разнообразные целевые запросы. Правда, ничего не смогу сказать о сравнительной производительности. Но на нескольких конкретных примерах я не заметил существенной разницы. Однако Delphi еще рисовало красивые графы целевых отношений. Этого я не делал на Prologe. Но ведь каждому свое. Логику должен реализовывать логический язык, презентации — презентационный язык, отчеты — язык отчетов, ввод — язык ввода, коммуникации — язык коммуникаций, взаимодействие сервисов — язык распределения, взаимодействия и оркестровки сервисов.

Классика

Старые классики

“Классиков нужно знать и чтить”. Не нужно думать, что все изобретено в наш век. “Ничто не ново под луной”. Это справедливо и в отношении программирования и его основных понятий. Кстати, сам термин “алгоритм” корнями имеет еще девятый век и происходит от имени математика аль-Хорезми. Алгоритмичны многие построения Эвклида. Так до сих пор жив его алгоритм нахождения наибольшего общего делителя. Луллий(его камнями забросали мусульмане – это к “прогрессивной” роли религии) в 13-м веке приходит к идее логической машины, оперирующей символами. В рукописях Леонардо да Винчи найдены чертежи тринадцатиразрядного вычислительного устройства. (Впрочем, в его рукописях найдено всего столько, что некоторые исследователь всерьез заявляют, что Да Винчи был не человек, а пришелец.)

В 1623 г. Шиккард, профессор языков(!!) Тюрингского университета спроектировал вычислитель. Великий Паскаль имел четкую идею механической вычислительной машины и построил механические арифмометры. Великий Лейбниц выдвинул идею арифметизации высказываний с тем, чтобы разрешение спора свести к вычислению ”Что спорить – сядем и посчитаем кто прав”!!.. “Недостойно одаренному человеку тратить подобно рабу часы на вычисления, которые, безусловно, можно было бы доверить любому лицу, если бы при этом применить машину” сказал Лейбниц и изготовил вычислительную машину и мечтал об универсальной машине, которая бы могла вычислять все.

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

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

Если следовать современной терминологией – Бэббедж “физик”. Музыку не любил. На опере придумал цветомузыку. По поводу стихов Теннисона

“Каждую минуту умирает человек,
Но каждую минуту человек рождается”

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

Каждое мгновение умирает человек,
Но 1,16 человека рождается…

Я могу сообщить Вам и более точную цифру – 1.167, но это, конечно, должно нарушить ритм стиха…”

Несмотря на это (а, может, благодаря этому) Бэббедж намеревался заняться исследованием природы юмора. Он типичный генератор идей. Из-за избытка идей не доводил до полного завершения свои многочисленные предложения и проекты. Изобрел спидометр, создал поперечно-строгальный и токарно-револьверный станки, прессформы, резцы, предложил способ гравировки по дереву. В общем, это английский Леонардо да Винчи. В 1832 году написал книгу “Экономика машин и производства”, в которой предвосхитил системный анализ, исследование операций, научную организацию труда. Эту книгу хорошо знал Маркс и цитировал ее в “Капитале”, о ней с восхищением говорил Кейнс. Но самое важное изобретение – аналитическая машина, являющаяся универсальным программируемым механическим компьютером. Государственных денег не хватало и Бэббедж тратит свои деньги на постройку машины. В поисках денег придумывает всякого рода источники. Вместе со своей напарницей, Адой Лавлейс придумывает “беспроигрышную систему” заключения пари на лошадиных бегах. Система привела к тому, что леди пришлось расплачиваться фамильными жемчугами. Затем Бэббедж планирует за год написать роман и выручку затратить на машину. Отговорил от этой затеи его друг. Затем неутомимый Бэббедж планирует наводнить страну автоматами для игры в крестики-нолики и, опять-таки, выручку пустить на машину. Но и на это нужны были деньги.

Работать ему мешали своими выступлениями уличные музыканты. Бэббедж через прессу, парламент, полицию ведет борьбу с ними. В ответ каждый пьянчуга считал своим долгом поорать под окнами Бэббеджа, музыканты являются уже издалека, чтобы повеселиться под его окнами. После смерти Бэббеджа в некрологе в газете “Таймс” есть строки “… человек, который дожил почти до 80-лет, несмотря на преследования уличных музыкантов”. Интересно до каких лет дожил бы он сейчас, когда современные уличные музыканты вооружены куда более большими децибелами?

Однажды Бэббедж придумал план эффективной борьбы с пожарами, но заявил “Я не опубликую его, пропади они все пропадом, пусть все их дома сгорят”. Ненавидел благочестие. Когда он увидел в Италии водокачку с надписью, гласящей, что хозяин построил ее во имя любви к богу и к своей стране, для того, чтобы усталые страннику могли утолить жажду, то Бэббедж насторожился, осмотрел водокачку и обнаружил, что каждый раз, когда путешественник качал воду, большая часть ее попадала в дом к благочестивому хозяину. После этого эпизода Бэббедж добавил “Есть только одна вещь, которую я ненавижу более чем благочестие – это патриотизм”

Первым программистом для аналитической машины Бэббеджа была дочь поэта Байрона — Ада. Вот несколько ее высказываний.

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

Ада ввела термины “рабочие ячейки”, “цикл”. Так что язык программирования “Ада”, применяемый в Пентагоне имеет достойное название.

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

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

Уже упоминаемый фон Нейман чисто теоретически доказал возможность самовоспроизведения автоматов. Кстати эта возможность реализована практически.

Классика-литература

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

Брукс. Как проектируются и программируются программные комплексы
Классика по проблемам, с которыми сталкиваются крупные проекты.
Дал, Дейкстра, Хоор. Структурное программирование.
Определяет начало новой эпохи в программировании. Удивляешься тому, как неожиданно и глубоко можно смотреть на обыкновенные программы. Содержит много философских замечаний.
Дейкстра. Дисциплина программирования.
Совершенно потрясная книга. В молодости я затратил на нее два отпуска. Увы, не могу уверить себя, что я все понял. Когда я встречал программистов, пытающихся блистать своим интеллектом, то я давал им читать эту книгу. Они возвращали ее какими-то сконфуженными. Схожая реакция была на “Пересмотренное сообщение об Алголе-68” (как выразился об Алголе-68 один из авторитетов – “это язык для программистов-поэтов”)
Вирт. Систематическое программирование.
Первая прочитанная книга, которая показала, что учебник по программированию может быть хорошим.
Йодан. Структурное программирование.
Главное успеть отметиться на модную тему. Но здесь это было к месту.
Грис. Наука программирования
“Если считать переломную книгу Дейкстры (Дисциплина программирования) интеллектуальным откровением, то книга Гриса – это апостольское деяние ”(Ершов).
Ахо, Хопкрофт, Ульман. Построение и анализ вычислительных алгоритмов
Противовес современным книгам однодневкам типа “C-+ за 21 секунду, минуту,… ” Содержит изложение важных быстрых алгоритмов, которые еще долго не умрут.
Турский. Методология программирования
Много интересных замечаний как о программировании в малом, так и о программировании в большом.
Кушниренко. Программирование для математиков
Великолепный учебник с высоким уровнем изложения.

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

Разное

Мифы

Программировать может любой. На этот счет к месту цитата из Шекспира: “Я духов вызывать могу из бездны, И я могу и каждый может, Вопрос лишь в том идут ль они на зов”. Как и для любой профессиональной деятельности для программирования нужно иметь склонность и способности. Мне кажется, что программировать могут и не все программисты. Можно до битика знать Windows NT и быть бессильным перед самостоятельным решением простейшей прикладной задачи.

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

Задачу бухучета написать легко и неинтересно, а вот создать web-страницу трудно и интересно.

И первое, и второе можно варьировать. Главное: бытовую задачу, мол, реализовать легко и над этим не стоит особенно трудиться. Достойны внимания только всякого рода кунштюки. Но так, по-моему, говорят только программеры, не создав ни одного приличного проекта. Это как представление о музыке как о модных наушниках – и бродит масса меломанов в наушниках, и с каким-то таким особенным видом приобщенности к какой-то эзотерике. Я и сам когда-то отдал дань программистскому снобизму. Видимо любой программер проходит стадию «я все знаю и все могу». Но для большинства она длится недолго.

Подобного рода настроения могут быть и с «высокой» стороны. В одной фирме знакомлюсь с программистом, выходцем из Физтеха, когда-то программировавшем полет баллистической ракеты. Начинаем разговор о применении математики в банковском деле. Он тут же мне приносит массу страниц с математической моделью фрагмента деятельности банка — дифференциальными уравнениями с запаздыванием(!!)(запаздывание пошло от процентов – кредит, выданный сегодня, приносит прибыль через некоторое время – вот и запаздывание). Выясняется, что он отталкивается от функционала прибыли банка и далее применяет известные методы математики. Но ведь задача то и состоит в том, чтобы найти этот функционал. А математику-программеру казалось, что это мелочь, с которой справится любой банкир, а вот дальше нагородить кучу формул банкир не сможет. Второе верно, но первое – нет. А в этом то и соль. Нужна не просто математика, а работающая математика. Иначе это только схоластика формул. Кстати функционал прибыли наверняка будет разрывной функцией(почти все экономические показатели разрывны, курс валюты, например) и поэтому к нему неприменимы методы непрерывной классики — принцип максимума Понтрягина, например.

Дай мне достаточно сильный компьютер и я взломаю любой код. Есть масса программистов, которые до хрипоты будут уверять, что можно взломать любой код. Дайте только достаточно сильный компьютер. По моему, это незнание азов теории информации, заложенной Шенноном. А все достаточно просто. Рассмотрим шум как закодированное сообщение. Из шума можно извлечь все что угодно. Его никак нельзя раскодировать – извлечь нечто полезное. Иначе это не шум. Шум, наложенный на сообщение, дает шум. Так вот наложим шум на сообщение: Шум(Ш)+Сообщение(С)=Шум1(Ш1). Шум Ш1 нельзя расшифровать. Конечно, полным перебором можно докопаться до сообщения. Но как узнать, что это нужное сообщение. Пусть мы имели сообщение “Петя — дурак”. Полный перебор извлечет это сообщение, но он извлечет и такие: “Петя — умник” и “Вася — дурак” и т.д. Так какое из них взять?

Но извлечь сообщение все-таки можно. Для этого нужно знать шум и способ наложения. Тогда С = Ш1-Ш. Но для этого не нужен суперкомпьютер, а нужно знать шум.

Между прочим, подобная схема, кажется, и применяется при разговорах между американским и российским президентами.

Математика программистам не нужна

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

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

Принципы

Какие общие положения произвели впечатление?

Разделяй и властвуй

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

Пусть безобразно, но единообразно

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

В связи с этим вызывает удивление отсутствие необходимых языковых конструкций, подталкивающих к системе. И самые современные средства для разработки СУБД-приложений сами строятся на файловых подходах. А как удобнее было бы представлять проект в виде БД и применять к нему аппарат поиска и выборки…

Язык определяет мышление

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

Программа=алгоритм+данные

В объектно-ориентированном подходе это положение протянуто до элементарных конструктов – объектов, которые состоят из данных и методов. Программирование вначале развивалось под знаком алгоритмов, а потом данных. Тематика СУБД полностью идет по рубрике “данные”. Но алгоритмы прокрались и туда – методы поиска, методы индексации.

Моделируй предметную область

Вербальная модель порождает представление о предметной области, доступное для ИТ-шника и содержащая самое существенное. Информационная модель типа “сущность — связь” порождает БД. Функциональная модель “модуль М получает на входе In и преобразовывает его в Out” определяет архитектуру программ. Объектная модель представляет предметную область как набор взаимодействующих объектов. Событийная модель помогает изобразить движение системы как изменение в ответ на определенные события.

Некоторые задачи

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

Задача о кофейных зернах

В банке имеется известное число черных и белых кофейных зерен и свободный запас зерен. Случайно выберите из банки два зерна. Если они одного цвета, то положите их в запас и положите в банк черное зерно. Если они разного цвета, то верните белое зерно назад, а черное поместите в запас. Продолжайте процесс, пока в банке не окажется одно зерно. Какого оно будет цвета?

Решение.
Процесс явно цикличен: повторяется действие “вынуть и положить”
Инвариант цикла – четность числа белых зерен. Значит, еcли начальное число белых зерен четно, то последним зерном будет черное, а если нечетно – то белое.

Жулик на пособии

Есть три очень длинных файла: Работники r, Студенты s, Безработные b. Они упорядочены по ФИО. Известно, что есть жулики-студенты, которые работают и находятся в списках безработных и, поэтому, получают пособие по безработице. Написать программу, находящего первого такого жулика – того, чье имя стоит первым по алфавиту.

Решение.
Пусть i,j,k – координаты в файлах r,s,b
I,j,k:=0,0,0; — начнем с начала
Пока (r(i)<>s(j) и s(j)<>b(k) и b(k)<>r(i)) повторять
начало
Если r(i) < s(j) то i:=i+1;
Если s(i) < b(j) то j:=j+1;
Если b(i) < r(j) то k:=k+1;
конец

i,j,k содержат координаты жулика в своих файлах.

Но как элегантно это выглядит в нотации Дейкстры:

i,j,k:=0,0,0;
do
? R(i)<S(j)?i:=i+1;
? S(j)<B(k)?j:=j+1;
? B(k)<R(i)?k:=k+1;
оd
{i,j,k и есть искомые координаты}
Где символ ? идентифицирует так называемую охрану (R(i)<S(j) и т. д)
Жалко, что эта нотация не вошла в языки.

Притча о туалетах в поездах

Жила-была некая страна, где каждый вагон делали с туалетом. Но вот появился экономист и решил сэкономить, снабдив туалетом половину вагонов. Так и начали делать. Но забыли предупредить об этом сортировочные станции, где собирается состав. В итоге некоторые поезда оказались без туалетов. Чтобы исправить положение, каждый вагон снабдили надписью, говорящей есть ли в нем туалет и проинструктировали сцепщиков: ”В поезде должно быть около половины туалетов”. Хотя это и осложнило жизнь сцепщикам, но они честно выполняли инструкцию. Однако пошли жалобы на то, что иногда туалеты оказывались в одной половине поезда. Чтобы исправить дело выпустили новую инструкцию: “При сцепке чередовать вагоны с туалетами и без оных”. Это добавило работы сцепщикам, но они, поворчав, стали честно выполнять инструкцию. Однако пошли жалобы на то, что для вагона без туалета вдобавок и туалет оказывался не в начале хотя бы одного соседнего вагона, а в дальних концах обоих их. Ужасная несправедливость для демократической страны. Что делать? Помозговав, чиновники выпустили дополнительную инструкцию “Каждый вагон с туалетом снабжать стрелкой, указывающей где туалет. При сцепке все стрелки вагонов поезда должны быть направлены в одну сторону ”. Сцепщики, хотя у них было недостаточно поворотных кругов, напряглись и стали делать и это. Однако — о ужас! – пассажиры стали беспокоиться о том, что хотя до ближайшего туалета и не более вагона, но не ясно с какой стороны этот туалет. Вышла дополнительная инструкция: ”В каждом вагоне без туалета, нарисовать стрелку “Туалет ” и сцеплять вагоны так, чтобы эта стрелка указывала на ближайший туалет”. Сцепщики взвыли: они вовремя не успевали. И тут нашелся человек, который заметил следующее: если сцепить вагон с туалетом и без оного так, чтобы туалет был в середине пары и никогда пару не расцеплять, то сортировочная станция будет иметь дело вместо N ориентированных вагонов с N/2 симметричных (неориентированных) пар вагонов. Тогда все проблемы сортировки исчезали. Правда, поезда должны содержать четное число вагонов. Но с этим можно смириться. Так и сделали.

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

Быстрая сортировка

После пузырьковой сортировки и сортировки Шелла – это откровение. Красивый алгоритм и самый быстрый результат.

Программа, распечатывающая текст самой себя

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

Шахматы на нескольких строчках

Поразила и программа, примерно из пятидесяти строк на C, которая прилично играла в шахматы. В строке могло быть несколько операторов.

Случаи

Польская запись

Было это давно. Разрабатываем в ВЦ Белпромстройбанка проект по ведению данных о стройках республики. Замышляется генератор отчетов. Каждая графа может задаваться любой арифметической формулой. Как ее вычислять? Принимается решение, что пользователь должен заполнить специальную форму, в которой он сам сводит формулу к элементарным. К примеру, формула r=(a+b)/(c-d) раскладывается так: 1) x=a+b, 2)y= c-d, 3) r=x/y. Так и сделали. Обкатываем. Проект внедряется. Каждый день отрабатываются десятки отчетов, печатающихся на десятках килограмм перфорированной финской бумаги. Шеф думает о дальнейшем развитии проекта. Постепенно у него зарождается идея, что разложение любой формулы может сделать сама машина. Тем самым пользователь избавляется от дурной работы – декомпозиции формулы (разложения ее на последовательность простых). Появляется идея раскрутки формулы в бесскобочную запись. Дальше появляется идея стека. И тут я вспоминаю, что читал где-то о польской записи выражения. Нахожу книгу и вижу, что мой шеф сам пришел к идее польской записи (или, по-другому, постфиксной) и стека. Все это было бы восхитительно, если бы не изобретение велосипеда. Ведь все это программист должен знать. Но и он, и я были дилетантами — пришельцами из других профессий… Увы, оказалось, что и наши профи (кончали матфак БГУ и работали в НИИ ЭВМ) этого не знали. Так что тут еще более грустно.

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

Еще немного о дилетантизме. Придя к нам на работу, шеф (будем называть его А.М.) решил сменить главу программистов. Вот я рассматриваюсь как претендент. Идет вроде бы милое собеседование, но реально идет тестирование. И вот мне задается вопрос “А как это физически определяется конец файла?” Увы, я этого не знал и отвечаю, что, мол, зачем мне знать, если язык мне дает ситуацию EOF и неважно как это реализуется. Как говорил К.Прутков: “… прав Костаки, прав и я”. Но как глава программистов я был зарублен. Однако мне предложили возглавить постановщиков. (Возвращаясь к началу повествования и, вспоминая классику, можно сказать – “сбылась мечта идиота”). “Учтя широкое мировоззрение ” как сказал А.М. Так были отделены овцы от козлищ – генералисты от специалистов. И далее А.М. квалифицированно разбиралcя с кадрами. Так у меня доминировал и доминирует подход к проблеме “сверху вниз – от проблемы к машине”, а у моего коллеги был противоположный “снизу вверх – от машины к проблеме”. А.М. тут же развел нас по разным полюсам. Коллега стал работать над драйверами устройств ввода данных о стройках, а я над ведением математической модели получения отчетов о состоянии строек. В других же проектах с другими руководителями я встречал обратное. В результате один говорит о битах, а второй об интегралах и не понимают друг друга.

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

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

Примеры:

“От и до” – нечего думать только о своей болячке, нужно видеть весь процесс.
“До битика” – халтурный, поверхностный подход здесь не пройдет.
“Засучив рукава” – нечего халявить, работайте без сачка.
“Так ли это?” – Не чушь ли ты несешь братец?

Эти пластинки повторялись у него ежедневно. Но была у А.М. и более неприятные свойства. Он очень любил устраивать мозговой штурм по праздникам. Праздник. Закончено обустройство стола, раскупоривается шампанское – и тут жди звонка от АМ. Так и есть, звонок. — “Тут у меня появилось парочку идей. Предлагаю обсудить их”. И – прощай праздник.

Змея, заполняющая все пространство

Как только появились дисплеи, появились и визуальные игры. Одна из первых — змея, догоняющая свой хвост. Змею нужно было вести, обходя случайно возникающие препятствия, давая команды налево/направо. Змея все время удлинялась, так что пространства оставалось все меньше. И тут у меня возникла задача. Можно ли выбрать такой маршрут змеи, чтобы она заполнила собой все пространство экрана. Подумав пару часов, я нашел нужный маршрут. Идем на обед. Я в очереди рассказываю задачу своему коллеге. И к моему удивлению, нам еще не успели налить первое, как он решил задачу (хотя очереди были длинными, но не на пару же часов). Поразмышляв над этим случаем, я стал утешать себя тем, что, видимо, стремление поесть стимулирует интеллект.

Фразы классиков

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

Брукс:

• За мастерством стоит изобретательность, благодаря которой появляются экономичные и быстрые программы. Почти всегда это является результатом стратегического прорыва, а не тактического умения. Иногда таким стратегическим прорывом является алгоритм, как, например, быстрое преобразование Фурье, предложенное Кули и Тьюки, или замена $$ сравнений на n*log(n) при сортировке.
  
  Гораздо чаще стратегический прорыв происходит в результате представления данных или таблиц. Здесь заключена сердцевина программы. Покажите мне блок-схемы, не показывая таблиц, и я останусь в заблуждении. Покажите мне ваши таблицы, и блок-схемы, скорей всего, не понадобятся: они будут очевидны.

• Представление данных — это суть программирования.
• Привыкание к требованиям совершенной точности является, по моему мнению, наиболее трудным в процессе обучения программированию.
• Как только проект окончательно принят, он становится устаревшим в смысле своих концепций.

Вирт:

• Программа=алгоритм+данные.
• В обычно используемых методах тестирования (отладки) программ исследуются только отдельные вычисления, а не весь класс вычислений, которые можно выполнить с помощью.
• этой программы. Чтобы сформулировать общезначимые утверждения о программе, необходимы аналитические методы верификации программ.
• Концепция верификации программы по существу является краеугольным камнем для более глубокого понимания алгоритмов, без нее программист не имел бы никакого другого инструмента, кроме своей собственной сомнительной интуиции.
• Программисту, который вынужден пользоваться более простым инструментом (например, машиной без встроенной операции деления), приходится искать и в конце концов находить решение более высокого качества. И нет ничего удивительного в том, что наличие очень мощных вычислительных машин с большой памятью расхолаживает программистов и ни в коей мере не стимулирует разработку более совершенного и экономичного варианта алгоритма.
• Как и в любом инженерном деле, конструирование изделия, в данном случае алгоритма, требует осмысливания, исследований и принятия решений. На ранних стадиях внимание обращено главным образом на глобальные проблемы, и в первом эскизном проекте упускаются из виду многие детали. По мере продвижения процесса проектирования задача разбивается на подзадачи, и постепенно все большее внимание уделяется подробному описанию проблемы и характеристикам имеющихся инструментов. В программировании благодаря абстрактной природе получаемого изделия появляются совершенно неожиданные возможности. В отличие
• от других областей инженерной деятельности в программировании изделия можно конструировать (и испытывать) без материальных затрат; они свободны от побочных физических эффектов, связанных со старением и применением материалов низкого качества. Поэтому программисты могут и должны разрабатывать много версий алгоритмов и тщательно сравнивать и анализировать их, прежде чем сделать окончательный выбор.
• Вероятно, наиболее общая тактика программирования состоит в разложении процесса на отдельные действия, а соответствующих программ на отдельные инструкции. На каждом таком шаге декомпозиции нужно удостовериться, что:
  
  
  1. решения частных задач приводят к решению общей задачи,
  2. выбранная последовательность индивидуальных действий разумна и
  3. выбранная декомпозиция позволяет получить инструкции, в каком-либо смысле более близкие к языку, на котором в конечном счете будет сформулирована программа.

SUN:

Сеть – это компьютер.

Отличная идея. Значит в идеале распределенная программа, рассматриваемая на уровне языка разработки, не должна отличаться от унитарной. Распределенная база на уровне использования не должна отличаться от нераспределенной. Распределенность должна реализовываться ОС. Распределение и оркестровка сервисов также не должна быть заботой прикладного программиста.

Дейкстра:

• Есть что-то пугающее в том, какими неисповедимыми путями наши привычки влияют на наш способ мышления (когда оказалось, что задачу о голландском национальном флаге быстрее решали семиты, так как нужно было начать перебор справа налево, а им это не впервой).
• Совет профессионалу-непрограммисту: если ты хочешь получить пользу от компьютера – не программируй.
• Что может дать применение техники формального доказательства программ на практике? Ответ Дейкстры: “Ответ менеджера на этот вопрос прост: ничего. Он скажет, что сложные проблемы для своего решения требуют больших программ, что большие программы могут быть написаны только большими коллективами, которые по необходимости состоят из людей низкой квалификации – достаточно низкой для того, чтобы сделать применение формальной техники полностью невозможным,
  … Я не согласен с этим ответом, поскольку он опирается на два неявно сделанных предположения. Первое из них состоит в том, что решение трудных проблем требует больших программ, второе, что с помощью “легионов” второсортных специалистов можно решить трудную проблему. Попытки использования легионов малокомпетентных программистов неоднократно предпринимались – и всегда с катастрофическими результатами… Экспериментально установлено, что большие коллективы второсортных программистов бесполезны, а
  совершенствование искусства их предводителей – напрасный труд”.
• О феномене программирования
  
  В программировании наш основной строительный блок выполняется менее чем за микросекунду — $$ а наша программа может выполняться часы — $$. Кроме программирования я не знаю другой технологии имеющей дело с отношением десять в десятой степени или даже большим. И в этом отношении проблема программирования, по-видимому, не имеет прецедента.
• О модуляризации.
  
  Главная характерная черта культурного мышления, по моему мнению, заключается в том, что человек может и хочет изучать некоторый аспект изолированно, ради его собственного содержания, сознавая в то же самое время, что он занимается только одним из аспектов. Другие аспекты должны ждать своей очереди, потому, что наши головы так малы, что не могут без путаницы работать со всеми аспектами. Это не значит, что другие аспекты полностью игнорируются, но временно мы про них забываем настолько, насколько они не существенны для текущей темы. Такое разделение, даже если оно и не полностью осуществимо, есть единственно доступный нам метод эффективного упорядочивания наших мыслей, который мне известен. Но мне бы хотелось отметить, что это разделение объектов рассуждения является только результатом, а не целью. Цель мышления заключается в уменьшении детализированных рассуждений до выполнимого количества, и разделение аспектов – это способ, с помощью которого мы собираемся добиться этого уменьшения. Из вышесказанного следует, что хотя и не ясно как проводить разделение аспектов, но ясно, что не нужно смешивать аспекты, которые были разделены в начале.
• …цель мышления состоит в уменьшении детализированных рассуждений до выполнимого количества. Наиболее волнующий вопрос здесь: можно ли понимаемому в этом смысле “мышлению” научить? Если я отвечу на этот вопрос: ”Нет”, то меня сразу же могут спросить, зачем я стал писать эту книгу; если на этот вопрос я отвечу: ”Да”, — то буду выглядеть дураком. Прежде всего, людям нужно объяснить, что человек неспособен заниматься всем – королями и капустой – и нужно научить их видеть, в чем и когда сложность проявляется. В той же мере, в какой профессор консерватории помогает своим ученикам знакомиться с элементами гармонии и ритма и с тем, как их можно комбинировать, вполне возможно научить студентов чувствовать образцы рассуждений и способы их комбинирования. Эта аналогия вовсе не притянута за волосы: четко проведенным рассуждением можно восторгаться так же, как и адажио Моцарта.
• Отладка может доказать наличие ошибок в программе, но не может доказать отсутствие ошибок в программе.
• Наверняка разочаруются все те, кто отождествляет трудность программирования с трудностью изощренного использования громоздких и причудливых сооружений, известных под названием «языки программирования высокого уровня» или — еще хуже! — «системы программирования». Если они сочтут себя обманутыми из-за того, что я вовсе не касаюсь всех
  этих погремушек и свистулек, могу ответить им только одно: «А вполне ли вы уверены, что все эти погремушки и свистульки, все эти потрясающие возможности ваших, так сказать, «мощных» языков программирования имеют отношение к процессу решения, а не к самим задачам?» Мне остается лишь надеяться, что, несмотря на употребление мною мини-языка, они все же прочтут предлагаемый текст." Тогда они, возможно, признают, что помимо погремушек и свистулек имеется очень богатое содержание и возникнет вопрос, стоило ли большинство из них вообще придумывать.
• Посвятив немало лет своей научной жизни тому, чтобы прояснить задачи программиста и сделать их более подвластными нашему интеллекту, я обнаружил с удивлением (и раздражением), что мое стремление внести ясность приводит к систематическим обвинениям в том, что я «внес в программирование трудности». Но эти трудности всегда в нем были; и только сделав их видимыми, мы сможем надеяться, что научимся разрабатывать программы с высокой степенью надежности, а не просто «лепить команды», т. е. выдавать тексты, основанные на неубедительных предположениях, несостоятельность которых может выявиться после первого
  же противоречащего примера.

Не_знаю_кто :

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

Маркетинг и программисты

Я подготовил по своему проекту рекламные материалы к выставке. Маркетологи моей фирмы обрушились на мой рекламный материал такими нападками:

• В материале много отрицаний(описание недостатков существующих проектов), а это несет негативную энергию
• Размеры рекламных листков не укладывались в золотое сечение.

И что-то ещё подобное.

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

Меня впечатлило вот что в маркетинге(вообще, а не в маркетинге фирмы). Это магия имен. Нужно каждому хоть сколь значительному факту дать название и возможно звучную аббревиатуру. Это уже гарантирует, что вы не оставили без внимания сам этот факт. А дальше нужно соответствовать названию. Название – применение принципа “Разделяй и властвуй”. Когда мы даем название, тем самым мы выделяем предмет. Сколько было авторских претензий типа: “мы это видели, но не выпячивали это факт и не давали ему названия ”. В том то и дело! Тогда я и понял круговерть OLE-->OCX-->ActiveX-->COM-->?; А сайт--> портал-->?.. Ну что говорить о взаимодействии бизнес-бизнес, а вот когда мы скажем B2B(Business to Business) — это уже термин и, значит, за этим что-то есть, хотя на самом деле может ничего и не быть, а просто обозначение. Как только появилась аббревиатура ERP, так очень многие разработчики стали преподносить свои разработки как ERP… Мода на термины — сильная вещь.

В связи с этим вспоминается следующее. Когда партия разрешила кибернетику, начались дебаты как назвать то, что сейчас называется «компьютер». «Вычислитель»,«ЦАМ», «ЭВМ»… — все не катило. Великий и могучий наш язык спасовал перед американизмом «Компьютер». По моему, это проявление комплекса неполноценности перед Западом. И, надо сказать, увы, вполне обоснованный комплекс.

Об интеграции

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

Самое

Самая интересная задача

Это проект “Бизнес-аналитика”. Что может более потешить самолюбие как осознание того факта, что ТЗ определил сам, постановку сделал сам, информационную модель – сам, объектную модель – сам и вдобавок еще и программируешь. Задача интересна новизной и широтой. Границ ее не видно.

Самая большая задача

Самый большой коллективный проект — Паспорта строек всей Беларуси. Проект был реализован на ассемблере ЕС ЭВМ. Предметная область — данные о всех стройках Беларуси. Пользователь сам задавал структуру и содержание отчета о стройках.

Самый большой индивидуальный проект — Бизнес-аналитика. Предметная область — анализ прошлого, текущего, планового и прогнозного состояний бизнеса. Инструменты: декомпозиторы, компараторы, сценарии моделирования, динамические ряды, статистические гипотезы. Языки: Delphi, C#.

Самая поразившая задача

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

Самая поразившая книга

Дал, Дейкстра, Хоар. Структурное программирование.
Дейкстра. Дисциплина программирования.

Самые нелепые случаи

Разрабатывали мы проект на Коболе для EC-1020. Я — начинающий программист. Возникла необходимость в программе-диспетчере, вызывающей те или иные программы в зависимости от ситуации. Программы на Коболе не могли загружать другие(или я не знал как это делать). Нужно было или писать на ассемблере (чего мы не знали), или делать что-то другое. И вот нашли это другое – это язык управления заданиями (JCL) операционной системы DOS.

Было такое понятие как SYSIN (логическое устройство входных данных), SYSRDRR (логическое устройство ввода директив JCL) и т.д. Их можно было переназначать во время выполнения. Поэтому, наготовив кучу SYSRDR для каждой возможной ветки можно в принципе выполнить задачу. И мы затратили массу усилий, чтобы сделать это. И все, конечно, напрасно. Изучив Ассемблер, мы получили все, а затратив кучу усилий с JCL, даже добившись результата мы не получали ничего нового. Выбирать нужно не из того, что ближе, а что принесет больше пользы вообще. Кстати, на смену DOS пришла OS/360 и тот JCL ушел в прошлое. Но пришел еще более соблазнительный, однако такая ошибка уже не повторялась. Трудно из рогатки сделать пистолет.

Самые смешные

В начале “асучивания” продукт сдавали в опытную эксплуатацию на контрольном примере. Контрольный пример — это глобальный тест, составляемый экономистами. Результатом прогона продукта обычно были табуляграммы – отчеты о состоянии решаемой проблемы, на разных стадиях ее решения. Табуляграммы сверялись с контрольным примером и если они совпадали, то продукт принимался в опытную эксплуатацию. Но проект не готов. Что делать? Решение простое. Пишутся программы, выдающие табуляграммы в лоб. На сдаче они и запускаются. И неопытный (а кто тогда был опытный?) заказчик подписывает акт приема в опытную эксплуатацию.

“Если можно рассказать, то зачем показывать” – такой фразой ответил один уважаемый программер, когда после увлекательного показа созданной им программы, последняя завалилась в самом начале показа и он перешел с показа на рассказ.

Самые странные

Разрабатывается проект – “Бизнес-аналитика”. Разработан был под NT. И вот нам нужно срочно продемонстрировать систему в банке. Решаем сделать это на ноутбуке. Там уже стояла Windows-98. Ставим, перекомпилируем, запускаем – все хорошо, кроме одного: начало периода устанавливается в 1898 год. Начинаем подозревать, что неправильно извлечен контекст, содержащий даты. Контекст извлекается по коду пользователя, который извлекается обращением к функции GetUserName API Windows. Начинаем подозревать, что эта функция неправильно срабатывает. Ставим точку подглядывания и запускаем отладчик. Все хорошо и программа нормально работает и даты нормальные. Списали все на случайность. Был вечер, и мы, довольные, идем домой. Завтра в банк. Наутро включаем – опять та же ситуация с датами. Включаем подсмотрщик в отладчике – все отлично. Ну прямо ситуация в квантовой механике: когда за частицей не подсматривают – они волны и интерферируют, а когда за ними подсматривают – они частицы. Так мы ответа не получили. А чтобы все прошло нормально, мы “ручками” ввели правильные данные и демонстрация прошла успешно.

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

Почти философия

Как описать интеллектуальные возможности программы, компьютера с фиксированным размером памяти? Ясно, что они не смогут даже запомнить достаточно большое число. Ну и что – мы тоже не можем запомнить и записать достаточно большое число. Но мы не относим себя к
неинтеллектуальным существам. Так где формальное определение интеллектуальности? Мне кажется это одна из фундаментальных проблем. Как описать меру интеллектуальности системы с заданными внешними параметрами – памятью? Как программа может понять саму себя – пределы самопознания? Применение макросов — программ, модифицирующих самих себя, ставят вопросы: может ли программа умнеть?, где пределы поумнения?

Как раньше мировоззрение определялось естественными науками, так теперь все в большей мере оно определяется Computer Science. Я имею в виду не примитивное программирование, а науку программирования. Так многие абстрактнейшие философские проблемы становятся совершенно конкретными при рассмотрении их с компьютерной точки зрения. Рассмотрим такой пример. В конце концов, в компьютере можно будет смоделировать интеллектуальные программы-существа. Можно смоделировать размножение, отбор, наследственнность, пространство, время… Получается внутрикомпьютерный мир. И вот внутрикомпьютерные существа(softhomo) живут там, борются за кусок хлеба беседуют, философствуют и рано или поздно задумаются: а есть ли бог на свете? Что первично: материя или сознание? Есть ли вещи в себе? Познаваем ли мир? Находится солипсист и заявляет: “весь мир существует только в моем воображении”. Местные материалисты подняли в связи с этим вой. Кто прав? С точки зрения их мира – правы материалисты, а сточки зрения нашего, внешнего по отношению к ним мира, прав солипсист. Доказательство этому – выключение компьютера.

И в нашем мире давно уже высказывалась мысль, что правы и материалисты и идеалисты. В физике давно преодолено примитивное дихотомическое мышление типа “или частица или волна” – “И частица И волна”. Так и в философии. Когда Бора спросили, что такое глубокая истина, он ответил так: “Глубокая истина это такая истина, отрицание которой также глубокая истина”. Отрицание истины 2*2=4 не глубоко, значит и сама эта истина не глубока. А вот отрицание истины “материя первична” глубока, как говорит все развитие философии, когда материалисты-ленинцы только критиковали идеалистические новации, сами не выдвинув ничего нового: мол “Да они сами не понимают, что придумали. А вот только мы дадим этому материалистическую интерпретацию, то все станет подлинно научным” Пример – кибернетика, семиотика, копенгагенская интерпретация квантовой механики и т.д.

И вот что: что бы softhomes там ни выдумывали, как бы ни напрягали интеллект, но они никогда не увидят и не услышат наш внешний для них мир – программиста, например(если программист не заложит диалог явно). И для них программист – бог, и наш мир для них вещь в себе, и ничто из нашего мира для них непознаваемо, и их интеллектуальная начинка, сделанная программистом это априорное знание. Похоже Кант, который говорил обо всем этом в своей философии, действительно знал в этом толк. Абстрактнейшие понятия Канта “вещь в себе”, ”трансцендентное”, ”трансцендентальное”, ”априорное синтетическое знание” получают в этой интерпретации вполне понятные вещи. Для указанного мира весь наш мир это вещи в себе, априорное синтетическое знание – все, что программист вложил в интеллект внутрикомпьютерного мира, трансцендентное знание для него – знание того, как программист создал этот компьютерный мир.

В таком случае можно задаться вопросом: А может и мы для кого-то являемся внутрикомпьютерным миром и бог это программист? Кстати в физике сформулирован так называемый антропный принцип. Оказывается, что все законы физики устроены так, что измени их чуть-чуть и человек не возник бы. Измени чуток гравитационную постоянную, или заряд электрона, или постоянную Планка и все устроится так, что или Солнце не загорится, или будет слишком жарко. То есть все сделано так, чтобы появился человек. Правда, многие говорят, что это само собой разумеется: разные миры могут возникать миллионы раз без человека, но если уж человек появился, то, естественно, что мир, в котором он появился, устроен так, чтобы он появился. Раз трактор вышел с конвейера, то естественно, что конвейер устроен так, чтобы трактор появился. Но все же, все же…

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

Последнее

Из всего жизненного пути я вынес банальную мудрость: “Чтобы умно поступать одного ума мало”. Сколько умниц было у нас на курсе — много. А где они? Что еще нужно для успеха? А бог его знает. И фарт, и деньги, и житейская наглость. Всем правят, увы, наглые троечники. Умники слишком сомневаются в себе. Им хватает интеллекта, но не хватает воли.

Жалобу древних вавилонян “ Настали тяжелые времена, прогневались боги, дети больше не слушаются родителей и всякий стремится написать книгу ” современность модифицировала: “Настали тяжелые времена, прогневались боги, дети больше не слушаются родителей и всякий стремится написать книгу, и, о горе, каждый дурак хочет создать собственный site/portal/blog в Internete”.