УНИВЕРСИТЕТ ИТМО
Кафедра «Технологии программирования»

Об алгоритмах и программах

1. Изготовление мостов, дорог, небоскребов без документации уголовно наказуемо. Этого не скажешь о программах.
   А.А. Шалыто
   PS. Кстати, в археологии тоже нельзя копать, как и где бог на душу положит, так как при этом могут быть большие неприятности.
2. Косой пошел с косой.
   Криницкий Н.А. Алгоритмы вокруг нас. М.: Наука, 1984.
3. Смотрит зайка косой,
   Как девчонка с косой
   За речною косой
   Травы косит косой.
   Михаил Митрейкин
4. Порядок сменит хаос.
   Прочел у Карпова Ю.Г.
   P.S. Кто, кого сменит?
5. Я встретил ее на поляне с цветами
   Прочел у Карпова Ю.Г.
   PS. У кого или где цветы?
6. При проектировании любая техника, сложнее CRC-карточек (или диаграмм использования - А.Ш.) считается слишком сложной и не применяется. У программиста всегда есть возможность отказаться от любой технологии, сказав начальнику, что он не укладывается в срок.
   
   
   Фаулер Мартин. Новые методологии программирования//www.spin.org.ua
   
   
   Все это приводит к тому, что даже "пользователи не считают ошибочное программное обеспечение чем-то из ряда вон выходящим"
   Буч Г. Создание будущего //Подборка статей на тему "Программы следующего десятилетия" в журнале "Открытые системы". 2001. N12.
7. Общая проблема российских программистов - патологическое нежелание читать, а уж тем более писать документацию.
   Демин В. Проблемы выхода российских разработчиков на Запад //PC WEEK/RE. 2001. N32.
8. Из пророков - в коммерсанты. Название статьи о создателях UML.
   PS. Бобровский С. Из пророков - в коммерсанты //PC WEEK/RE. 04.02.1997.
9. Перед тем как читать новую книгу по UML я приготовился к самому худшему. Я был приятно удивлен - лишь некоторые места книги содержали объяснения, которые были написаны так, будто сами авторы книги не совсем понимали, о чем речь. Когда вы в первый раз сталкиваетесь с языком UML, кажется, что его невозможно понять - такое там множество диаграмм и мелочей. Некоторые авторы утверждают, что большая часть всего этого попросту никому не нужна...
   Б. Эккель. Философия Java. СПб.: Питер, 2001.
   PS. Наши танки, рассмотренные в разделе "Проекты", подтверждают это. Кстати, при социализме под сокращением УМЛ понимался университет марксизма-ленинизма...
10. Линус Торвальдс говорит, что программисты могут проводить заимствования, как уже 450 лет их проводят ученые - только ссылаясь. Так поступили и мы, делая этот сайт.
11. В сентябрьском номере за 2002 г. в одном из журналов для программистов на странице "От редакции" написано, что у журнала: "... растет уровень авторов. Не так давно, уже после опубликования статей, мы узнали, что один из наших авторов является чемпионом Урала по программированию!"
    
    В ответ я отправил письмо следующего содержания. "Это хороший рекламный ход. Осталось, чтобы он был еще и корректным.
    
    Возникает вопрос почему слово "статей" написано вами во множественном числе?
    
    Так как вы не пишете о чьих статьях идет речь, может это сказано не про статьи чемпиона Урала по программированию, или этот чемпион не Н.Н. Шамгунов?
    
    У Н.Н. Шамгунова в Вашем журнале опубликована только одна статья, а вторую, как известно, Вы без объяснения причин отклонили. Так, что множественного числа никак не получается.
    
    Оно, правда, могло бы получиться, но в другом контексте, так как Н.Н. Шамгунов является трехкратным чемпионом Урала и двукратным участником финалов чемпионата мира по программированию.
    
    С пожеланием дальнейшего сотрудничества Шалыто А.А."
    
    Через день, чтобы исключить недопонимание, я послал второе письмо.
    
    "Вчерашнее письмо не содержит скрытого намека на публикацию отклоненной статьи. Она скоро будет опубликована.
    Вчерашнее письмо о другом - о корректности!
    С наилучшими пожеланиями Шалыто".
12. Люди нашей профессии производят чудовищные по своей сложности операционные системы, поставляемые с более чем 100 тыс. известных программных ошибок. Ведущие коммерческие программные системы создаются без предварительного анализа или проектирования, без использования моделей и диаграмм.
    
    Билл Гейтс публично заявляет, что не верит в диаграммы и не желает, чтобы его программисты занимались проектированием.
    Константин Л. Назад в будущее //Открытые системы. 2001. N12.
    PS. Может быть я антиглобалист, но знаете ли вы хоть один товар, кроме "коробочного" программного обеспечения, на который изготовитель не дает никаких гарантий?
13. Простота требует проектирования и хорошего вкуса.
    Л. Торвальдс
    PS. Вот вам и вся разница между Гейтсом и Торвальдсом.
14. Физик исследует мир, программист его создает.
    
    Очень трудно объяснить, что интересного в том, чтобы биться головой о стену три дня подряд, не зная, как лучше, красивее решить задачу.
    
    Но когда ты нашел решение - это чувство нельзя сравнить ни с чем в мире.
    Л. Торвальдс
    PS. Когда Линус это писал, он еще не знал, что ни с чем не сравнимое чувство возникает также, когда (с помощью Switch- технологии) ты точно и сразу знаешь место и условие возникновения логической ошибки (раздел "О нас" п.13).
    А.А. Шалыто
15. Я крутился как белка в колесе: программирование - сон - программирование - еда (соленые сухарики) - программирование сон - программирование - душ (на скорую руку) - программирование. Я редко вообще знал, день сейчас или ночь, рабочий день или выходной. В иные дни (или ночи?) я выпрыгивал прямо из постели на стул перед компьютером, до которого было примерно полметра. Без всякого преувеличения можно сказать, что у меня практически не было контактов с миром вне моего компьютера.
    
    И я ни в малейшей степени не чувствовал себя жалким яйцеголовым неудачником.
    
    Оболочка работала, а это значило, что я фактически построил основу работоспособной операционной системы. Про себя я назвал ее Linux.
    Л. Торвальдс
    PS. Как говорится, нет комментариев!
16. На одной из компьютерных выставок я видел один из программных продуктов, разработанный фирмой IBM, интерфейс которого был направлен на красивое визуальное программирование.
    Я спросил у стендиста: "А внутри программа построена также красиво, как это сделано для пользователя?"
    Стендист ответил: "Нет. Первое время все было красиво, а потом началась спешка и появились заплаты со всеми вытекающими для красоты последствиями".
    Странно, но такая ситуация относительно внутреннего устройства программ имеет место практически всегда.
17. Словесное описание на разработку программы, обладающей достаточно сложным поведением, это практически всегда не ее алгоритм, а декларация о намерениях и не более того.
18. Если говорить о промышленной разработке корпоративных систем, то индустрия уже давно топчется на месте.
    
    Несмотря на постоянное освоение идеологических новинок, выпуск все более совершенных средств разработки и технологических платформ, сдвиги в области конечных продуктов с большой натяжкой можно охарактеризовать как качественные. На мой взгляд на это имеется одна большая причина и одна маленькая.
    
    Большая причина состоит в слабости научных основ промышленной автоматизации деловых процессов. Если называть вещи своими именами, то научных основ нет.
    
    Вместо них существует целый ряд полушаманских учений под заголовками CRM, MRP, ERP, SCM, IDEF0, UML и т.п. Каждое из таких учений базируется на одном-двух (порой ошибочных) постулатах и претендует на относительную полноту, на деле покрывая лишь узкий спектр задач.
    
    Малая причина состоит в том,что корпорации, увлекшись технологиями, не больно-то задумываются о целях их возможного применения. Ситуация с постоянным выпуском новых версий, появлением платформ и сред больше напоминает шоу-бизнес, чем серьезную вдумчивую работу. В результате мы имеем кучу красивых разноцветных кирпичей, из которых можно построить все что угодно, кроме дома, для построения которого мы их собственно и покупали.
    
    
    Олег Горский, технический директор ООО "Кубикс", oleg@qbix.ru
19. Возник спор как правильно писать: аплет или апплет. Были разные доводы в пользу каждого из вариантов, например, что в Интернете написание "апплет" встречается значительно чаще.
    
    Но пока остановились на написании "апплет", ввиду того, что оно так пишется на русскоязычном сайте фирмы "SUN".
    
    PS. Отметим, что это слово отсутствует в Словаре для "начальников", созданном в СПбГУ //Российская газета, 4.09.2002.
20. "UNIX" можно прочитать как "У НИХ".
21. В микропроцессоре "Pentium-4" 28 миллионов транзисторов, а в операционной системе "Windows" порядка 30 миллионов строк. "Элементная" сложность близка, а качество разное...
    
    PS. Не знаю, как на "Pentium", а на "Windows" изготовитель ничего не гарантирует. Кто-то из студентов сказал, что в документации на один из сигнальных процессоров также указано, что изготовитель гарантий не несет!
    
    Не нравится - не покупай. В этом есть что-то бандитское...
22. Группа пользователей Интернета из Южной Кореи хочет подать в суд на компанию Microsoft. По мнению истцов, эта компания должна нести ответственность за эпидемию очередного вируса. Этот червь, используя "дыру" в ПО Microsoft, атаковал серверы под управлением SQL Server и стал причиной серьезных проблем пользователей сети во многих странах мира. По мнению представителей группы, компания Microsoft должна нести ответственность за ущерб, возникший из-за ошибок в ее продуктах. Судиться хотят уже почти 3000 пользователей.
    
    
    Газета "Деловой Петербург". 5.02.2003
23. Мне на ум приходят только три вещи, которые создаются без разработки проектной документации: дети, романы и программы.
    
    Использование чертежей не зависит от серийности - платье и дома обычно шьется не кое-как, а по выкройкам.
    
    
    А.А. Шалыто
24. Почему на аппаратуру выпускается "море" подробной и внятной проектной документации, в которой специалист средней квалификации может сравнительно просто разобраться и при необходимости изменить ее даже через много лет после выпуска, а для программ такая документация либо вовсе не выпускается, а если она создается, то обычно написана для "отбытия номера" и для ее корректировки требуется специалист более высокой квалификации, чем ее разработчик?
    
    Мои ответы на этот вопрос состоят в следующем.
    
    Во-первых, аппаратуру разрабатывают одни люди (организации, подразделения), а изготавливают - другие. Поэтому при некачественной документации разработчик проведет на "заводе" остаток жизни, что ему явно не хочется. При создании программ имеет место другая ситуация, так как в это случае обычно разработчик и изготовитель программ одно и тоже лицо, и поэтому какую номенклатуру документов не создавай, их содержимое обычно является весьма поверхностным.
    
    Во-вторых, аппаратура является "жесткой", а программа - "мягкими". Это упрощает внесение изменений в программу, но не является основанием для того, чтобы вовсе не выпускать проектную документацию.
    
    
    А.А. Шалыто
25. Практически ни один, даже очень толковый молодой программист не умеет писать проектную документацию. Несмотря на то, что многие программисты слушали и сдавали большие и сложные курсы математики, это почти никак не отражается на логике и строгости написания документации. Они, например, никак не могут по всей документации (вне зависимости от ее размеров) использовать одно и тоже обозначение, и поэтому один и тот же предмет называется, например, то лампа, то лампочка, то lamp, то с большой буквы, то с маленькой и это еще не все!
    
    Это происходит, во-первых, потому, что при программировании компилятор подсказывает несоответствия, в то время как при написании проектной документации подсказать некому, а, во-вторых, разработка программ все больше напоминает шоу- бизнес с его погоней за прибылью. Все делается в дикой спешке, не раздумывая о том, что будет с этим продуктом через некоторое время, особенно длительное. Третья причина состоит в том, что чем более закрыт (не документирован) проект, тем более незаменим его автор и тем, в конечном счете, он дороже стоит.
    
    Этот стиль работы, к сожалению, распространяется и на создание программного обеспечения для ответственных систем. Поэтому не удивителен случай, который стал недавно широко известен из литературы, когда в центре Парижа из-за отказа компьютерной системы управления в новом дорогом автомобиле чуть не погибли люди, так как кондиционер перестал работать, двери не открывались, а бронированные стекла даже снаружи удалось разбить далеко не сразу.
    
    Описанная выше ситуация в программировании была далеко не всегда - при использовании "больших" машин программы либо проектировались, либо писались очень тщательно, так как после нахождения ошибки следующий "заход" на машину происходил обычно не ранее, чем через сутки.
    
    
    А.А. Шалыто
    
    
    PS. При наличии качественной проектной документации программист не сможет "управлять" менеджерами. После его увольнения на продолжение проекта можно нанять человека с более низкой квалификацией и зарплатой, а не с более высокой, как это часто имеет место в настоящее время.
    
    В конечном счете, в цивилизованной стране средний программист, не должен получать больше среднего школьного учителя.
26. Многие работы особенно студенческие (см. например, введение к книге Романовский И.В. Дискретный анализ. СПб.: БХВ-Петербург, Невский Диалект, 2003) "лежат" в Интернете в соответствии с лицензией AS IS (КАК ЕСТЬ, без ответственности за ошибки).
    
    Это не относится к работам, "выложенным" на настоящем сайте в разделе "Проекты". При создании проектов мы очень старались. Написание каждой из них требовало десятков часов. Это свидетельствует о том, что разработка качественной проектной документации в программистском шоу-бизнесе вряд ли привьется.
    
    Но, слава богу, есть и другие области программирования и появляются другие люди, которым нравятся программы с хорошей документацией.
    
    Один из студентов, впервые увидев проектную документацию, разработанную на основе предлагаемого подхода, воскликнул: "Она лучше, чем на телевизор! Видимо, она такая же, как для подводной лодки".
    
    
    А.А. Шалыто
27. Программное обеспечение с обстоятельной открытой проектной документацией, в которой программная документация является лишь составной частью, может рассматриваться в качестве новой разновидности паттернов проектирования, которое позволяет достаточно просто оценить как достоинства, так и недостатки выполненного проекта. Рефакторинг (изменение структуры программы без изменения ее функциональности) или ее перепроектирование при необходимости в этом случае может быть выполнено значительно проще, чем даже в случае наличия открытых исходных текстов.
    
    В разделе "Проекты" приведено документация на систему управления танком для игры "Robocode". Как отмечено, в разделе "О нас" этот танк, во-первых, неплохо сражается, а, во-вторых, полностью документирован. Поэтому, когда перед Д.В. Кузнецовым встал вопрос о выборе танка для целей обучению программированию, он выполнил рефакторинг нашего, а не другого из сотен известных танков.
    
    Такая же ситуация имеет место и для другой, еще более известной программистской игрой "Террариум". Известны сотни разработанных существ, но проектную документацию разработали, похоже, только мы одни.
    
    Из изложенного следует, что если мир начал движение в сторону открытых исходных текстов, то будем надеяться, что со временем будет разрабатываться и открытая проектная документация. Это позволит отказаться от мучительного чтения чужих программ, заменив его рассмотрением проектной документации, а когда захочется "пошевелить" мозгами, то вместо чтения программ можно будет, например, взяться за решение японских кроссвордов.
    
    
    А.А. Шалыто
28. Недавно я был свидетелем как один выдающийся программист (участник финалов двух командных чемпионатов мира по программированию АСМ) в течении весьма продолжительного времени не мог понять программу из шести строк на языке Си, про которую было известно какую задачу она решает.
    
    Это очередной раз подтвердило, что движение за "открытые исходные тексты" ("открытые исходники") - "Open Source Software" - не обеспечивает даже в этом простейшем (относительно реальных проектов) случае решения проблемы понимания программ.
    
    К счастью, так думаю не только я. Безруков Н. (ведущий аналитик корпорации BASF, профессор университета Fairleigb Dickinson (NJ), веб-мастер www.softpanorama.org - OpenSource Software) в статье "Повторный взгляд на "собор" и "базар" //BYTE/Россия. 2000, N8 пишет: "Центральным вопросом в практике программирования является вопрос о понимании программных текстов. Всегда хорошо иметь исходники, но проблема состоит в том, что зачастую этого недостаточно. Чтобы понять некоторую нетривиальную программу, обычно требуется дополнительная документация. Эта потребность растет экспоненциально с ростом объема кода. Реконструкция программного обеспечения, то есть анализ текстов программ, направленный на восстановление первоначальных проектных решений, принятых разработчиками, и понимание программ являются двумя важными ветвями технологии программирования, существование которых неразрывно связано с недостаточностью исходных текстов для понимания программ. В качестве примера попробуйте понять структуру нетривиального компилятора, не располагая определением языка, который им компилируется. Любая большая и сложная программа часто имеет что-то типа встроенного языка или коллекции подпрограмм, которые имитируют некую абстрактную машину. Следовательно, исходные тексты - лишь одна из важных частей сложной инфраструктуры и базы знаний, используемой в крупных программных проектах.
    
    Реальная проблема - это понимание программ. Всегда неплохо иметь исходники, но проблема состоит в том, что этого недосточно.
    
    Каждый, кто участвовал в крупном проекте по реконструкции программного обеспечения, навсегда запомнит чувство беспомощности и потерянности, которое испытываешь, когда впервые видишь гору плохо документированных (но не всегда плохо написанных) исходных текстов. Доступность исходных текстов не сильно поможет, если отсутствует доступ к ключевым разработчикам. Если программа написана на сравнительно низкоуровневом языке типа языка C и плохо документирована, то все основные проектные решения обычно растворяются в деталях кодирования и требуют реконструкции. В таких ситуациях ценность документации более высокого уровня, такой как спецификация интерфейсов и описание архитектуры, может превышать ценность самого исходного текста.
    
    Такое осознание неадекватности исходных текстов для понимания программ привело к попыткам объединить код и документацию более высокого уровня. Одна из наиболее известных попыток такого уровня была предпринята Д.Кнутом в книге "Грамотное программирование" (Literate Programming. Stanford: Center for the Study of Language and Information, 1992).
    
    Возможно, самой известной запрещенной книгой в истории компьютерных наук была книга Lions J. Lions' Commentary on Unix: With Source Code, которая содержала высокоуровневое описание исходных текстов Unix наряду с используемыми алгоритмами. Она нелегально копировалась и распространялась в течение более чем двадцати лет с момента ее первой публикации в 1977 году.
    
    Сложность и объем фактически "закрывают" исходные тексты при условии отсутствия документации высокого уровня и если вы не принимали личного участия в проекте с его ранних стадий.
    
    Понимание "доисторического" кода при отсутствии первоначальных разработчиков или адекватной документации, позволяющей понять соответствующие архитектурные решения, является, вероятно, одним из труднейших видов программистской деятельности".
29. Еще один интересный штрих. Один из наших проектов после восьмой (что далеко не рекорд) корректировки (которая привела к тому, что мой соавтор-студент, как чеширский кот, потерял улыбку), по моему мнению, можно было завершить: программа имела хороший интерфейс, нормально работала и была разработана подробная, аккуратно выполненная проектная документация, содержащая, в том числе, и исходный код.
    
    Последнее нас и "погубило", так как открытая проектная документация, как отмечалось выше, весьма наглядно демонстрирует не только достоинства, но и все недостатки программы.
    
    Один выдающийся программист (призер чемпионатов мира по программированию) взглянул на код программы, и студент вновь начал переделывать проект. Это (с перерывами) продолжается уже более полугода (выполнено еще несколько корректировок), и я надеюсь, что хотя бы в этом проекте (игра "Морской бой") все будет прекрасно: и душа (программный код), и тело (документация), и мысли (работа программы). При этом отметим, что все это происходит после того, как зачет по проекту был давно получен.
    
    На основе этого примера можно себе представить, как выглядят программы и документация на них, если они выполнены по лицензии AS IS.
    
    
    А.А. Шалыто
30. В большинстве случаев хороша не та технология, которая действительна хороша, а та, которая выгодна.
31. Существуют ли какие-нибудь достойные свободные программы, вид которых не вызывает отвращения? До сих пор, несмотря на обилие свободного кода, нормальных программ среди него ужасно мало.
    
    
    Протасов П. Снизу //Компьютерра. 2003. N19
32. То, что не специфицировано формально, не может быть проверено, а то, что не может быть проверено, не может быть безошибочным.
    
    
    Зайцев С.С. Описание и реализация протоколов сетей ЭВМ. М.: Наука, 1989.
    
    
    
33. Если нет спецификации, то нет и ошибок.
    
    
    Аллен Э. Типичные ошибки проектирования. Сб.: Питер, 2003
34. Протоколы (история вычислений) являются конструкциями, вскрывающими механизм работы программы, и поэтому постепенно среди теоретиков программирования складывается представление, что множество протоколов лучше характеризует программу, нежели сам исходный программный текст.
    
    
    Ершов А.П. Смешанные вычисления //В мире науки. 1984. N6.
35. Что есть работа и почему люди занимаются ей?
    
    Работа обеспечивает потребности (выживание) отдельных людей и социальных групп. Работу можно рассматривать как воплощение инициативы, как сферу приложения энергии, форму жизненной силы. Это сила, скрепляющая общество. Это способ приложения энергии людей, способ наполнения нашей жизни, путь к достижению бессмертия. Работа - камертон нашей жизни. Работа - связующая сила цивилизации и сфера выражения индивидуальности, обеспечивающая широкие возможности для проявления творческих потенций. Работа должна обеспечить самовыражение человека.
    
    Та степень, в которой человек накладывает на работу отпечаток своей индивидуальности и придает ей качества своего разума и духа, является мерой его успеха в деле свободного и полного выражения своей природы.
    
    В ходе индустриализации повышалась производительность труда, и одно из последствий этого процесса состояло в том, что рабочие повсеместно теряли не нужную на рабочих местах квалификацию и выход творческой энергии вынуждены были искать в сфере досуга.
    
    В наши дни работники, как правило, требуют, чтобы в их работе был какой-то смысл, какая-то возможность самореализации, хотя мало кто стремится полностью реализовать себя на рабочем месте - для того, чтобы жить полной жизнью требуется спорт, искусство и другие любимые занятия.
    
    В профессии разработчика программного обеспечения есть какой-то изначально ей присущий неотъемлемый элемент творчества, а это именно то, что делает труд человечным. Может быть реализован инстинкт мастера своего дела - свобода выполнять работу в собственной неповторимой манере. Обычные рабочие потеряли эту свободу еще в доинформационную эру.
    
    Три категории человеческой деятельности:
    
    
    • теоретизирование (знание);
    • поэтика и ремесло (творческая работа);
    • практическая деятельность (обычна работа).
    Имеет место триада "знания - творчество - практика"
    
    Все эти три формы деятельности присутствуют в труде программиста в сочетании, которое подчеркивает лучшие стороны каждой из них. Это обеспечивает возможность самовыражения человека. Это также позволяет человеку выполнить полезную общественную функцию.
    
    Истинным революционером является инженер - именно он, изучая процессы, изменяет способы выполнения работы, и эти изменения влекут за собой перемены во всей нашей жизни.
    
    Революционеры нашей эпохи - инженеры-программисты.
    
    В последнее время часто используются методы "шустрой разработки" (agile). Это новый модный термин, обозначающий разработку силами небольших групп специалистов-ремесленников, предполагает использование проверенных методов, которые часто вызывают в памяти таких авторов, как Фредерик Брукс и Том Де Марко, Гради Буч и Кент Бек (Cockburn A. Agile Software Development. Addison-Wesley, 2001).
    
    Независимо от того, каким образом программные средства будут организованы в будущем, они уже изменили весь окружающий нас мир.
    
    Программное обеспечение играет центральную роль в поддержании целостности общества.
    
    Важнейшие задачи: в теории - уяснение природы процессов разработки программ; на практике - подготовка спецификаций.
    
    
    Кьюсак Д. О том, как труд профессионалов в области ПО изменяет мир //Открытые системы. 2003. N6.
36. Говорят, что язык "Java" его создателями предназначался для того, чтобы писать на нем управляющие программы для бытовых устройств - стиральных машин, кофеварок, чайников и т.д. Поэтому, дескать, и название.
    
    И вот теперь на базе языка "Java" в Sun Microsystems создали новый язык специально для "чайников", тех, кто вовсе не умеет программировать.
    
    Язык "Ace" предполагает, что код будет представляться графически, в виде экранных диаграмм.
    
    Надо сказать, что средства графического программирования предлагались и прежде. Особого успеха их создатели не снискали. Так или иначе, в Sun преисполнены оптимизма, полагая, что Ace даст возможность уменьшить стоимость и сложность разработки приложений, упростит их перенос на новые платформы.
    
    
    Открытые системы. 2003. N6.
37. Когда я возмутился тем, что единственный отечественный весьма доступный (во всех отношениях) профессиональный журнал по программированию "Программист", закрылся, один выдающийся студент-программист сказал:
    - А, что там было читать?
    
    На что я ответил:
    - А, что ты туда написал?
    
    На этом наша обсуждение закончилось, а писать статьи о программировании в России практически некуда, и это при буме программирования в стране. Многим журналам почему-то больше нравится публиковать рекламу - либо прямую, либо косвенную, в том числе и по программированию.
38. Значительное событие в развитии методологии программирования - появление технологии разработки программ, управляемой моделями, так называемый model-driven architecture (MDA), зародыши которой можно видеть в CASE-системах.
    
    Речь идет о двунаправленном взаимодействии графического и кодового представления программы, благодаря которому достигается повышение эффективности разработки приложений.
    
    Есть реализация MDA для Delphi.
    Дубова Н. Вместе с Borland //Computerworld Россия. 11.03.2003.
39. Дело математики - по Ломоносову - ум в порядок приводить.
    
    Дело информатики - приводить мир в порядок.
    Плаксин М.А. Информатика. 2003. N1.
40. Национальная информационная безопасность диктует неотложность наведения порядка в используемом силовыми структурами ПО: переход на открытые исходники - один из возможных вариантов.
    
    Необходима национальная программа по развитию систем с искусственным интеллектом (робототехники).
    Пройдаков Э.М. PC WEEK. 2003. N10.
41. Компания "SPIRIT" (президент - Андрей Свириденко) - одна из немногих российских компаний, специализирующихся на разработках передовых технологий для мирового рынка.
42. Как встречают архитектуру MDA (Model Driven Architecture - архитектура, основанная на модели) разработчики?
    
    В крупных компаниях она прививается быстро, а в мелких - медленнее. Раньше модель не имела никакого отношения к способу ее реализации.
    
    Подход, основанный на моделях, позволяет создавать не плакат, прикрепляемый на стену и игнорируемый разработчиками, а некую основу для реальной генерации программного кода.
    
    Если программа будет автоматически генерироваться по модели, так что разработчику не придется учитывать особенности конкретных инфраструктур, форматов данных, способов их преобразования и т.д., а нужно будет лишь запрограммировать прикладную логику, это станет для всех большой победой.
    
    MDA переводит разработку приложений в новое качество //PC WEEK/RE. 2003. N9.
    
    PS. Прикладную логику можно запрограммировать, в том числе сгенерировав ее, на основе автоматного программирования.
43. Теорема Райса и "Движение за открытую проектную программную документацию" - "Stream for Open Project Software Documentation"
    
    Проектная документация необходима, так как из теории алгоритмов известно (теорема Райса), что, в общем случае, по тексту программы невозможно алгоритмически доказать истинность никаких нетривиальных свойств вычисляемой ей функции.
    
    Для понимания программ (в отличие от их исполнения) следуя Тьюрингу, требуется "проницательность и изобретательность". Но так как анализ текстов программ все равно не поддается автоматизации, а анализ "вручную" требует колоссальных затрат времени, то кажется, что по только по тексту программы невозможно сделать выводы о ее свойствах.
    
    Однако это не так. Математики нашли решение аналогичной проблемы еще в античности. Это запись доказательства понятным человеку языком, что и отличало греческую математическую школу от древнеегипетской. В последней в качестве решения геометрической задачи предоставлялся чертеж, снабженный "пояснительной" надписью "Смотри!", что сродни представлению текста программы для определения того, что она делает.
    
    Для того, чтобы другие могли понять не только как работает наша программа, но и что она делает и каким образом она это делает, им необходимо предоставлять подробное описание (на понятном человеку даже "средней" квалификации формализованном языке) как процесса создания программы, так и ее свойств (статических и динамических), что и представляет собой проектную документацию. Она является подтверждением того, что представленная программа вычисляет данную функцию - соответствует техническому заданию.
44. Вопрос о качестве документации на программное обеспечение приобретает все большее социальное значение. Так в статье, опубликованной в газете "Известия", первым среди вопросов "о чем мы должны подумать, задолго до того как кончится нефть" является качество указанной документации.
    
    "Наиболее запомнившееся и поразившее меня при выполнении совместного проекта с фирмой IBM отличие состояло в том, как они относятся к документации. У них было принято и это соответствовало практике - что написано в документации, то так и есть, так и работает. У нас - никогда! У них из этого проистекала корпоративная уверенность в себе - на все вопросы они находили ответ в документации, утвержденной начальством.
    
    У нас не только документация плоха, ни и мысли изложить толком никто не умеет. Я много раз сравнивал и х доклады и наши "доклады". Однажды мы пригласили одного из лучших переводчиков. Он потом извинялся, что не смог толком перевести на английский, но я его успокоил, что на русском-то ничего не понял...
    
    Этому нужно научиться. Эту часть работы следует любить и уважать".
    Скрипников А. Когда кончится нефть //Газета "Известия". 09.09.2003.
    PS. Несомненно, что у н и х с документацией не так все хорошо, как говорит автор, но тенденция просматривается...
45. Питер Кодд из TogetherSoft предпочитает дизайн-ориентированный подход к созданию систем, а фирма Borland в большей степени была ориентирована на разработку, управляемую созданием кода. Так что после приобретения TogetherSoft фирмой Borland Кодд привнес в последнюю новое важное направление - разработку, основанную на дизайне системы.
    
    Значительное событие в развитии методологии программирования - это появление технологии разработки, управляемой моделями, так называемый "model-driven architecture" (MDA), зародыши которой можно видеть в CASE-системах. Речь идет о двунаправленном взаимодействии графического и кодового представления программы, благодаря которому достигается значительное повышение эффективности разработки приложений. В Borland есть реализация MDA для Delphi.
    Спецификации MDA разрабатываются в рамках консорциума OMG Вместе с Borland //Computerworld Poccия. 11.03.2003.
46. В рамках разработки новой ОС в Microsoft проектируется новая подсистема обработки событий. Мы занимаемся ею потому, что, по нашему мнению, на предстоящем этапе главна цель - повышение управляемости. Хотим, чтобы наши разработчики аналогичным образом реализовали эту подсистему как для клиента, так и для сервера.
    Джим Оллчин. Computerworld Россия, 23.09.2003
47. У нас вчера вирус через программу "Outlook" уничтожил все связанное с почтой, а я что-то не слышал, чтобы кто-нибудь из создателей этой программы извинился или застрелился.
    А.А. Шалыто
48. Я спросил одного толкового студента почему для подводной лодки или самолета создается проектная документация, а для программного обеспечения она обычно столь подробно не разрабатывается.
    
    Он ответил, что подводную лодку или самолет, не разработав проектную документацию, в принципе не построить, в то время как программу написать можно, и поэтому при ее создании обычно выполняется оптимизация по критерию "цена/качество".
    
    На это я ответил, что при проектировании программ по этому критерию я под снижением качества понимаю меньшую функциональность, а не возможность наличия ошибок, как это считается обычно. Оптимизация по указанному критерию при наличии ошибок, по моему мнению, является просто разгильдяйством.
    
    На первый взгляд кажется, что в условиях рынка программы с малой функциональностью, например, для сотовых телефонов, мало кого интересуют, и поэтому ошибки в программах имеются практически всегда.
    
    Однако это не совсем так. Длительная эксплуатация такой операционной системы (ОС) как QNX показывает, что в ней практически отсутствуют ошибки.
    
    Очень много усилий для их устранения предпринято и при создании ОС "Symbian", предназначенной для сотовых телефонов.
    
    Для создания прикладных программ для ответственных систем все шире применяется, так называемое, синхронное программирование, использующее специальные языки программирования.
    
    Качество программного обеспечения в последнее время обсуждается все шире и шире. Так в январском номере журнала "Мир ПК" в колонке редактора Алексея Орлова написано:"Госу- дарство должна тревожить проблема ответственности производите- лей программного обеспечения за свои изделия. Раз уж мы поставлены перед фактом всегосударственной любви к одной известной фирме, то давайте хоть попробуем заставить ее, а за ней и остальные компании нести ответственность за свою продук- цию. Ведь каждое равнодушное принятие условий "безответствен- ной" лицензии - это наши деньги, вложенные в бесконечные обновления и покупки новых версий ПО. Способно же государство требовать сертификаты на мясо! В конце концов, бесконечная сказка про ... особый характер программ как товара лишь прекрывает нежелание производителей вкладывать деньги в наукоемкую разработку средств верификации программ".
49. В обсуждении статьи о "Движении за открытую проектную документацию" многие писали, что, по их мнению, самодокументирующийся код и есть документация на программу.
    
    Это тоже самое, что утверждать, что схема электрическая принципиальная - вся документация на систему.
    
    В общем это большое недоразумение. "Один из пионеров авиации Д. Дуглас, говорил, что "когда вес документов достигнет веса самолета, он начнет летать", а Д. Мартин утверждает, что "документация для "Боинга-747" весила больше, чем самолет". То же самое относится и к программному обеспечению, а где это не так - разработки неуправляемы" (Фокс Дж. Программное обеспечение и его разработка. М.: Мир, 1985). С появлением новых носителей информации вес документации, естественно, уменьшается, но это сути дела не меняет, так как количество информации в документации при этом сохраняется.
50. Software is like SEX - it's better when it's FREE.
    Linux Torvalds
51. QNX Software Systems (www.qnx.com) объявила, что ее основатели, генеральный директор Дэн Додж и административный директор Гордон Белл, в разделе "Промышленный менеджмент и технологии" журнала "Fortune" названы героями промышленности.
    
    Это ежегодная рубрика отмечает жителей Северной Америки, оставших наиболее яркий след в мировой индустрии. Додж и Белл удостоились этого почетного титула за создание ОСРВ QNX Neutrino.
    PC Week/RE. 2003. N 10.
52. В "Движении за открытую проектную документацию" результат (документация) - свободна, однако способ ее изготовления - не свободный, так как студенты делают документацию "из под палки".
53. Проектная документация должна быть понятна среднестатистическому "чайнику". Тогда и среднестатистический программист на одиннадцатом часу работы тоже сможет понять ее.
    
    Для этого документация должна создаваться с позиций "чайника", который, желательно, чтобы при этом сидел рядом с вами.
    
    Такой процесс (по аналогии с экстремальным программированием) может быть назван "экстремальное написание проектной документации".
54. Понятие "объектный код" не связано с объектно-ориентированным программированием.
55. О настоящем сайте. Здесь ничего нельзя украсть (кроме авторства), а можно сославшись, все взять бесплатно.
56. Статья 48-2 закона «Об авторских и смежных правах» запрещает удалять с продукта указание его авторства, что часто делается недобросовестными пользователями в Интернете.
57. На долю штата Карнатака, на территории которого находится технологический центр Бангалор, приходится 36% экспорта всего индийского софта. За последний финансовый год его объем вырос на 46% — 3,85 до 5,63 млрд. долл. Рост экспортных поставок ПО оказался столь быстрым, что уже привел к нехватке программистов. В новом году ожидается более чем 30% рост экспорта ПО.
    
    Интересно, что разработкой ПО в Бангалоре занимается все больше иностранных предприятий. В прошлом году здесь открыли бизнес 168 фирм, инвестировавших 748 млн. долл. Сегодня в Бангалоре размещены офисы свыше 1100 международных и индийских компаний. Здесь трудится около 110 000 программистов и 60 000 специалистов в области аутсорсинга.
    
    Пока многие страны еще только соображают, как стать э-державами, корейское правительство поставило задачу к 2007 г. превращения государства u-Korea. Приставка «u» возникла от прилагательного ubiquitous (вездесущий, повсеместный). При этом для реализации этого проекта предложена стратегия «8 — 3 — 9».
    
    Она предполагает развертывание восьми новых сервисов (мобильный Интернет, телематика и т.д.), создание трех инфраструктур (системы связи новых поколений) и развитие девяти основных направлений (цифровое телевидение, роботы, встраиваемое ПО и т.д.).
    
    Тайвань превратился из мирового производственного центра в центр исследований, разработок и производства.
    Максимов А. Восточный экспресс //PC WEEK/RE. 2004. N23.
58. Компания VALinux ведет онлайн-репозитарий открытого ПО под названием SourceForge (http://sourceforge.net).
59. Продолжается соревнование на рынке двух конкурирующих изделий при автоматизации технологических процессов: программируемых логических контроллеров (ПЛК) и промышленных компьютеров (ПК).
    
    Еще несколько лет даже рыночные аналитики утверждали, что ПК постепенно заменят ПЛК. Однако в конце концов они отказались от этого сценария.
    
    Объемы продаж ПЛК растут, и, похоже, они пришли, чтобы остаться.«Собака не берет след», — вот ответ всем аналитикам, предсказывающих победу ПК.
    
    В фирме «Омрон» (Япония) не считают, что ПК вообще когда-либо заменят ПЛК. Они стали применяться в новых приложениях, в которых раньше не применялись, например, в устройствах защиты. ПЛК являются устойчивыми платформами и обладают готовностью к более длительной эксплуатации, по сравнению с ПК.
    
    С этим соглашается фирма «Rockwell Automation». «До сих пор управление на основе ПК не было ориентировано на потребности конечных пользователей, которым необходима надежность, долговечность и простота применения, а ПЛК предлагают эти три свойства в изобилии».
    
    ПЛК по-прежнему имеют упрощенное программирование и это очень существенно для промышленной автоматизации. Появился даже новый термин «программируемый контроллер для автоматизации» (programmable automation controller — PAC).
    Промышленные АСУ и контроллеры. 2004. N7.
60. Верно определяйте слова, и вы освободите мир от половины недоразумений.
    Рене Декарт
61. Бертран Мейер, создатель языка программирования «Effel», хорошо говорящий по-русски, сначала сказал, а потом написал на доске, что программы пишутся на АВОСЬ.
62. Границы моего языка есть границы моего мира.
    Людвиг фон Витгенштейн
63. Лучше выцветшие чернила, чем отличная память.
    Китайская пословица
64. Дилемма заключенных (The Prisoners’ Dilemma) как модель стратегии нанесения первого ядерного удара.
    
    Два заключенных содержатся отдельно и им предлагается следующая сделка: «Если никто не сознается, вас обоих освободят. Если вы оба сознаетесь, то получите большие сроки. Если сознается только один, то он получит маленький срок, а другой — в два раза больше.»
    
    В этой ситуации оба могут сидеть большой срок, хотя могли бы не сидеть вовсе.
65.  — В чем разница между террористом и автором методологии? — С терристом иногда можно договориться.
    М. Фаулер
66. Технологии верификации позволяют проектировщику микросхем проверить, что результат реализации его проекта будет именно таким, как он задумал, а специалисту по маркетингу убедиться, что проектировщики сделали то, что от них требовалось.
    
    Эти технологии очень сложны, например, в Intel над ними работало порядка тысячи (!) человек.
    Майкл Фистер, руководитель компании «Cadence». PCWeek/RE. 22 марта 2005 г.
67. В моем представлении А.П. Ершову ближе всего подходит образ Дон Кихота Ламанчского. Но не в упрощенном бытовом восприятии как чудака, борющегося с ветряными мельницами компьютерного образования, а как благородного странствующего рыцаря, который с гордостью мог сказать: «Я вступался за униженных, выправлял кривду, карал дерзость, побеждал великанов и попирал чудовищ».
    
    Последние рыцари уходят. И заменить их уже некем… Богатырев  Р. Календарь истории. Портреты великих. Мир ПК. 2005. N4.
68. Если исходные коды открыты, то наличие плохо выполненной документации бывает хуже ее отсутствия, так как число вопросов увеличивается. Как говорили при Сталине: «Есть человек — есть проблема, нет человека — нет проблемы».
69. Мне часто приходит на ум, что надо придумать какой-нибудь типографирческий знак, обозначающий улыбку, — какую-нибудь закорючку или упавшую навзничь скобку…
    Владимир Набоков
70. Запомнить имя файла легко, вспомнить трудно.
    Б. Вольтер
71. Просто программировать легко, а вот программировать легко и просто — гораздо труднее.
    А. Черномырдин
72. Мы делаем средства разработки для корпорации Samsung. Разработка сопровождается огромным количеством документации - просто титанические объемы, тома, в которых раскрывается, как работает изготовленное нами средство. Потом сотрудники корпорации Samsung приезжают к нам, и наши разработчики все им рассказывают и показывают.
    П. Васильев, генеральный директор компании «АстроСофт». Компьютер-информ. 2006. N3, с.14,15.
73. Экономия от внедрения готовых коммерческих систем составляет в США до 80% от объема затрат, необходимого для разработки оригинального ПО для военных применений.
    
    Одна из основных проблем сертификации таких систем заключаются в высокой трудоемкости анализа исходных текстов.
    
    Согласно статистике по сертификации критически важных систем в 100% из них сопроводительная документация нуждается в улучшении.
    PC Week/RE. 2006. N3
74. Программная инженерия на протяжении десятилетий идет путем повышения уровня абстракции, выходя за пределы текстовых языков.
    
    В приложениях всегда главным считался код, но сегодня одного только кода мало. При этом традиционным текстовым языкам не хватает средств для того, чтобы оценивать и понимать поведение программ.
    Буч  Г. Будущее моделирования выглядит оптимистично //PC Week/RE. 2005. N42, с.23, 38
75. Для математиков решать простые задачи не интересно и непрестижно. Программисты также относятся к написанию программ, которые могут быть понятными людям с квалификацией существенно меньшей, чем у них.
76. Модели в программировании должны привязываться к реальности с помощью неформальной «силы веры». Сторонники применения формальных методов в программировании должны иметь терпение.
    Боуэн  Д., Хинчи  М. Десять заповедей формальных методов… Десять лет спустя. Computer. 2006. N1
77. Проектирование — это сознательные усилия, направленные на установление разумного порядка.
    Виктор Папенек
78. Методология — совокупность методов, правил допущений, используемых в определенной дисциплине: конкретная процедура или набор процедур.
    
    Методология — анализ принципов и процедур, применяемых при проведении исследований в определенной области.
79. Аспектное программирование — это способ формирования из модулей код, который будет воплощать сквозную функциональность вместо «размазывания» ее по всей программе.
    
    P.S. Автоматы служат для той же цели применительно к реализации поведения. А.Ш.
80. Национальную медаль за заслуги в области технологий из рук президента США получил Уоттс Хамфри (Watts Hamfrey), сотрудник Института программной инженерии при университете Карнеги- Меллона, работы которого посвящены наведению порядка в сфере разработки ПО. Он считает, что ошибки многих программ объясняются изъянами в образовании и дисциплине разработчиков. По его мнению, для борьбы с нынешним хаосом при разработке ПО достаточно воспользоваться методами, зарекомендовавшими себя в других областях индустрии.
    Компьтерра. 2005, #583
81. Согласно правилам, принятым в британских вооруженных силах, полеты на новых самолетах и верталетах можно начинать лишь после того, как специальным исследованием будет уставлено, что оно безопасно.
    
    Однако после покупки восьми военных вертолетов возникла непреодолимая проблема, так как пункт о предоставлении текстов программ в явном виде в контракт не вошел, а когда их попытались получит позже, корпорация Boeing ответила отказом, заявив, что «не готова» к этому по соображениям безопасности. Эта история тянется с 2001 года, а вертолеты стоили почти полмиллиарда долларов.
    Компьютерра. 2005, #585
82. Пользователи очень редко читают документацию, потому что знают, что обычно очень плохо написана.
83. Конек корпорации SAP — это глубокое знание бизнес-процессов. Однако, если попытаться отыскать эти знания в нашем ПО - а это сотни миллионов строк кода, — окажется, что места, в котором было бы сосредоточено все относящееся к бизнес-процессам, просто не существует.
    
    Мне представляется, что в перспективе бизнес-процессы найдут свое воплощение в хорошо спроектированных программных компонентах. Все модели здесь будут описаны явно. В них смогут разобраться представители самой широкой аудитории, а не только знатоки С++. Сегодня это приобретает все большее значение.
    Айк Насси, старший вице-президент лаборатории SAP Labs по научным исследованиям, сыграл ключевую роль в разработке языка Ada. Еженедельник «Computerworld Россия». 19.09.2006
84. Когда мир столкнулся с проблемой 2000 года, то казалось, что через пять-шесть лет весь мир будет полностью объектно-ориентированным, но это оказалось не так, и в настоящее время в мире более одного миллиона программистов пишут программы на Коболе.
    Computerwold Россия. 30.01.2007
85. Программисты меньше всего приспособлены к тому, чтобы создавать программы для неопытных пользователей.
86. Некоторые компании воспринимают General Public Licence (GPL) как отсутствие лицензии вообще. Мол, исходный текст программы свободен, и поэтому бери его и делай с ним все, что душе угодно.
    
    На самом деле это совершенно не так. Открытый стандарт накладывает довольно жесткие ограничения на использование кода. И их нарушения чреваты судебным разбирательством.
    
    Главное требование - пользователь открытого кода обязан полностью опубликовать код, котором заимствование использовано.
    PC WEEK/RE. 2007. N2, с.8
87. У нас недавно представители одной огромной фирмы в течение часа рассказывали какие их инновации в области аппаратных решений контроллеров появятся на рынке в этом году.
    
    О том, как лучше писать программы для программируемых контроллеров, они ничего не сказали.
    
    Такая ситуация имеет место уже не первый год.
88. В середине 60-х годов в индустрии программного обеспечения наступил "кризис программирования" - выяснилось, что классическая схема разработки, состоящая из трех основных этапов (написание кода, компиляция и отладка), при создании сложных систем становится неэффективной. При этом сложность программ и вычислительная мощность компьютеров пришли в противоречие с технологическими возможностями программирования.
    
    Усилия, направленные на преодоление этого кризиса, привели к созданию новой дисциплины, названной "программной инженерией". При этом, в частности, для повышения производительности труда программистов начали разрабатываться инструментальные средства.
    
    В 1968 году в Гармиш-Партенкирхине (Германия) состоялась организованная комитетом по науке НАТО конференция, которую считают моментом рождения программной инженерии.
    
    Термин "Software Engineering" в том же году предложил Фредерик Бауер.
    
    Программирование губит иллюзия простоты и вседозволенности.
    
    Даже уже в 1999 году Фредерк Брукс при вручении премии Тьюринга сказал: "Мы не знаем, что делаем, и не знаем, что сделали".
    
    Хроника (начало - 1986 год) неприятностей, связанных с программированием, приведена в http://catless.ncl.ac.uk/Risks.
89. Два выпускника академии ВВС США Пол Леви и Майк Девлин в 1981 году решили создать собственную компанию, которая в дальнейшем была названа Rational Software (в начале Rational Machines). Это компания с 2003 года вошла в cостав IBM.
    
    Принятому решению предшествовал почти двадцатилетний период участия в оборонных проектах, из которых они вынесли твердое убеждение в необходимости разработки средств, рационализирующий процесс создания программного обеспечения, что отразилось в названии компании.
    
    В 1990 году был запущен проект - разработка средств моделирования, основанных на графической нотации, предложенной Гради Бучем. В 1995 году в компанию пришел Джеймс Рамбо, а затем у фирмы Ericsson была куплена шведская компания Objectory Systems, основанную Айваром Якобсоном в 1987 году. В 1995 году их совместными усилиями появился язык Unified Modeling Language (UML).
    
    В дальнейшем центром, курирующим UML, стал консорциум Object Management Group (OMG).
90. Мы делаем средства разработки для корпорации "Samsung". Разработка сопровождается огромным количеством документации, - просто титанические объемы, тома, в которых раскрываются, как работает созданное нами средство.
    Васильев П. Генеральный директор компании "АстроСофт". Компьютер- Инфо. 2005. N20
91. Участники третьей конференции по встраиваемым системам "Embedded Software Summit" единодушно согласились с необходимостью развития системы независимой сертификации программных систем двойного назначения.
    
    Основная сложность подобной сертификациизаключается в высокой трудоемкости анализа исходных текстов продуктов и тестированием всех возможных уязвимостей. Согласно статистике 100% сертифицируемых систем и документации на них требовали доработки.
    PC WEEK/RE. 2006. N3
92. Программирование часто сводится к формуле: "отредактировать, откомпилировать, отладить" ("edit, compile, debug").
    
    Продолжающееся использование термина "отладка" является доказательством того, что процесс программирования в сущности за поседние годы не изменился.
    PC WEEK/RE. 2007. N10
93. Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям.
    Фаулер М. Рефакторинг. СПб.: Символ. 2003
94. Когда на производстве, в каком-то технологическом цикле хорошая математика есть, этого никто не замечает, когда ее нет - проблемы очевидны всем.
    Академик РАН Н.Н. Красовский
95. Переход от неформального к формальному существенно неформален.
    М.Р. Шура-Бура
96. Серьезная проблема при переходе в область наноэлектронных устройств - уменьшение рассеиваемой энергии в процессе вычислений.
    
    Идея о возможности "логически обратимых" операций, которые не сопровождаются рассеянием энергии, впервые высказал Р. Ландауер еще в 1961 году.
    
    Существенный шаг в решении этой задачи был сделан в 1982 году Ч. Беннеттом, который теоретически доказал, что универсальный цифровой компьютер может быть построен на логически и термодинамически обратимых вентилях таким образом, что энергия будет рассеиваться только за счет необратимых периферийных процессов ввода информации в машину (формирование исходного состояния) и соответственно вывода из нее (считывание результата).
    
    К обратимым универсальным вентилям относятся вентили Фредкина и Тоффоли.
97. Задача разложения целого числа на простые множители не по силам современным компьютерам, так как она имеет экспоненциальную сложность.
    
    Если требуется разложить на простые множители число x, имеющее n знаков в двоичной записи, то очевидный способ решения состоит в том, чтобы попробовать последовательно разделить на числа от двух до корня из n. При этом перебирается два в степени n/2 вариантов.
    
    Если число содержит 100000 двоичных знаков, то требуется перебрать 3x10 в степени 15051 вариантов.
    
    Существует алгоритм, решающий эту задачу за exp (n в степени 1/3), но при миллионе знаков опять возникает непреодолимая проблема.
98. Идея использования квантовых вычислений впервые была высказана советским математиком Ю.И. Маниным в 1980 году в книге "Вычислимое и невычислимое". Правда, интерес к его работе возник лишь два года спустя, в 1982 году, после опубликования статьи на ту же тему американского физика-теоретика Ричарда Фейнмана.
    
    Скорее всего, моделирование квантовой механики является экпоненциально сложной математической задачей.
    
    В 1985 году Дэвид Дойч предложил математическую модель квантового компьютера.
    
    В 1994 году Питер Шор предложил для квантового компьютера алгоритм разложения n-значного числа на простые множители за время, полиномиально зависящее от n (квантовый алгоритм факторизации). После этого появились алгоритмы, позволяющие решать некоторые NP-проблемы.
    
    В настоящее время известен квантовый компьютер, составленный из семи кубитов. Этого достаточно, чтобы разложить число 15 с помощью алгоритма Шора.
    
    Первый квантовый компьютер, который был создан на практике, - это импульсный ядерный магнитно-резонансный (ЯМР) спектрометр высокого разрешения, хотя он исходно как квантовый компьютер не рассматривался. На нем осуществлены квантовые операции с числом кубитов до семи.
99. В 1985 году была опубликована статья Р. Боэма "Спиральная модель разработки программного обеспечения", посвященная итеративной разработке программ.
    
    В начале 90-х годов Д. Сазерленд и К. Швайбер изобрели и начали использовать в компании "Easel Corp." методологию, которую назвали Scrum. Она основана на подходе, который использовался в таких компаниях, как Honda, Canon и Fujitsu. Для этой методологии характерны 30-ти дневные итерации, называемые спринтами, и самоорганизация команд. При этом ежедневно проводятся 15-минутные собрания, на которых каждый член команды рассказывает, что он делал вчера, что будет делать сегодня и что ему мешает. Первая публикация по этой тематике появилось лишь в 1999 году.
    
    В середине 90-х годов компания Rational начала разработку методологию Rational Unified Process, в основу которой были положены итеративность и инкрементность разработки. Она включает набор некоторых "лучших практик" софтверной разработки на все случаи жизни.
    
    В 1994 году группа людей, использующих Rapid Application Development, собрались, чтобы обсудить описание стандартного итеративного процесса. Позже это описание трансформировалось в методологию DSDM (Dynamic systems Development Method), которая и сегодня популярна на ее родине - в Великобритании.
    
    В 1996 году к проекту Chrysler C3, который к тому времени был практически провален, присоединился Кент Бек. Он вместе с Роном Джеффрисом использовал все известные ему на тот момент практики и пришел к выводу, что их совместное применение весьма эффективно. Эта методология была названа "Extreme Programming" (XP - экстремальное программирование). Она быстро получила известность, так в ней упор сделан на простоту, раннее тестирование, а также ввиду провакационного названия.
    
    В 1997 году Питер Кодд и Джефф де Люка подключились к безнадежному проекту по построению большой логистической и успешно справились с ним за счет применения практики интерактивной разработки, который они назвал Feature Driven Development (FDD).
    
    В феврале 2001 года 17 разработчиков методологий, в том числе и некоторых из перечисленных, для того обнаружит что-нибудь общее в этих подходах. Тогда же появился термин Agile (гибкий, шустрый), объединивший указанные методологии.
100. Открытые методы разработки коммерческого ПО - очередная значительная инновация в деле решения сложных инженерных задач, требующих сочетания принципов творчества и сотрудничества.
     Дэнни Саббах, генеральный менеджер IBM Rational Software
101. При использовании эволюционных методов не требуется точно указывать как решать задачу. Вместо этого достаточно ее сформулировать в терминах некоторой "цели" и "допустимых затрат", программа будет создана самой вычислительной системой в ходе эволюционного процесса. Высказывание: "машина никогда не знат больше программиста при этом оказывается просто неверным".
     Фогель Л., Оуэнс А., Уолш М. Искусственный интеллект и
     эволюционное моделирование. М.: Мир. 1969.
102. Проект был не совсем открытым - документация в нем была написана на японском языке.
103. МО США, запретив военнослужащим вести блоги и обмениваться э-письмами без разрешения специального отдела, наложило вето и доступ к социальным сетям через служебные сети, которые оказываются полностью загруженными развлекательным содержимым.
104. Корпорация "Google" и движение "Close Source"
     Фотокорреспондент журнала "Секрет фирмы" снял сидящих за компьютерами программистов, которые после этого окружили журналиста и жестко, без всяких шуток, попросили уничтожить фотографии. Программисты снимаются в холле, потому что в офисе в поле зрения объектива может попасть (о, ужас - А.Ш.) часть программного кода.
     Журнал "Секрет фирмы". 2007. N27, с.17
105. Цель, к которой надо стремиться в области распознавания текстов, была сформулирована в 1966 г.: "Мы будем говорить, что система ведет интеллектуальную обработку, когда предоставим ей текст поэмы А.С. Пушкина "Евгений Онегин" и она даст корректный ответ на вопрос: "Какое отчество было у Татьяны Лариной?" Ответ возможен, так как в тексте поэмы говорится о надписи на надгробном камне: "Смиренный грешник Дмитрий Ларин..."
     
     Прошло уже более сорока лет, и, надо признать, что мы не очень-то сильно приблизились к решению этой задачи. Это - высокая цель - интеллектуальное понимание текста системой.
     В.Л. Арлазаров, член-корреспондент РАН. Мир ПК. 2007. N9
106. Следующий этап развития должен научить системы распознавать и извлекать из документа смысл его содержания при условии, что оно заранее неизвестно. Только представьте, мы ищем статью по интересующей нас тематике, дав системе запрос в произвольной форме, а она эту статью идентифицирует из массы других и делает аннотацию на десять строк. Мечта? Пока, к сожалению, да.
     В.Л. Арлазаров, член-корреспондент РАН. Мир ПК. 2007. N9
107. Я считаю название журнала по дизайну "Проектор" гениальным. Само слово "проект" является ключевым в тех процессах, которые происходят в сфере дизайна и виртуального искусства. Проектное мышление - один из постулатов, на котором держится профессия дизайнера. Проектор - то, что выхватывает из темноты, проецирует, освещает.
     Харшак, главный редактор
108. Программирование должно еще в школе преподаваться не как искусство, а как инженерная дисциплина.
109. В университетах мы должны учить чистым, прозрачным и передаваемым вещам. При этом язык должен быть на заднем плане. Это не главная тема обучения. Важно, что обучение мышлению в программировании не должно осуществляться с помощью того или иного языка.
     Никлаус Вирт
110. Когда пишешь код, думай о тесте. Когда пишешь тест, думай о коде. Когда думаешь о коде и тесте как о едином, тестирование просто, а код красив.

     Запускай тесты часто. Радуйся, когда они проходят. Радуйся, когда они не проходят. Программирование с использованием тестов - это более приятный процесс, чем программирование без тестов. При Test-Driven Development - тесты средство достижения цели.

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

111. Каждая компьютерная проблема решается еще одним уровнем абстракции.
     Дэвид Уиллер
112. Сейчас на рынке ПО остро не хватает кадров. Но охота при этом идет не на отдельных программистов, а на дееспособные команды хотя бы из трех человек!
     Секрет фирмы. 2008. № 13, с. 23.
113. Почему те, кто разрабатывает аппаратуру относится к разработке более ответственно, чем программисты? Это, видимо, связано с тем, что аппаратура отсутствие проекта не прощает – может сгореть, а в программировании можно соединять все подряд – просто не будет работать!
114. Программисты высокого класса называются неправильно – они решатели задач, а не кодировщики чужих алгоритмов.
115. Переход от неформального к формальному существенно неформален.
     М.Р. Шура-Бура
116. «Экспресс – тренинг. Искусство жить. Техника достижения желаемого». Управляй своим состоянием. Обеспечение состояний комфортности, уверенности и свободы.
     Реклама на столбе