А.А. Шалыто
PS. Кстати, в археологии тоже нельзя копать, как и где бог на душу
положит, так как при этом могут быть большие неприятности.
Криницкий Н.А. Алгоритмы вокруг нас. М.: Наука, 1984.
Как девчонка с косой
За речною косой
Травы косит косой.
Михаил Митрейкин
Прочел у Карпова Ю.Г.
P.S. Кто, кого сменит?
Прочел у Карпова Ю.Г.
PS. У кого или где цветы?
Фаулер Мартин. Новые методологии программирования//www.spin.org.ua
Все это приводит к тому, что даже "пользователи не считают ошибочное программное обеспечение чем-то из ряда вон выходящим"
Буч Г. Создание будущего //Подборка статей на тему "Программы
следующего десятилетия" в журнале "Открытые системы". 2001.
N12.
Демин В. Проблемы выхода российских разработчиков на
Запад //PC WEEK/RE. 2001. N32.
PS. Бобровский С. Из пророков - в коммерсанты //PC WEEK/RE. 04.02.1997.
Б. Эккель. Философия Java. СПб.: Питер, 2001.
PS. Наши танки, рассмотренные в разделе "Проекты",
подтверждают это. Кстати, при социализме под сокращением
УМЛ понимался университет марксизма-ленинизма...
В ответ я отправил письмо следующего содержания. "Это хороший рекламный ход. Осталось, чтобы он был еще и корректным.
Возникает вопрос почему слово "статей" написано вами во множественном числе?
Так как вы не пишете о чьих статьях идет речь, может это сказано не про статьи чемпиона Урала по программированию, или этот чемпион не Н.Н. Шамгунов?
У Н.Н. Шамгунова в Вашем журнале опубликована только одна статья, а вторую, как известно, Вы без объяснения причин отклонили. Так, что множественного числа никак не получается.
Оно, правда, могло бы получиться, но в другом контексте, так как Н.Н. Шамгунов является трехкратным чемпионом Урала и двукратным участником финалов чемпионата мира по программированию.
С пожеланием дальнейшего сотрудничества Шалыто А.А."
Через день, чтобы исключить недопонимание, я послал второе письмо.
"Вчерашнее письмо не содержит скрытого намека на публикацию отклоненной статьи. Она скоро будет опубликована.
Вчерашнее письмо о другом - о корректности!
С наилучшими пожеланиями Шалыто".
Билл Гейтс публично заявляет, что не верит в диаграммы и не желает, чтобы его программисты занимались проектированием.
Константин Л. Назад в будущее //Открытые системы. 2001. N12.
PS. Может быть я антиглобалист, но знаете ли вы хоть один
товар, кроме "коробочного" программного обеспечения, на
который изготовитель не дает никаких гарантий?
Л. Торвальдс
PS. Вот вам и вся разница между Гейтсом и Торвальдсом.
Очень трудно объяснить, что интересного в том, чтобы биться головой о стену три дня подряд, не зная, как лучше, красивее решить задачу.
Но когда ты нашел решение - это чувство нельзя сравнить ни с чем в мире.
Л. Торвальдс
PS. Когда Линус это писал, он еще не знал, что ни с чем
не сравнимое чувство возникает также, когда (с помощью Switch-
технологии) ты точно и сразу знаешь место и условие
возникновения логической ошибки (раздел "О нас" п.13).
А.А. Шалыто
И я ни в малейшей степени не чувствовал себя жалким яйцеголовым неудачником.
Оболочка работала, а это значило, что я фактически построил основу работоспособной операционной системы. Про себя я назвал ее Linux.
Л. Торвальдс
PS. Как говорится, нет комментариев!
Я спросил у стендиста: "А внутри программа построена также красиво, как это сделано для пользователя?"
Стендист ответил: "Нет. Первое время все было красиво, а потом началась спешка и появились заплаты со всеми вытекающими для красоты последствиями".
Странно, но такая ситуация относительно внутреннего устройства программ имеет место практически всегда.
Несмотря на постоянное освоение идеологических новинок, выпуск все более совершенных средств разработки и технологических платформ, сдвиги в области конечных продуктов с большой натяжкой можно охарактеризовать как качественные. На мой взгляд на это имеется одна большая причина и одна маленькая.
Большая причина состоит в слабости научных основ промышленной автоматизации деловых процессов. Если называть вещи своими именами, то научных основ нет.
Вместо них существует целый ряд полушаманских учений под заголовками CRM, MRP, ERP, SCM, IDEF0, UML и т.п. Каждое из таких учений базируется на одном-двух (порой ошибочных) постулатах и претендует на относительную полноту, на деле покрывая лишь узкий спектр задач.
Малая причина состоит в том,что корпорации, увлекшись технологиями, не больно-то задумываются о целях их возможного применения. Ситуация с постоянным выпуском новых версий, появлением платформ и сред больше напоминает шоу-бизнес, чем серьезную вдумчивую работу. В результате мы имеем кучу красивых разноцветных кирпичей, из которых можно построить все что угодно, кроме дома, для построения которого мы их собственно и покупали.
Олег Горский, технический директор ООО "Кубикс", oleg@qbix.ru
Но пока остановились на написании "апплет", ввиду того, что оно так пишется на русскоязычном сайте фирмы "SUN".
PS. Отметим, что это слово отсутствует в Словаре для "начальников", созданном в СПбГУ //Российская газета, 4.09.2002.
PS. Не знаю, как на "Pentium", а на "Windows" изготовитель ничего не гарантирует. Кто-то из студентов сказал, что в документации на один из сигнальных процессоров также указано, что изготовитель гарантий не несет!
Не нравится - не покупай. В этом есть что-то бандитское...
Газета "Деловой Петербург". 5.02.2003
Использование чертежей не зависит от серийности - платье и дома обычно шьется не кое-как, а по выкройкам.
А.А. Шалыто
Мои ответы на этот вопрос состоят в следующем.
Во-первых, аппаратуру разрабатывают одни люди (организации, подразделения), а изготавливают - другие. Поэтому при некачественной документации разработчик проведет на "заводе" остаток жизни, что ему явно не хочется. При создании программ имеет место другая ситуация, так как в это случае обычно разработчик и изготовитель программ одно и тоже лицо, и поэтому какую номенклатуру документов не создавай, их содержимое обычно является весьма поверхностным.
Во-вторых, аппаратура является "жесткой", а программа - "мягкими". Это упрощает внесение изменений в программу, но не является основанием для того, чтобы вовсе не выпускать проектную документацию.
А.А. Шалыто
Это происходит, во-первых, потому, что при программировании компилятор подсказывает несоответствия, в то время как при написании проектной документации подсказать некому, а, во-вторых, разработка программ все больше напоминает шоу- бизнес с его погоней за прибылью. Все делается в дикой спешке, не раздумывая о том, что будет с этим продуктом через некоторое время, особенно длительное. Третья причина состоит в том, что чем более закрыт (не документирован) проект, тем более незаменим его автор и тем, в конечном счете, он дороже стоит.
Этот стиль работы, к сожалению, распространяется и на создание программного обеспечения для ответственных систем. Поэтому не удивителен случай, который стал недавно широко известен из литературы, когда в центре Парижа из-за отказа компьютерной системы управления в новом дорогом автомобиле чуть не погибли люди, так как кондиционер перестал работать, двери не открывались, а бронированные стекла даже снаружи удалось разбить далеко не сразу.
Описанная выше ситуация в программировании была далеко не всегда - при использовании "больших" машин программы либо проектировались, либо писались очень тщательно, так как после нахождения ошибки следующий "заход" на машину происходил обычно не ранее, чем через сутки.
А.А. Шалыто
PS. При наличии качественной проектной документации программист не сможет "управлять" менеджерами. После его увольнения на продолжение проекта можно нанять человека с более низкой квалификацией и зарплатой, а не с более высокой, как это часто имеет место в настоящее время.
В конечном счете, в цивилизованной стране средний программист, не должен получать больше среднего школьного учителя.
Это не относится к работам, "выложенным" на настоящем сайте в разделе "Проекты". При создании проектов мы очень старались. Написание каждой из них требовало десятков часов. Это свидетельствует о том, что разработка качественной проектной документации в программистском шоу-бизнесе вряд ли привьется.
Но, слава богу, есть и другие области программирования и появляются другие люди, которым нравятся программы с хорошей документацией.
Один из студентов, впервые увидев проектную документацию, разработанную на основе предлагаемого подхода, воскликнул: "Она лучше, чем на телевизор! Видимо, она такая же, как для подводной лодки".
А.А. Шалыто
В разделе "Проекты" приведено документация на систему управления танком для игры "Robocode". Как отмечено, в разделе "О нас" этот танк, во-первых, неплохо сражается, а, во-вторых, полностью документирован. Поэтому, когда перед Д.В. Кузнецовым встал вопрос о выборе танка для целей обучению программированию, он выполнил рефакторинг нашего, а не другого из сотен известных танков.
Такая же ситуация имеет место и для другой, еще более известной программистской игрой "Террариум". Известны сотни разработанных существ, но проектную документацию разработали, похоже, только мы одни.
Из изложенного следует, что если мир начал движение в сторону открытых исходных текстов, то будем надеяться, что со временем будет разрабатываться и открытая проектная документация. Это позволит отказаться от мучительного чтения чужих программ, заменив его рассмотрением проектной документации, а когда захочется "пошевелить" мозгами, то вместо чтения программ можно будет, например, взяться за решение японских кроссвордов.
А.А. Шалыто
Это очередной раз подтвердило, что движение за "открытые исходные тексты" ("открытые исходники") - "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 году.
Сложность и объем фактически "закрывают" исходные тексты при условии отсутствия документации высокого уровня и если вы не принимали личного участия в проекте с его ранних стадий.
Понимание "доисторического" кода при отсутствии первоначальных разработчиков или адекватной документации, позволяющей понять соответствующие архитектурные решения, является, вероятно, одним из труднейших видов программистской деятельности".
Последнее нас и "погубило", так как открытая проектная документация, как отмечалось выше, весьма наглядно демонстрирует не только достоинства, но и все недостатки программы.
Один выдающийся программист (призер чемпионатов мира по программированию) взглянул на код программы, и студент вновь начал переделывать проект. Это (с перерывами) продолжается уже более полугода (выполнено еще несколько корректировок), и я надеюсь, что хотя бы в этом проекте (игра "Морской бой") все будет прекрасно: и душа (программный код), и тело (документация), и мысли (работа программы). При этом отметим, что все это происходит после того, как зачет по проекту был давно получен.
На основе этого примера можно себе представить, как выглядят программы и документация на них, если они выполнены по лицензии AS IS.
А.А. Шалыто
Протасов П. Снизу //Компьютерра. 2003. N19
Зайцев С.С. Описание и реализация протоколов сетей ЭВМ. М.:
Наука, 1989.
Аллен Э. Типичные ошибки проектирования. Сб.: Питер, 2003
Ершов А.П. Смешанные вычисления //В мире науки. 1984. N6.
Работа обеспечивает потребности (выживание) отдельных людей и социальных групп. Работу можно рассматривать как воплощение инициативы, как сферу приложения энергии, форму жизненной силы. Это сила, скрепляющая общество. Это способ приложения энергии людей, способ наполнения нашей жизни, путь к достижению бессмертия. Работа - камертон нашей жизни. Работа - связующая сила цивилизации и сфера выражения индивидуальности, обеспечивающая широкие возможности для проявления творческих потенций. Работа должна обеспечить самовыражение человека.
Та степень, в которой человек накладывает на работу отпечаток своей индивидуальности и придает ей качества своего разума и духа, является мерой его успеха в деле свободного и полного выражения своей природы.
В ходе индустриализации повышалась производительность труда, и одно из последствий этого процесса состояло в том, что рабочие повсеместно теряли не нужную на рабочих местах квалификацию и выход творческой энергии вынуждены были искать в сфере досуга.
В наши дни работники, как правило, требуют, чтобы в их работе был какой-то смысл, какая-то возможность самореализации, хотя мало кто стремится полностью реализовать себя на рабочем месте - для того, чтобы жить полной жизнью требуется спорт, искусство и другие любимые занятия.
В профессии разработчика программного обеспечения есть какой-то изначально ей присущий неотъемлемый элемент творчества, а это именно то, что делает труд человечным. Может быть реализован инстинкт мастера своего дела - свобода выполнять работу в собственной неповторимой манере. Обычные рабочие потеряли эту свободу еще в доинформационную эру.
Три категории человеческой деятельности:
- теоретизирование (знание);
- поэтика и ремесло (творческая работа);
- практическая деятельность (обычна работа).
Все эти три формы деятельности присутствуют в труде программиста в сочетании, которое подчеркивает лучшие стороны каждой из них. Это обеспечивает возможность самовыражения человека. Это также позволяет человеку выполнить полезную общественную функцию.
Истинным революционером является инженер - именно он, изучая процессы, изменяет способы выполнения работы, и эти изменения влекут за собой перемены во всей нашей жизни.
Революционеры нашей эпохи - инженеры-программисты.
В последнее время часто используются методы "шустрой разработки" (agile). Это новый модный термин, обозначающий разработку силами небольших групп специалистов-ремесленников, предполагает использование проверенных методов, которые часто вызывают в памяти таких авторов, как Фредерик Брукс и Том Де Марко, Гради Буч и Кент Бек (Cockburn A. Agile Software Development. Addison-Wesley, 2001).
Независимо от того, каким образом программные средства будут организованы в будущем, они уже изменили весь окружающий нас мир.
Программное обеспечение играет центральную роль в поддержании целостности общества.
Важнейшие задачи: в теории - уяснение природы процессов разработки программ; на практике - подготовка спецификаций.
Кьюсак Д. О том, как труд профессионалов в области ПО изменяет
мир //Открытые системы. 2003. N6.
И вот теперь на базе языка "Java" в Sun Microsystems создали новый язык специально для "чайников", тех, кто вовсе не умеет программировать.
Язык "Ace" предполагает, что код будет представляться графически, в виде экранных диаграмм.
Надо сказать, что средства графического программирования предлагались и прежде. Особого успеха их создатели не снискали. Так или иначе, в Sun преисполнены оптимизма, полагая, что Ace даст возможность уменьшить стоимость и сложность разработки приложений, упростит их перенос на новые платформы.
Открытые системы. 2003. N6.
- А, что там было читать?
На что я ответил:
- А, что ты туда написал?
На этом наша обсуждение закончилось, а писать статьи о программировании в России практически некуда, и это при буме программирования в стране. Многим журналам почему-то больше нравится публиковать рекламу - либо прямую, либо косвенную, в том числе и по программированию.
Речь идет о двунаправленном взаимодействии графического и кодового представления программы, благодаря которому достигается повышение эффективности разработки приложений.
Есть реализация MDA для Delphi.
Дубова Н. Вместе с Borland //Computerworld Россия. 11.03.2003.
Дело информатики - приводить мир в порядок.
Плаксин М.А. Информатика. 2003. N1.
Необходима национальная программа по развитию систем с искусственным интеллектом (робототехники).
Пройдаков Э.М. PC WEEK. 2003. N10.
В крупных компаниях она прививается быстро, а в мелких - медленнее. Раньше модель не имела никакого отношения к способу ее реализации.
Подход, основанный на моделях, позволяет создавать не плакат, прикрепляемый на стену и игнорируемый разработчиками, а некую основу для реальной генерации программного кода.
Если программа будет автоматически генерироваться по модели, так что разработчику не придется учитывать особенности конкретных инфраструктур, форматов данных, способов их преобразования и т.д., а нужно будет лишь запрограммировать прикладную логику, это станет для всех большой победой.
MDA переводит разработку приложений в новое качество //PC WEEK/RE. 2003. N9.
PS. Прикладную логику можно запрограммировать, в том числе сгенерировав ее, на основе автоматного программирования.
Проектная документация необходима, так как из теории алгоритмов известно (теорема Райса), что, в общем случае, по тексту программы невозможно алгоритмически доказать истинность никаких нетривиальных свойств вычисляемой ей функции.
Для понимания программ (в отличие от их исполнения) следуя Тьюрингу, требуется "проницательность и изобретательность". Но так как анализ текстов программ все равно не поддается автоматизации, а анализ "вручную" требует колоссальных затрат времени, то кажется, что по только по тексту программы невозможно сделать выводы о ее свойствах.
Однако это не так. Математики нашли решение аналогичной проблемы еще в античности. Это запись доказательства понятным человеку языком, что и отличало греческую математическую школу от древнеегипетской. В последней в качестве решения геометрической задачи предоставлялся чертеж, снабженный "пояснительной" надписью "Смотри!", что сродни представлению текста программы для определения того, что она делает.
Для того, чтобы другие могли понять не только как работает наша программа, но и что она делает и каким образом она это делает, им необходимо предоставлять подробное описание (на понятном человеку даже "средней" квалификации формализованном языке) как процесса создания программы, так и ее свойств (статических и динамических), что и представляет собой проектную документацию. Она является подтверждением того, что представленная программа вычисляет данную функцию - соответствует техническому заданию.
"Наиболее запомнившееся и поразившее меня при выполнении совместного проекта с фирмой IBM отличие состояло в том, как они относятся к документации. У них было принято и это соответствовало практике - что написано в документации, то так и есть, так и работает. У нас - никогда! У них из этого проистекала корпоративная уверенность в себе - на все вопросы они находили ответ в документации, утвержденной начальством.
У нас не только документация плоха, ни и мысли изложить толком никто не умеет. Я много раз сравнивал и х доклады и наши "доклады". Однажды мы пригласили одного из лучших переводчиков. Он потом извинялся, что не смог толком перевести на английский, но я его успокоил, что на русском-то ничего не понял...
Этому нужно научиться. Эту часть работы следует любить и уважать".
Скрипников А. Когда кончится нефть //Газета "Известия".
09.09.2003.
PS. Несомненно, что у н и х с документацией не так все
хорошо, как говорит автор, но тенденция просматривается...
Значительное событие в развитии методологии программирования - это появление технологии разработки, управляемой моделями, так называемый "model-driven architecture" (MDA), зародыши которой можно видеть в CASE-системах. Речь идет о двунаправленном взаимодействии графического и кодового представления программы, благодаря которому достигается значительное повышение эффективности разработки приложений. В Borland есть реализация MDA для Delphi.
Спецификации MDA разрабатываются в рамках консорциума OMG
Вместе с Borland //Computerworld Poccия. 11.03.2003.
Джим Оллчин. Computerworld Россия, 23.09.2003
А.А. Шалыто
Он ответил, что подводную лодку или самолет, не разработав проектную документацию, в принципе не построить, в то время как программу написать можно, и поэтому при ее создании обычно выполняется оптимизация по критерию "цена/качество".
На это я ответил, что при проектировании программ по этому критерию я под снижением качества понимаю меньшую функциональность, а не возможность наличия ошибок, как это считается обычно. Оптимизация по указанному критерию при наличии ошибок, по моему мнению, является просто разгильдяйством.
На первый взгляд кажется, что в условиях рынка программы с малой функциональностью, например, для сотовых телефонов, мало кого интересуют, и поэтому ошибки в программах имеются практически всегда.
Однако это не совсем так. Длительная эксплуатация такой операционной системы (ОС) как QNX показывает, что в ней практически отсутствуют ошибки.
Очень много усилий для их устранения предпринято и при создании ОС "Symbian", предназначенной для сотовых телефонов.
Для создания прикладных программ для ответственных систем все шире применяется, так называемое, синхронное программирование, использующее специальные языки программирования.
Качество программного обеспечения в последнее время обсуждается все шире и шире. Так в январском номере журнала "Мир ПК" в колонке редактора Алексея Орлова написано:"Госу- дарство должна тревожить проблема ответственности производите- лей программного обеспечения за свои изделия. Раз уж мы поставлены перед фактом всегосударственной любви к одной известной фирме, то давайте хоть попробуем заставить ее, а за ней и остальные компании нести ответственность за свою продук- цию. Ведь каждое равнодушное принятие условий "безответствен- ной" лицензии - это наши деньги, вложенные в бесконечные обновления и покупки новых версий ПО. Способно же государство требовать сертификаты на мясо! В конце концов, бесконечная сказка про ... особый характер программ как товара лишь прекрывает нежелание производителей вкладывать деньги в наукоемкую разработку средств верификации программ".
Это тоже самое, что утверждать, что схема электрическая принципиальная - вся документация на систему.
В общем это большое недоразумение. "Один из пионеров авиации Д. Дуглас, говорил, что "когда вес документов достигнет веса самолета, он начнет летать", а Д. Мартин утверждает, что "документация для "Боинга-747" весила больше, чем самолет". То же самое относится и к программному обеспечению, а где это не так - разработки неуправляемы" (Фокс Дж. Программное обеспечение и его разработка. М.: Мир, 1985). С появлением новых носителей информации вес документации, естественно, уменьшается, но это сути дела не меняет, так как количество информации в документации при этом сохраняется.
Linux Torvalds
Это ежегодная рубрика отмечает жителей Северной Америки, оставших наиболее яркий след в мировой индустрии. Додж и Белл удостоились этого почетного титула за создание ОСРВ QNX Neutrino.
PC Week/RE. 2003. N 10.
Для этого документация должна создаваться с позиций "чайника", который, желательно, чтобы при этом сидел рядом с вами.
Такой процесс (по аналогии с экстремальным программированием) может быть назван "экстремальное написание проектной документации".
Интересно, что разработкой ПО в Бангалоре занимается все больше иностранных предприятий. В прошлом году здесь открыли бизнес 168 фирм, инвестировавших 748 млн. долл. Сегодня в Бангалоре размещены офисы свыше 1100 международных и индийских компаний. Здесь трудится около 110 000 программистов и 60 000 специалистов в области аутсорсинга.
Пока многие страны еще только соображают, как стать э-державами, корейское правительство поставило задачу к 2007 г. превращения государства u-Korea. Приставка «u» возникла от прилагательного ubiquitous (вездесущий, повсеместный). При этом для реализации этого проекта предложена стратегия «8 — 3 — 9».
Она предполагает развертывание восьми новых сервисов (мобильный Интернет, телематика и т.д.), создание трех инфраструктур (системы связи новых поколений) и развитие девяти основных направлений (цифровое телевидение, роботы, встраиваемое ПО и т.д.).
Тайвань превратился из мирового производственного центра в центр исследований, разработок и производства.
Максимов А. Восточный экспресс //PC WEEK/RE. 2004. N23.
Еще несколько лет даже рыночные аналитики утверждали, что ПК постепенно заменят ПЛК. Однако в конце концов они отказались от этого сценария.
Объемы продаж ПЛК растут, и, похоже, они пришли, чтобы остаться.«Собака не берет след», — вот ответ всем аналитикам, предсказывающих победу ПК.
В фирме «Омрон» (Япония) не считают, что ПК вообще когда-либо заменят ПЛК. Они стали применяться в новых приложениях, в которых раньше не применялись, например, в устройствах защиты. ПЛК являются устойчивыми платформами и обладают готовностью к более длительной эксплуатации, по сравнению с ПК.
С этим соглашается фирма «Rockwell Automation». «До сих пор управление на основе ПК не было ориентировано на потребности конечных пользователей, которым необходима надежность, долговечность и простота применения, а ПЛК предлагают эти три свойства в изобилии».
ПЛК по-прежнему имеют упрощенное программирование и это очень существенно для промышленной автоматизации. Появился даже новый термин «программируемый контроллер для автоматизации» (programmable automation controller — PAC).
Промышленные АСУ и контроллеры. 2004. N7.
Рене Декарт
Людвиг фон Витгенштейн
Китайская пословица
Два заключенных содержатся отдельно и им предлагается следующая сделка: «Если никто не сознается, вас обоих освободят. Если вы оба сознаетесь, то получите большие сроки. Если сознается только один, то он получит маленький срок, а другой — в два раза больше.»
В этой ситуации оба могут сидеть большой срок, хотя могли бы не сидеть вовсе.
М. Фаулер
Эти технологии очень сложны, например, в Intel над ними работало порядка тысячи (!) человек.
Майкл Фистер, руководитель компании «Cadence». PCWeek/RE.
22 марта 2005 г.
Последние рыцари уходят. И заменить их уже некем… Богатырев Р. Календарь истории. Портреты великих. Мир ПК. 2005. N4.
Владимир Набоков
Б. Вольтер
А. Черномырдин
П. Васильев, генеральный директор компании «АстроСофт».
Компьютер-информ. 2006. N3, с.14,15.
Одна из основных проблем сертификации таких систем заключаются в высокой трудоемкости анализа исходных текстов.
Согласно статистике по сертификации критически важных систем в 100% из них сопроводительная документация нуждается в улучшении.
PC Week/RE. 2006. N3
В приложениях всегда главным считался код, но сегодня одного только кода мало. При этом традиционным текстовым языкам не хватает средств для того, чтобы оценивать и понимать поведение программ.
Буч Г. Будущее моделирования выглядит оптимистично
//PC Week/RE. 2005. N42, с.23, 38
Боуэн Д., Хинчи М. Десять заповедей формальных методов…
Десять лет спустя. Computer. 2006. N1
Виктор Папенек
Методология — анализ принципов и процедур, применяемых при проведении исследований в определенной области.
P.S. Автоматы служат для той же цели применительно к реализации поведения. А.Ш.
Компьтерра. 2005, #583
Однако после покупки восьми военных вертолетов возникла непреодолимая проблема, так как пункт о предоставлении текстов программ в явном виде в контракт не вошел, а когда их попытались получит позже, корпорация Boeing ответила отказом, заявив, что «не готова» к этому по соображениям безопасности. Эта история тянется с 2001 года, а вертолеты стоили почти полмиллиарда долларов.
Компьютерра. 2005, #585
Мне представляется, что в перспективе бизнес-процессы найдут свое воплощение в хорошо спроектированных программных компонентах. Все модели здесь будут описаны явно. В них смогут разобраться представители самой широкой аудитории, а не только знатоки С++. Сегодня это приобретает все большее значение.
Айк Насси, старший вице-президент лаборатории SAP Labs по
научным исследованиям, сыграл ключевую роль в разработке
языка Ada. Еженедельник «Computerworld Россия». 19.09.2006
Computerwold Россия. 30.01.2007
На самом деле это совершенно не так. Открытый стандарт накладывает довольно жесткие ограничения на использование кода. И их нарушения чреваты судебным разбирательством.
Главное требование - пользователь открытого кода обязан полностью опубликовать код, котором заимствование использовано.
PC WEEK/RE. 2007. N2, с.8
О том, как лучше писать программы для программируемых контроллеров, они ничего не сказали.
Такая ситуация имеет место уже не первый год.
Усилия, направленные на преодоление этого кризиса, привели к созданию новой дисциплины, названной "программной инженерией". При этом, в частности, для повышения производительности труда программистов начали разрабатываться инструментальные средства.
В 1968 году в Гармиш-Партенкирхине (Германия) состоялась организованная комитетом по науке НАТО конференция, которую считают моментом рождения программной инженерии.
Термин "Software Engineering" в том же году предложил Фредерик Бауер.
Программирование губит иллюзия простоты и вседозволенности.
Даже уже в 1999 году Фредерк Брукс при вручении премии Тьюринга сказал: "Мы не знаем, что делаем, и не знаем, что сделали".
Хроника (начало - 1986 год) неприятностей, связанных с программированием, приведена в http://catless.ncl.ac.uk/Risks.
Принятому решению предшествовал почти двадцатилетний период участия в оборонных проектах, из которых они вынесли твердое убеждение в необходимости разработки средств, рационализирующий процесс создания программного обеспечения, что отразилось в названии компании.
В 1990 году был запущен проект - разработка средств моделирования, основанных на графической нотации, предложенной Гради Бучем. В 1995 году в компанию пришел Джеймс Рамбо, а затем у фирмы Ericsson была куплена шведская компания Objectory Systems, основанную Айваром Якобсоном в 1987 году. В 1995 году их совместными усилиями появился язык Unified Modeling Language (UML).
В дальнейшем центром, курирующим UML, стал консорциум Object Management Group (OMG).
Васильев П. Генеральный директор компании "АстроСофт". Компьютер-
Инфо. 2005. N20
Основная сложность подобной сертификациизаключается в высокой трудоемкости анализа исходных текстов продуктов и тестированием всех возможных уязвимостей. Согласно статистике 100% сертифицируемых систем и документации на них требовали доработки.
PC WEEK/RE. 2006. N3
Продолжающееся использование термина "отладка" является доказательством того, что процесс программирования в сущности за поседние годы не изменился.
PC WEEK/RE. 2007. N10
Фаулер М. Рефакторинг. СПб.: Символ. 2003
Академик РАН Н.Н. Красовский
М.Р. Шура-Бура
Идея о возможности "логически обратимых" операций, которые не сопровождаются рассеянием энергии, впервые высказал Р. Ландауер еще в 1961 году.
Существенный шаг в решении этой задачи был сделан в 1982 году Ч. Беннеттом, который теоретически доказал, что универсальный цифровой компьютер может быть построен на логически и термодинамически обратимых вентилях таким образом, что энергия будет рассеиваться только за счет необратимых периферийных процессов ввода информации в машину (формирование исходного состояния) и соответственно вывода из нее (считывание результата).
К обратимым универсальным вентилям относятся вентили Фредкина и Тоффоли.
Если требуется разложить на простые множители число x, имеющее n знаков в двоичной записи, то очевидный способ решения состоит в том, чтобы попробовать последовательно разделить на числа от двух до корня из n. При этом перебирается два в степени n/2 вариантов.
Если число содержит 100000 двоичных знаков, то требуется перебрать 3x10 в степени 15051 вариантов.
Существует алгоритм, решающий эту задачу за exp (n в степени 1/3), но при миллионе знаков опять возникает непреодолимая проблема.
Скорее всего, моделирование квантовой механики является экпоненциально сложной математической задачей.
В 1985 году Дэвид Дойч предложил математическую модель квантового компьютера.
В 1994 году Питер Шор предложил для квантового компьютера алгоритм разложения n-значного числа на простые множители за время, полиномиально зависящее от n (квантовый алгоритм факторизации). После этого появились алгоритмы, позволяющие решать некоторые NP-проблемы.
В настоящее время известен квантовый компьютер, составленный из семи кубитов. Этого достаточно, чтобы разложить число 15 с помощью алгоритма Шора.
Первый квантовый компьютер, который был создан на практике, - это импульсный ядерный магнитно-резонансный (ЯМР) спектрометр высокого разрешения, хотя он исходно как квантовый компьютер не рассматривался. На нем осуществлены квантовые операции с числом кубитов до семи.
В начале 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 (гибкий, шустрый), объединивший указанные методологии.
Дэнни Саббах, генеральный менеджер IBM Rational Software
- При использовании эволюционных методов не требуется точно указывать как решать задачу. Вместо этого достаточно ее
сформулировать в терминах некоторой "цели" и "допустимых затрат",
программа будет создана самой вычислительной системой в ходе
эволюционного процесса. Высказывание: "машина никогда не знат
больше программиста при этом оказывается просто неверным".
- Проект был не совсем открытым - документация в нем была
написана на японском языке.
- МО США, запретив военнослужащим вести блоги и обмениваться
э-письмами без разрешения специального отдела, наложило вето и
доступ к социальным сетям через служебные сети, которые оказываются
полностью загруженными развлекательным содержимым.
- Корпорация "Google" и движение "Close Source"
Фотокорреспондент журнала "Секрет фирмы" снял сидящих за компьютерами программистов, которые после этого окружили журналиста и жестко, без всяких шуток, попросили уничтожить фотографии. Программисты снимаются в холле, потому что в офисе в поле зрения объектива может попасть (о, ужас - А.Ш.) часть программного кода.
Фогель Л., Оуэнс А., Уолш М. Искусственный интеллект и
эволюционное моделирование. М.: Мир. 1969.
Фотокорреспондент журнала "Секрет фирмы" снял сидящих за компьютерами программистов, которые после этого окружили журналиста и жестко, без всяких шуток, попросили уничтожить фотографии. Программисты снимаются в холле, потому что в офисе в поле зрения объектива может попасть (о, ужас - А.Ш.) часть программного кода.
Журнал "Секрет фирмы". 2007. N27, с.17
- Цель, к которой надо стремиться в области распознавания текстов,
была сформулирована в 1966 г.: "Мы будем говорить, что система
ведет интеллектуальную обработку, когда предоставим ей текст
поэмы А.С. Пушкина "Евгений Онегин" и она даст корректный ответ
на вопрос: "Какое отчество было у Татьяны Лариной?" Ответ
возможен, так как в тексте поэмы говорится о надписи на
надгробном камне: "Смиренный грешник Дмитрий Ларин..."
Прошло уже более сорока лет, и, надо признать, что мы не очень-то сильно приблизились к решению этой задачи. Это - высокая цель - интеллектуальное понимание текста системой.
Прошло уже более сорока лет, и, надо признать, что мы не очень-то сильно приблизились к решению этой задачи. Это - высокая цель - интеллектуальное понимание текста системой.
В.Л. Арлазаров, член-корреспондент РАН. Мир ПК. 2007. N9
- Следующий этап развития должен научить системы распознавать и
извлекать из документа смысл его содержания при условии, что оно
заранее неизвестно. Только представьте, мы ищем статью по
интересующей нас тематике, дав системе запрос в произвольной
форме, а она эту статью идентифицирует из массы других и делает
аннотацию на десять строк. Мечта? Пока, к сожалению, да.
В.Л. Арлазаров, член-корреспондент РАН. Мир ПК. 2007. N9
- Я считаю название журнала по дизайну "Проектор" гениальным.
Само слово "проект" является ключевым в тех процессах, которые
происходят в сфере дизайна и виртуального искусства. Проектное
мышление - один из постулатов, на котором держится профессия
дизайнера. Проектор - то, что выхватывает из темноты,
проецирует, освещает.
Харшак, главный редактор
- Программирование должно еще в школе преподаваться не как
искусство, а как инженерная дисциплина.
- В университетах мы должны учить чистым, прозрачным и передаваемым вещам. При этом язык должен быть на заднем плане. Это не главная тема обучения. Важно, что обучение мышлению в программировании не должно осуществляться с помощью того или иного языка.
Никлаус Вирт
- Когда пишешь код, думай о тесте. Когда пишешь тест, думай о коде. Когда думаешь о коде и тесте как о едином, тестирование просто, а код красив.
- Каждая компьютерная проблема решается еще одним уровнем абстракции.
Запускай тесты часто. Радуйся, когда они проходят. Радуйся, когда они не проходят. Программирование с использованием тестов - это более приятный процесс, чем программирование без тестов. При Test-Driven Development - тесты средство достижения цели.
Существуют тысячи причин, из-за которых программа слабо поддается тестированию.
Дэвид Уиллер
- Сейчас на рынке ПО остро не хватает кадров. Но охота при этом идет не на отдельных программистов, а на дееспособные команды хотя бы из трех человек!
Секрет фирмы. 2008. № 13, с. 23.
- Почему те, кто разрабатывает аппаратуру относится к разработке более ответственно, чем программисты? Это, видимо, связано с тем, что аппаратура отсутствие проекта не прощает – может сгореть, а в программировании можно соединять все подряд – просто не будет работать!
- Программисты высокого класса называются неправильно – они решатели задач, а не кодировщики чужих алгоритмов.
- Переход от неформального к формальному существенно неформален.
М.Р. Шура-Бура
- «Экспресс – тренинг. Искусство жить. Техника достижения желаемого». Управляй своим состоянием. Обеспечение состояний комфортности, уверенности и свободы.
Реклама на столбе
