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

Сто лучших университетских команд мира, отобранных из 7109 команд 1838 университетов, собрались в Шведском королевском технологическом институте (Royal Institute of Technology, KTH). Их задача состояла в разработке ПО, которое может помочь в решении проблем мирового уровня. Каждой команде, состоящей из трех участников, было предложено 11 задач. Например, создание расписания аэропорта для безопасной посадки самолетов, которое бы учитывало изменение погодных условий, или оптимизация транспортного потока в часы пик. Выбранная участниками технология должна основываться на открытых стандартах.

Команды-победители определялись, во-первых, по количеству правильно решенных задач, а при прочих равных — по наименьшему времени, затраченному на поиск решения. Команда студентов из Санкт-Петербурга решила 9 из 11 задач. На чемпионате ACM ICPC вручается по четыре золотых, серебряных и бронзовых медали. Второе, третье и четвертое места заняли соответственно команды Университета Циньхуа (Tsinghua University) из Китая, Санкт-Петербургского государственного университета и Саратовского государственного университета.

21 апреля 2009 г. в Стокгольме прямо в том же зале, где лауреатам вручают Нобелевскую премию, наградили победителей финала очередного студенческого командного чемпионата мира по программированию International Collegiate Programming Contest (ICPC) 2009. На этот раз команды из России заняли первое, третье и четвертое места.

Всего за последние 10 лет Россия на этих соревнованиях завоевывала чемпионский титул 6 раз.

Следующий мировой финал чемпионата ICPC 2010 состоится в китайском Харбине. Команды будет принимать Харбинский научно-технический университет (Harbin Engineering University).

Источник — cnews.ru

В продолжение темы ролик о том, куда деваются эти люди.
Как создавалась советская операционная система к столетию Ленина? Почему в России не осталось IT-специалистов? Как западные компании присваивают наши достижения? Ответы на эти и другие вопросы дает один из крупнейших в мире ученых и бизнесменов Михаил Владимирович Донской.

Ровно 27 лет назад компания Sinclair Research выпустила первый ZX Spectrum.
У меня был spectrum zx-80 и умел он выполнять один миллион элементарных операций в секунду. Это было чудо за которым ехали специально в другой город, игры записывались на кассеты, классные игры загружались на кассетах дольше, а загружались они не с первого раза и все это дело подключалось у меня к обычному телевизору. Это было чудо заключенное в корпус клавиатуры, а на кнопочках еще непонятные мне надписи помимо букв.

На нем я писал свои первые программы на бейсике для решения квадратных уравнений и записывал их на кассеты. Я мечтал о дисководе и пяти дюймовых дискетах.

Этот компьютер вырастил целое поколение увлечённых IT людей, и в массе вариантов пришёл на территорию всего ex-СССР, получив немыслимое для своего создателя развитие — здесь он обзовёлся мышами, дисководами, пятикратным объёмом памяти, стал полноправным участником не одной Demo Party и любимцем миллионов.

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

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

Для тех, кто не в теме, вот так вот выглядел процесс загрузки игры:


А вот так выглядела самая первая реклама ZX Spectrum:


У кого было подобное чудо?

Буду благодарен за текстовый перевод (может, кому-то на работе не чем заняться:)) Перевод запустится сабтитрами, при желании укажу ваше имя;)

Начало:
Жизненный цикл программиста Часть 1
Жизненный цикл программиста Часть 2

После ухода из «Параграфа», я не смог найти другую работу, в основном по принципу «двух медведей в одной берлоге», когда начальник не хотел иметь в команде еще одного лидера. Поэтому в 1994 году мне пришлось заняться бизнесом, организовав свою фирму «ДИСКо» (Donskoy Interactive Software Company), существующую по сей день. Фирма занимается разработкой программ на заказ. Основными клиентами являются крупные фирмы, работающие в области информационных технологий. Связано это, в первую очередь с тем, что доказывать разумность нашей ценовой политики клиентам из других отраслей крайне сложно. Они искренне полагают, что любую программную систему можно сделать одному человеку за месяц. Ситуация усугубляется тем, что рынок полон дешевых предложений, связанных либо с самонадеянностью вчерашних студентов, либо, что еще хуже, с сознательным затягиванием клиента с целью дальнейшей раскрутки его уж на совсем большие деньги. Это напоминает «бесплатные» лекции по народной медицине, где вход формально свободен, а выход фактически с пустым кошельком.

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

До кризиса доткомов «ДИСКо» работало в основном на рынке США, но после него пришлось переориентироваться на российский рынок. Одну вещь после этого перехода пришлось прочувствовать сразу. В Америке ни один менеджер не ведет переговоры вне рамок своей компетенции и, особенно, вне рамок своего бюджета. В России, особенно на первых порах, много раз приходилось, уже придя к соглашению по всем параметрам проекта – техническим требованиям, цене, срокам, — слышать замечательную фразу «А теперь я пойду согласовывать это с начальством». Эффективность переговоров с такого рода менеджерами, мягко говоря, невелика. Отсюда – нацеленность «ДИСКо» работать с крупными кампаниями, про которые ясно, кто есть кто.

В начале этого тысячелетия пришлось сделать еще один крутой поворот. На этот раз — в сторону мобильных устройств и всего, что с ними связано, в первую очередь, беспроводными технологиями связи. Поскольку первые заказы были американскими, приходилось убеждать авторов технологий в их «незрелости» для практического использования. Слышать это от маленькой российской фирмы им было странно. К счастью, это потом подтверждалось и другими, более авторитетными источниками. Так было, например, с технологией BlueTooth, про которую было много критики на CeBit-2002. Мы сделали пилотный проект для разных средств связи по заказу 3COM, и, если инфракрасная связь и WiFi работали прекрасно, то с BlueTooth были серьезные проблемы.

Однако с 2004 г. с BlueTooth стало все в порядке, а мобильные устройства становятся все популярнее и популярнее. Хотя карманные компьютеры и сходят на нет, их с успехом заменяют (а может, и вытесняют) смартфоны, имеющие все прелести и карманных компьютеров и мобильных телефонов. Для лэптопов и ноутбуков сейчас тоже очень хороший сезон. А впереди маячат планшетные компьютеры и сетевые и многое другое.

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

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

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

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

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

Похожая история должна произойти с Symbian, операционной системой, установленной на телефонах Nokia и Sony Eriicsson. Подход ее авторов тоже был минималистским. Она, конечно, лучше, чем Палм, но все равно, крайне трудна для программистов. А именно программисты решают все. Самой лучшей операционной системой последние 30 лет является Юникс, но плохой пользовательский интерфейс привел к тому, что более популярно изделие Майкрософта.

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

Сила Майкрософта не только в больших деньгах, вкладываемых в раскрутку продуктов, иногда не совсем работающих, а и в армии программистов, умеющих работать в этой системе, и в куче полуфабрикатов, которыми могут пользоваться эти программисты. Для меня, например, разработка программы для Windows по себестоимости вдвое дешевле, чем разработка аналогичной программы для Symbian. Нетрудно догадаться, какую систему я рекомендую своим заказчикам.

Пока последний поворот в моей программистской биографии – видео в Интернет. Интернет, точнее, мировая паутина – это особая тема для разговора. Она обладает врожденным пороком. Это — система, придуманная для обмена гипертекстовой информацией в распределенных сетях. Однако за свои 13 лет, начиная с появления «Мозаики», паутина эволюционировал в сторону системы доступа к гигантскому хранилищу информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Михаил Донской

Взято здесь: http://polit.ru/science/2008/08/20/programmist.html

Начало:
Жизненный цикл программиста Часть 1

А в 80-х началась эра языка Си на машинах, скопированных с PDP и IBM PC. Мы потеряли весь свой ассемблерный «языковый запас» и так и не достигли аналогичного уровня инструментария на Си. Это была своего рода эмиграция. Привыкнув к детальному пониманию, как происходят реальные вычисления в памяти, пришлось отвыкать и работать в гораздо более абстрактных сущностях.

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

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

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

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

«Система наблюдения» «Каиссы» состояла в возможности вывода на печать хода перебора в любом разрезе, начиная с любой точки, как в партии, так и в переборе. Что важно, сама форма выдачи была «человеческой», то есть в шахматных терминах, а не в терминах программы. Во время матча «Каиссы» с читателями «Комсомольской Правды» в 1972 году результатом каждого хода была распечатка толщиной 2-3 сантиметра. И мы ее всю внимательно прочитывали. Поэтому к чемпионату мира мы знали о глубинах перебора гораздо больше, чем все остальные. В этих условиях было трудно не придумать эффективные методы сокращения перебора, которые и принесли «Каиссе» победу. Кстати, в научных кругах, матч 1972 года ценится гораздо выше, чем победа в чемпионате мира.

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

Если до середины 80-х еще реальны были программы, созданные если не одним человеком, то хотя бы в рамках одного коллектива, то в дальнейшем в производство шли программы, построенные по принципу «Лего», а именно, собранные из различных полуфабрикатов (библиотек и компонент), разработанных в разных уголках мира.

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

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

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

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

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

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

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

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

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

Вернемся к 1980-м. Еще до перестройки мы — отдел ВНИИСИ под руководством В. Арлазарова — локально победили институтскую и академическую бюрократию за счет того, что на игольчатом принтере «Электроники» смогли изобразить шрифт печатной машинки. В то время, например, было запрещено подавать к защите диссертации, напечатанные на компьютере, но с нашим шрифтом понять, что это печать компьютера, а не машинки, без специальной экспертизы было нельзя. Аналогичным образом дело обстояло со многими другими документами – планами, отчетами, выездными характеристиками и так далее.

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

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

В начале российской эпохи персональных компьютеров, случайно или не случайно совпавшей с кооперативным движением, ко мне обратился прекрасный менеджер Е. Соколинский, возглавлявший кооператив «Перспектива» с предложением реанимировать «Каиссу» для ПК. Для этого мне нужно было из работавшего в свое удовольствие ученого стать начальником группы программистов, да еще и создать эту группу с нуля. Уговорив меня, Соколинский нашел изумительный способ формирования группы. Мы дали объявление в газеты о платных курсах шахматного программирования. Стоимость месячного обучения для наших слушателей составляла 200 рублей, что по тем временам была существенная сумма. Занятия шли шесть дней в неделю и кооператив доплачивал за аренду аудиторий и компьютеров немалую сумму.

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

В конце 1980-х, когда я оказался в СП «Параграф», он представлял собой своеобразную сборную лучших московских программистов. В «Параграфе» того времени работали Е.Веселов (автор «Мастера» и «Лексикона»), А. Чижов (автор многих русификаторов, в частности, знаменитой «Беты», он же автор альтернативной таблицы кодировки кириллицы) и другие. В качестве помощницы у Веселова в «Параграфе» работала О. Дергунова, получившая известность уже в Майкрософте. Игры продавал В. Савюк, потом раскрутивший марку «Денди». В общем, компания подобралась неплохая.

По дороге пришлось пережить очередной крутой поворот – появилась Windows 3.1, и пришлось от традиционного процедурного программирования переходить к системам, управляемым потоком событий. Сегодня они привычны и понятны, а тогда ушло много усилий на понимание, «куда лошадь запрягать», а именно как устроен порядок исполнения кода в таких системах. Поток управления в них весьма неочевиден, и проблемы многопоточности и синхронизации вышли на первый план.

У меня в «Параграфе» был отдел шахматного программирования, в котором «Каисса» получила вторую жизнь в качестве программы для IBM PC. Хотя мы и сделали в отделе шахматную программу – реинкарнацию «Каиссы» для IBM PC, которая достойно сыграла на компьютерной олимпиаде 1990 года, заняв третье место, интерес быстро сдвинулся в сторону пользовательского интерфейса, поскольку графические оболочки Мака и Windows очень манили в эту сторону.

Наш отдел, в котором работали А. Дубец, М. Караев, В.Кокин, И. Шабалин и другие, открыл целое направление графических редакторов. Мы сделали редактор формул, а, уже уйдя из Параграфа, и редактор факсов, а потом и новую версию Лексикона.

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

В это же время пришлось осваивать C++. Мое знакомство с этим языком началось с экскурсии в офис Bell Laboratories в Murray Hill, которую мне устроил в 1989 году автор Юникс Кен Томпсон. Мы с сыном жили у Кена в гостях, и в воскресный вечер он предложил прокатиться в офис. Офис был безлюден, и я с интересом смотрел на технические чудеса, которых там хватало. В какой-то момент Кен показал на дверь кабинета со словами «А здесь сидит чудак, который думает, что на его языке будет программировать весь мир». Табличка на кабинете гласила, естественно, «Б. Страутсруп».

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

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

Продолжение:
Жизненный цикл программиста Часть 3

Статья известного российского системного программиста, зав. лабораторией Института системного анализа РАН, члена Российской академии интернета, автора шахматной программы «КАИССА» (первого чемпиона мира среди шахматных программ), президента компьютерной фирмы ДИСКо, лауреата всех профессиональных опросов «Top-100 Российского компьютерного бизнеса», Михаила Донского.

У каждой профессии есть свой романтический период и есть период, когда она превращается в рутинную. Быть шофером в начале прошлого века было трудно и почетно. Сегодня автомобиль может водить любой желающий, а в большинстве районов США жизнь без автомобиля практически невозможна. Так профессия шофера прошла полный цикл от интеллектуальной и романтической до бытовой и повседневной за какие-то 60 лет.

Цикл профессии авиапилота тоже близится к окончанию и займет те же 60 лет.

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

Так получилось, что время моей жизни практически совпало с жизненным циклом моей профессии. Я – программист. Сами компьютеры появились в 40-х годах (и не надо здесь вспоминать ерунду про дочку Байрона), то есть в то же десятилетие, когда я родился.

В этой статье я хочу, вспоминая свою профессиональную жизнь, напомнить, как менялась профессия программиста.

Когда я школьником учился программировать на М-20, в СССР программистами были известные математики, на ходу выдумывавшие то, чему сейчас учат в школе.

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

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

В итоге тогда шахматная программа ИТЭФ, предшественница «Каиссы», умещалась в памяти М-20, а именно в 4096 ячейках, каждая из которых имела 48 разрядов (теперь это называют битами). Где-то рядом уже существовал Алгол-60, но им «настоящие» программисты не пользовались, поскольку техники отладки практически не было. Чуть позже большую популярность получила статья «Почему настоящие программисты не пишут на Фортране».

Мои студенческие годы пришлись на целый ряд советских машин – Раздан-3, Минск 1, 2, 22, 32, Урал-14, все из которых имели пульт, за которым сидели программисты, а программы и данные вводились с перфокарт или с перфолент. АЦПУ — устройство «широкой» печати — появилось только в конце 1960-х.

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

Рассказывают, что в операционной системе «Пульт», написанной в Вычислительном Центре АН СССР для БЭСМ-6, был счетчик ошибок оператора, и при достижении некоторого порога система выдавал «вежливое» сообщение «А если ты – дурак, то не садись за „Пульт“». Когда директор ВЦ академик А. Дородницын инспектировал систему, он понажимал несколько раз случайные кнопки и был крайне огорчен полученным результатом.

О серьезности задач, которые тогда приходилось решать на тогдашних компьютерах, говорит то, что одним из моих проектов в студенческое время была система инверсного поиска патентов для экспертов. Кстати, ВМК еще не было, было отделение вычислительной математики на мех-мате, но я учился на отделении математики. Сдавая зачет по программированию, я должен был аппелировать к своему профессору М.Р. Шуре-Буре, поскольку его аспиранты, принимавшие зачет, программировать почему-то не умели. И вообще на мех-мате программирование считалось чем-то вроде предательства чистой математики, и всерьез на моем курсе им занималось не больше десятка человек. Была даже частушка: «Меня милый не целует, не садится близко, говорит „я – математик, а ты – программистка“». А потом 90 процентов выпускников с моего курса пошло-таки работать программистами.

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

Конец моих студенческих времен совпал с революцией в компьютерах. Появились компьютеры «общего пользования с системами разделения времени. Это IBM 360, ICL 4-70, ЕС ЭВМ. Писать в кодах для таких машин стало принципиально невозможно, и на передний план вышел (как наименьшее зло) язык ассемблера. Были и другие языки программирования (Фортран, Кобол, Алгол, PL-1), но они не позволяли эффективно контролировать оттранслированный код. Мой сосед по кабинету в ИПУ М. Фурман, на мой изумленный вопрос, как ему удается программировать на PL-1, просто заметил, что он в уме транслирует все операторы, прежде чем написать их.

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

Именно за эти годы мною и моими товарищами по работе под руководством В. Арлазарова были написаны „Каисса“, „ИНЕС“, АСУ МНТС (Международного научно-технического сотрудничества для ГКНТ СССР) и много конкретных прикладных систем. Где-то в это время нам пришлось расстаться с привычными перфокартами и пересесть за дисплеи, между прочим, – алфавитно-цифровые.

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

Среди них были знаменитые в мире информационных технологий люди – К. Шеннон (автор теории информации), К. Томпсон (автор операционной системы Юникс), Д.Леви, М. Ньюборн, А. Марсланд, Б. Миттман, Ф. Фридель (автор ChessBase) и многие другие.

СУБД „ИНЕС“, в которой я занимался системными вопросами – генерацией и дистрибуцией системы, системой поддержки версий, для чего была написана Архивная Система — и АСУ МНТС, устанавливать которую мне пришлось по всем министерствам и республикам СССР, принесли мне много хороших знакомых по всей стране. В любой город СССР можно было поехать, и везде встречали очень тепло, даже когда устанавливаемые мною системы были принимающим, мягко говоря, не слишком нужны (как сейчас сказали бы, АСУ МНТС снижало коррупционную емкость планирования научных командировок за границу).

И мое тогдашнее хобби – спортивный бридж – тоже было источником многих дружб и знакомств. Не случайно, когда мои американские друзья приезжали в СССР, они, после очередной случайной встречи с кем-нибудь на улице, спрашивали меня „Тебя все здесь знают?“.

С К. Шенноном связана одна из самых удивительных историй в моей жизни. Меня с ним познакомили в 1980 году на чемпионате мира среди шахматных программ в Линце. Каждый чемпионат имеет своего почетного гостя, и в том году им был Клод. Услышав его имя, я подумал „Как! Он еще жив?“. Ведь работы Шеннона по шахматному программированию относились к году моего рождения, то есть для меня он существовал в очень давней перспективе. Оказалось, что ему в год моего рождения было меньше тридцати, и в 1980м он был еще очень не старым человеком. Когда же пришла моя очередь быть почетным гостем чемпионата мира 1999 года в Падерборне, я прочел в глазах молодых шахматных программистов все тот же немой вопрос „Как! Он еще жив?“. И, поняв, что с момента моих публикаций уже прошло больше двадцати лет, я вспомнил Шеннона и успокоился.

В начале 1970-х появились машины серии „Ряд“. Так получилось, что во время моего распределения после МГУ мне пришлось быть свидетелем, как А.С. Кронрод боролся за продолжение проектирования и производства оригинальных советских машин (он даже предлагал назвать серию „АС“ — автоматическая советская — по своим инициалам) против В.М. Глушкова и Л.Т. Кузина, которые ратовали за копирование IBM. Одним из аргументов у последних было то, что можно будет воспользоваться всем математическим обеспечением, созданным для IBM и ликвидировать то небольшое отставание в вычислительной технике, которое имелось в конце 1960-х.

Глушков и Кузин победили (а судьей был председатель ГКНТ Кириллин), но все оказалось не так-то просто. Первый компьютер серии с трудом (титаническим трудом инженеров-электронщиков, запустивших его в жаркое лето 1972 года на ВДНХ, после чего они искупались в фонтане Дружбы Народов) был запущен в 1972 году, а массовая работа на нем – только в 1979 году. Все это время я неплохо зарабатывал лекциями по ОС ЕС ЭВМ. Документация по системе переводилась моими однокурсницами и другими людьми, не представлявшими себе, что такое компьютер вообще и операционная система в частности, и разобраться по такой документации было невозможно.

Таким образом, Глушков и Кузин просчитались именно в этой компоненте – культуре пользования. Теперь я понимаю, что неправ был и Кронрод, за которого я „болел“, потому что надо было и копировать IBM и делать свои машины именно для сохранения культуры. А в итоге к 80-м мы потеряли культуру проектирования элементов, потом и культуру проектирования устройств, а сейчас от нас уходит (вместе с носителями – людьми, которые умеют это делать) культура создания операционных систем.

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

Продолжение:
Жизненный цикл программиста Часть 2
Жизненный цикл программиста Часть 3