Интерстрон: ближайшие планы

Этот текст (см. ниже) на днях появится на сайте компании Интерстрон (www.interstron.ru). Возможно, он окажется интересен и тем, кто время от времени меня читает. Там, в частности, говорится и о состоянии дел с переводом нового стандарта Си++.

Коллеги и друзья!

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

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

- Развитие языка Си++ и его реализация
- Создание новых инструментов разработки

А теперь чуть подробнее.

Новый стандарт Си++ и его реализация

Многие знают, что совсем недавно была опубликована «бета-версия» нового Международного Стандарта Си++ (октябрьский драфт). Формального принятия этого стандарта можно ожидать примерно через полтора года, однако по правилам ISO нынешняя версия уже не должна претерпеть существенных изменений (кроме стилистических и редакторских), так что ее можно рассматривать как практически окончательную.

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

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

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

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

Наш перевод мы собираемся снабдить комментариями, которые будут пояснять некоторые не слишком ясно написанные или просто важные моменты определения языка. Идейным вдохновителем и образцом для нас послужил в первую очередь текст книги Страуструпа, который написал такое комментированное описание языка в 1990 году, к началу процесса стандартизации. Для стандарта языка Ада выпущена отдельная книга с обоснованием всего дизайна языка и его конструкций («Rationale»). Похожая книга имеется и для C# (C# Annotated Standard, Morgan Kaufmann, 2007), так что полезность комментариев подтверждается реальной практикой.

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

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

Новые инструменты проектирования и разработки

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

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

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

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

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

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

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

Первым продуктом из этой серии будет инструмент моделирования и инжиниринга программ, реализующий широкое подмножество графической нотации UML и использующий Си++ в качестве входного и целевого языка. Рабочее название инструмента – Визуализатор, однако собственно «визуализация» программ, то есть представление их в наглядном структурном виде – только очень небольшая часть его функциональных возможностей. Если говорить коротко, то этот продукт обеспечивает достаточно полный спектр типичных операций по моделированию ПО согласно методике, поддерживаемой графическим языком UML (Unified Modeling Language). К числу таких операций относятся обратный и прямой инжиниринг, а также средства документирования и визуализации. Язык UML, реализованный в продукте, соответствует последней на настоящий момент версии 2.1.

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

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

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

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

Ориентировочный срок выпуска книги и Визуализатора – весна-лето будущего года.

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

Следите за новостями!

 

Стандарт С++0x: финальная фаза

Внизу текст сообщения из OpenNET (прямая ссылка).

От себя добавлю: скачав октябрьский драфт (сентябрьский пропустил, каюсь), скорее побежал смотреть главу 14.

И вот: концепты появились!

30.10.2008 19:45  Принятие стандарта языка C++0x вошло в финальную фазу

На очередной сессии комитета ISO по C++, проходившей в Сан-Франциско с 15 по 20 сентября, на общем голосовании был принят проект стандарта языка программирования C++0x. По словам Герба Саттера, председательствовавшего на заседании, результат голосования был достаточно предсказуем - финальная редакция документа практически ни чем не отличается от его сентябрьской рабочей копии. Перед окончательным принятием C++0x в качестве официального стандарта ISO должно пройти еще два раунда согласований в национальных комитетах. На первом этапе, который уже начался, национальные комитеты должны изложить свои комментарии по поводу полученного проекта и подать необходимые усовершенствования. Следующий этап, который начнется приблизительно через год, будет нацелен на исправление неточностей формулировок и общего стиля документа. Внесение кардинальных изменений по сути принимаемого стандарта на этом этапе не предусматривается. Текущую стадию документа можно рассматривать как функционально законченную бета-версию.

Семантическое представление: ответ Анониму

Уважаемый Аноним, спасибо за развернутый комментарий.

Только "спорить"-то не о чем - у нас ведь не спор, а дискуссия...

Вот мои соображения в ответ на Ваши (писать их в виде комментария неудобно, лучше уж новый пост сделать).

На мой взгляд, то, что писал Страуструп в "Дизайне и эволюции", в значительной степени сделано во многих компиляторах и средах программирования для различных языков. Писал-то он давно.

В том-то и дело, что практически ничего из предложенного не сделано!- потому и мой пост. Ну, если что-то и сделано (см. ниже), то частично и - самое главное - для несколько иных целей, нежели кажутся мне действительно актуальными.

Ну действительно, Intellisense есть и в Visual Studio, и в Java-средах программированя, и в Dephi - да где только нет... 

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

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

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

А тут и гадать не надо: код, генерируемый для .NET, по определению несет в себе метаданные - некоторую информацию об исходной программе, которой и пользуется Intellisense. Более того, доступ к этой информаици можно производить кому угодно (программным путем) - из самой программы, из другой программы...

Внутреннее семантическое представление есть во всех компиляторах. 

Это конечно, так, и на первый взгляд выглядит очевидным: внутренние таблицы компилятора, синтаксическое дерево программы - можно считать тем самым семантическим представлением. Однако чуть более глубокий взгляд на ситуацию говорит, что не все так просто. Во-первых, эта информация - сугубо внутренняя, она недоступна извне. Во-вторых, эта информация предназначена исключительно для нужд компилятора (а именно, для контроля ошибок и генерации кода) и потому не слишком удобна для любых менее "стандартных" операций. В-третьих, зачастую эти внутренние структуры данных просто невозможно использовать, так как они практически никогда не существуют как единое целое. Например, внутреннее представление компилятора С++ из Visual Studio создается по частям (для отдельных функций, например) и по частям же удаляется (после генерации кода для это функции). Проделать какую-либо содержательную процедуру, связанную с глобальным анализом программы, пользуясь таким фрагментарным представлением, невозможно. В-четвертых, даже если авторы компилятора дают возможность доступиться к внутренним структурам (например, Ада-компилятор GNAT может сбросить целиком дерево программы на файл), они принципиально не дают никакой гарантии, что в следующей версии формат этого дерева не изменится...

Многие системы используют единое внутреннее представление для нескольких языков (на ум приходят Visual Works и gcc, есть и в VS наверняка).

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

У VS нет единого внутреннего представления. Все языки, представленные в VS, создавались в различных условиях, с разными задачами, в разное время и различными командами. Вообще, VS скрывает в себе немало неожиданностей. Например, там, как говорят инсайдеры, на самом деле два компилятора C# - один обычный, подобный тому, который из командной строки (он запускается по команде Build), а второй - "умный", который находит синтаксические ошибки на лету (в процессе наборра программы в редакторе) и обеспечивает Intellisense. Компилятор VB - один на все виды работ. Что касается плюсового компилятора, то с ним вообще непонятно. Он совсем старый, подкрученный на "живую нитку". Говорят, они собираются его капитально переделывать (якобы, уже начали...)

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

Честно говоря, вопросы "свободно/за деньги" мне параллельны, поскольку они не имеют отношения к тому, что мы обсуждаем. Интерес представляет проблемы, связанные собственно с разработкой и реализацией семантического представления, а не с тем, как оно распространяется. Вот сделаем, тогда и решать будем. :-)

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

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

То есть, непонятно, что нового - в использовании какого-то особого внутреннего представления C++.

Новое заключается в том, чтобы придумать целостное, полное, независимое от конкретного компилятора представление семантики языка Си++, а также программный интерфейс к такому представлению, и, конечно, реализовать этот интерфейс. Этого до сих пор никто не сделал, хотя пара проектов с подобными целями известна (но они либо умерли лет пять назад, либо несколько "сменили ориентацию" в пользу более простых задач). Правда, можно двигаться несколько другим путем: начать с того, чтобы специфицировать интерфейс доступа к семантическому представлению, а потом заниматься реализацией этого интерфейса. Именно так сделано в Ада-мире: был принят стандарт на интерфейс доступа к Ада-программам - ASIS (Ada Semantic Interface Specification), и он был реализован для нескольких Ада-компиляторов.

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

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

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

Ну и я о том же самом писал: нет семантической информации. Где спор-то? :-)

 Даже в устаревающем Delphi уже давно есть откомпилированные модули dcu с кучей метаинформации в заголовке. И линковщик только заглядывает в нее и сразу разрешает внешние ссылки. А в C++ линковщик проделывает гигантскую работу - известно же про скорость линковки проектов на C++...

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

 Я уж не говорю про .NET и Java, где этап линковки ну почти отсутствует - в байт-коде уже хранится нужная информация.

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

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

С байт-кодом (или с MSIL-кодом) проблемы те же: там нет семантической информации об исходной программе. Есть метаданные, но их недостаточно для реализации "умной" линковки. Да и нет метаданных для кода из-под "обычного" С++ (не для Managed C++). А нужда в умной линковке, помимо борьбы с code bloat для шаблонов, заключается еще и в возможности делать глобальную оптимизацию программы, и в возможности ее "умной" и безопасной интерпретации (в частности, для режима отладки). Именно по этим причинам линковка семантического представления предпочтительна.

Мне кажется, что сейчас нужно ставить более прогрессивные вопросы, чем ставил Страуструп 15 лет назад: создание единого семантического представления для группы языков программирования

"Прогресс" - понятие диалектическое. :-) На мой-то взгляд, прогресс в решении даже тех задач, которые Страуструп сформулировл в том разделе, довольно относителен. С другой стороны,

реальный прогресс в той сфере, которую мы обсуждаем, возможен только при наличии соответствующих потребностей со стороны пользователей. Спроси сейчас кого угодно: тебе нужно единое семантическое представление для двух (трех и т.д.) языков? Ответ будет отрицательный. Это не означает, разумеется, что работы в этой области не имеют смысла. Но надо понимать, что это требует довольно фундаментальных исследований. Речь идет, по существу, о том, чтобы спроектировать и обосновать универсальный семантический базис для различных ЯП. Можно запросто (знаю, что говорю :-)) объединить семантические представления, например, для С/С++, Джавы и C# (просто свалить все в одну кучу) и объявить "революцию" свершившейся. Выделить же общие семантические свойства хотя бы двух языков, построить минимальный понятийный базис для них и определить механизм расширения этого базиса - это задача, поверьте, очень-очень нетривиальная...

 и преобразования "во все стороны".

Преобразовапние во все стороны - это как раз несложно. "Одна сторона" (например, текстовое представление) генерируется по "другой стороне" довольно просто. Исходный текст по UML-представлению, например,- сколько угодно.

 Можно также говорить о стандарте внутреннего представления только для C++ и о стандарте хранения его на диске - иначе каждая фирма будет разрабатывать свое и тщательно скрывать от конкурентов.

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

А насчет "скрывать" - мне, честно говоря, не очень интересно, как та или иная фирма будет поступать со своими разработками. Все равно эффект от семантического представления будет виден в продуктах фирмы...

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

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

Страуструп о будущих средах программирования

В августе позволил себе короткий отпуск и взял с собой книгу Страуструпа Дизайн и эволюция языка C++. Вроде, в свое время читал ее (просматривал), но в этот раз обнаружил совершенно замечательный раздел, который раньше как-то прошел мимо меня. Он пишет в точности о том, что сейчас занимает все мои "профессиональные" мысли!

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

9.4.4 За пределами файлов и синтаксиса

Как я вижу среду для разработки программ на С++? Прежде всего - инкрементная компиляция. Если вносится небольшое изменение, то система "понимает", что оно небольшое, и генерирует новую версию программы мгновенно. Моментальные ответы хотелось бы получать также на простые вопросы и указания типа: "Показать объявление f", "Какие еще f есть в области действия", "Как разрешен этот вызов оператора +?", "Какие классы произведены от Shape?" и "Какие деструкторы вызываются в конце этого блока?"

                           Инструмент, который давал бы возможность получать ответы на
                           подобные вопросы,- это в точности то, над чем я сейчас работаю.
                           Основой такой системы должно быть то самое промежуточное
                           представление программ на С++ (я предпочитаю говорить
                           о семантическом представлении), о котором он пишет далее.

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

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

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

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

То, что в основе реализаций С++ лежат символьно-ориентированные инструменты, всегда было главным препятствием на пути развития языка. Если нужно препроцессировать и перекомпилировать каждый заголовочный файл, прямо или косвенно включенный в файл, где находится слегка измененная функция, то для этого требовалось определенное, пусть и небольшое время. Существует несколько методов, позволяющих избежать ненужных перекомпиляций, но, по-моему, наиболее перспективный и интересный подход - отказаться от традиционного исходного текста и положить в основу инструментов абстрактное внутреннее представление. Ранний вариант такого представления можно найти в работах [Murray, 1992], [Koenig, 1992].  Естественно, текст все равно необходим - его вводят и читают пользователи - но он легко преобразуется системой во внутреннюю форму

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

и реконструируется по запросу.

                           А вот реконструкция текста - это действительно несложно.

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

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

                           Ну, и обычными компиляторами переднего плана, разумеется.

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

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

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

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

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

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

Единственная фудаментальная константа - это базовая семантика языка. Она не должна меняться ни при каких обстоятельствах, и, учитывая это, вполне можно выдать С++-код в обычной текстовой форме по запросу.

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

                           У Интерстрона есть линкер промежуточного представления,
                           который делает именно это: компоновку программы на этапе,
                           предшествующем генерации кода. Более того, согласно нашей
                           философии, генерация кода - это частный случай, одна из многих
                           операций, возможных над промежуточным представлением.
                           Можно это представление визуализировать, можно подвергнуть
                           его статическому анализу или оптимизировать, наконец, можно
                           его... исполнить (см. далее)!

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

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

Комментированный стандарт: current state

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

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

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

Шутка, конечно, но приятно :-)

Давно уже встречал этот тест у разных блоггеров, но сам не заходил: боялся опозориться :-). А тут вот взял и... прошел:

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

Там еще такие слова были:

Результаты тестирования
8 из 8 - Поздравляем, вы - вымирающий вид россиянина, отлично знающего свой родной русский язык. Вы один из немногих носителей элитарного знания, доступного в наше время единицам (4% от общего числа опрошенных). Второй вариант: вы - выпускник, которого хорошо натаскали на сдачу экзамена по русскому языку. Третий вариант: вы – репетитор. Или просто закончили филологический факультет и пошли работать не по специальности.

Комментированный стандарт: предварительные итоги

Коллеги и друзья!

Я уже несколько раз писал о своей старой идее выпуска комментированного стандарта C++. Так вот, дело, кажется, сдвинулось с мертвой точки: некоторое время назад мы с коллегами из фирмы Интерстрон (www.interstron.ru) приняли решение о возобновлении этого проекта.

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

Многие в курсе, что сейчас рабочая группа ISO с бюрократической аббревиатурой JTC1/SC22/WG21 готовит новую редакцию стандарта C++. Скорее всего, окончательный текст будет готов к концу этого года, но формальная процедура принятия нового стандарта завершится не раньше, чем еще через год, а то и позже; по крайней мере, так оценивает сроки Страуструп). Нам показалось бессмысленным ждать момента формального принятия, и мы решили взять за основу нашего текста последнюю на настоящий момент версию (от февраля нынешнего года) предварительного стандарта («Working Draft», документ №2521, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2521.pdf).

Конечно, с формальной точки зрения Working Draft – это не стандарт. Однако, наш опыт работы с предыдущей редакцией стандарта от 1998 года (а тогда мы писали наш компилятор C++ параллельно с процессом стандартизации и вынуждены были оперативно отслеживать изменения, производимые в нем) показывает, что на завершающих этапах серьезных добавлений в текст уже не вносится. Разумеется, мы будем вносить в наш текст последующие изменения, которые появятся в новых драфтах,- вплоть до момента сдачи книги в типографию, насколько это будет в наших силах.

К данному моменту текст предварительного стандарта практически полностью переведен. Это основной итог напряженной работы последнего времени. На следующей неделе мы начинаем активную деятельность по анализу текста: собираемся определить, какие положения стандарта требуют комментирования, в чем должен состоять комментарий и т.д. Следующий этап – собственно комментарии. Да, кроме перевода и комментариев, текст будет включать дополнительные материалы: толковый словарь понятий C++ («Краткий стандарт», или просто «Краткий курс» :-)), обоснование выбранных вариантов перевода технических терминов, синтаксические диаграммы и кое-что еще.

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

"Редкая профессия" на сайте Интерстрона

Типа информация. :-)
Моя давняя-давняя статья "Редкая профессия", о том, как мы делали компилятор C++, выложена на сайте фирмы Интерстрон (www.interstron.ru). Статья вышла в конце 1997 года в PC Magazine/Russian Edition, довольно долгое время лежала у них в электронном архиве, но недавно исчезла (наверное, в связи с десятилетним юбилеем :-)) По этой причине я счел естественным опубликовать ее на сайте "своей" фирмы, подправив кое-какие ляпы и опечатки (не все, к сожалению).

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

Прямая ссылка на статью:
http://www.interstron.ru/upload/images/pubs/Redkaya_professiya.pdf
Enjoy! :-)

Да, чуть не забыл. Вопрос к читателям (на сто тысяч):
Если вы смогли одолеть этот довольно длинный текст, то как бы вы отнеслись к появлению статьи под условным заголовком "Редкая профессия: десять лет спустя" - с рассказом о том, что последовало за описанными событиями, и о некоторых других похожих проектах? Не умею устраивать голосование на блоге (да и не хочу заморачиваться, честно говоря), но узнать интегральное мнение было бы очень интересно...

UPD: Оказывается, статья не исчезла, а просто переехала на другое место в связи с редизайном сайта PC Magazine/RE. Прошу прощения за ошибку, и спасибо Олегу Лебедеву за поправку. Вот новая ссылка на статью.

Интервью Б.Страуструпа

Недавно, 27-го марта, в Dr. Dobb’s Journal было опубликовано очередное интервью Б.Страуструпа. Заметная часть интервью либо повторяет более-менее известные исторические обстоятельства появления C++, либо содержит любопытные (хотя тоже ранее озвученные) взгляды автора этого языка на обучение программированию. Самое же для меня интересное – информация о готовящемся новом стандарте C++ (кодовое наименование C++0x). Вот наиболее важное в вольном пересказе.

Срок

Новый стандарт языка (по плану?) должен быть готов к концу 2008 года, но все процедуры ISO, связанные с его официальным принятием, обычно занимают много времени. Поэтому то, что сейчас известно под именем C++0x, скорее всего, станет C++10.

Стандартная библиотека

Нововведения в стандартной библиотеке хотя и существенны, но, по его мнению, недостаточны. Добавлены потоки (threads), регулярные выражения, хеш-таблицы (которые изначально присутствовали в оригинальной STL, но не были внесены в предыдущий стандарт), "умные" указатели. Много усовершенствований внесено в существующую библиотеку контейнеров. Наконец, в язык добавлен ряд низкоуровневых свойств (новая модель памяти и задачная библиотека - task library),которые, как он говорит, не предоставляют непосредственных выгод для программистов, но скорее призваны служить основой последующих нововведений (которые откладываются до так называемого "C++13"): разделяемая память, пулы потоков (thread pools), распределенное параллельное программирование. С другой стороны, эти новые свойства уже используются в некоторых мощных коммерческих библиотеках.

(Кстати, один очень интересный момент: Страуструп несколько раз на протяжении интервью жалуется на совершенно недостаточное финансирование процесса стандартизации, из-за которого некоторые важные нововведения в стандартной библиотеке так и не были должным образом рассмотрены и из-за этого в новый стандарт уже не попадают. Причем это высказано в достаточно резких выражениях: «the committee has so few resources», «absolutely no funding» и т.п. Это удивительное для меня обстоятельство: ISO, оказывается, недостаточно финансирует свои комитеты!.. А казалось бы: уважаемая международная организация, важность которой никем не подвергается сомнению, работающая эффективно, тщательно и весьма результативно...)

Нововведения в язык

Основной мотив добавления большинства новых свойств - повысить уровень языка введением полезных высокоуровневых абстракций, которые бы способствовали созданию более ясного и хорошо организованного кода без дополнительных затрат по времени выполнения и требуемой памяти (это почти буквальная цитата). К числу таких свойств относятся обобщенные константные выражения (generalized constant expressions), статические утверждения (static assertions), ссылки на r-значения (rvalue references), а также новые возможности задания перечислимых типов.

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

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

Будущее C++ после принятия нового стандарта

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

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

Lisp на "Эльбрусе" (вторая предыстория)

Очень скоро после того, как я отошел от идеи реализовать на "Эльбрусе" полный Lisp, в журнале "Программирование" (очень неплохой был журнал; он жив и посейчас, но никто о нем, кажется, не знает и не вспоминает...) вышла статья А.Рейтсакаса из Таллина... ровно на ту же самую тему: Lisp на "Эльбрусе"!

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

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

Конечно, у меня нашлись объяснения. Мы находились совершенно в разных обстоятельствах: Саша работал в Академии Наук Эстонской (тогда еще) ССР, реализация Лиспа была темой его диссертации и, тем самым, основной обязанностью "по службе". Мой же "проект" был полнейшей самодеятельностью, и надеяться, что начальство позволит мне уделять рабочее время теме, хоть и интересной самой по себе, но решительно не относящейся к тематике нашего "ящика", не приходилось.

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

И - закон парности событий! - примерно в это же самое время появилась еще одна работа, тематически очень близкая: московский аспирант (как же его имя?- кажется, Володя Лихолип... Если ошибся, прошу извинить - все-таки много лет прошло) реализовал для того же "Эльбруса" язык Плэнер (Planner), довольно часто упоминавшийся тогда в литературе, а ныне, кажется, совершенно забытый. Planner предназначался для программирования ("планирования", отсюда и название) поведения роботов и содержал в себе полный Lisp как подмножество. Помимо этого, в нем, помнится, был целый ряд нетривиальных и очень интересных свойств, делающих его мощным инструментом программирования в сфере искусственного интеллекта и подобных областях.

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

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

Впоследствии мне еще несколько раз приходилось испытывать подобные чувства: и когда я познакомился с новосибирскими разработчиками PL/I и Ады, и когда В.О. Сафонов из Питера рапортовал о рекордном быстродействии своего Паскаль-компилятора, который обгонял даже "родной" для "Эльбруса" компилятор Эль-76... Я был чужим на этом празднике жизни, занимаясь системным администрированием, поддержкой и обучением пользователей, разрабатывающих для "Эльбруса" "боевые алгоритмы", смысла которых я почти не понимал...

Основной вывод, который я сделал для себя тогда... Да вру, никаких выводов я не сделал. Просто порасстраивался, и продолжал жить дальше. В конце концов, у меня еще все впереди, появится и у меня классная компиляторная работа!.. (десять лет пришлось ждать...)

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

В середине девяностых мы, уже работая в МГУ, активно занимались языком C++, делая компилятор по заказу одной европейской фирмы (см. "Редкая профессия"). Наша работа шла параллельно процессу стандартизации C++ в ISO, и от наших заказчиков мы регулярно получали текущие материалы рабочей группы, занимающейся разработкой этого стандарта - стенограммы обсуждений, принятые технические решения, планы и т.д. И вот у моего шефа, профессора В.А.Сухомлина, возникла идея более тесно и, самое главное, официально участвовать в этом процессе в качестве представителей от России. Основания были более чем весомые: наша команда работала над реализацией языка, основываясь на последних решениях рабочей группы, кроме компилятора, мы разрабатывали тесты на соответствие стандарту - так почему бы нам более активно, с учетом собственного опыта, не участвовать в работе этой группы?

До той поры контакты с рабочими группами ISO по различным языкам формально шли через какой-то отдел НИЦЭВТа - конторы, которая в советское время занималась разработкой ЭВМ Единой Серии. Несмотря на несколько ироническое отношение к характеру и качеству их разработок (все специалисты прекрасно знали и понимали степень "оригинальности" их решений), следует признать, что с чисто промышленной точки зрения эта организация делала очень важное дело, занимаясь масштабным внедрением вычислительной техники во все отрасли народного хозяйства. Да и, кроме того, за ЕС ЭВМ надо признать по крайней мере один большой плюс: унификацию периферийного оборудования, в том числе их интерфейсов. Дисковые и ленточные накопители, дисплеи, графопостроители и другая периферия на "Эльбрусе" вся была ЕСовская. Правда, со смертью обеих этих ветвей отечественной вычислительной индустрии все это потеряло всякий смысл и значение...

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

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

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

(Спаведливости ради - и, так сказать, для баланса - должен заметить, что примерно в те же времена один из "конкурентов" НИЦЭВТа, институт, где проектировались, создавались и программировались "Эльбрусы" - ИТМиВТ - выглядел не лучше. Такая же пустота и запустение. Правда, ощущения сбывшегося апокалипсиса не возникало - но и то лишь из-за сравнительно скромных размеров эльбрусовского "гнезда"...)

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

Быстро попрощавшись с зябнущим хозяином комнаты, я с деловым видом подхватил сумку и вышел, стремясь поскорее покинуть это умирающее место (и страшась: вдруг меня остановят и заставят вернуть награбленное :-)). Надо ли говорить, что среди материалов по C++, в сумке лежало много документов, к этому языку не имеющих никакого отношения. А среди них - рабочий вариант международного стандарта языка Lisp!..

5 инструментов, без которых я не могу работать продуктивно

У Алены Сагалаевой увидел приглашение поучаствовать в опросе (спасибо, Алена!). Получилось довольно длинно, так как без комментариев обходиться не умею. :-)

Для начала хотел бы сравнить инструменты, которыми я пользовался в процессе разработки компилятора Си++ (десять лет назад), и теми, с которыми работаю сейчас.

                      1998                    2008
Файловый менеджер     Norton Commander        Total Commander
Компилятор            gcc                     C++/C# из VS
Отладчик              gdb                     Отладчик VS
Текстовый редактор    Multi-Edit              Редактор VS
Ведение версий        CVS                     SourceSafe
Интернет-броузер      Netscape                Internet Explorer
Почтовая программа    Netscape Communicator   Gmail
Персональный организатор                      The Journal, Onfolio

Несколько комментариев.


Файловый менеджер
Я довольно консервативен, да и просто не вижу причин менять привычную парадигму манипуляций с файлами/каталогами. Модель с двумя окнами кажется мне удобной и совершенно адекватной подавляющему большинству практических потребностей. Встроенный в винду Windows Explorer, на мое скромное имхо, безумно коряв с эстетической точки зрения и очень неудобен в работе (даже для рядовых пользователей); даже если потратить довольно много времени на его настройку, результат явно неудовлетворителен. Кстати, никакими плагинами к TC не пользуюсь, может, зря – но времени жалко их выбирать, ставить, пробовать, проверять... Единственный недостаток TC – он довольно медленно работает с большим количеством файлов (несколько сот штук) зараз. Впрочем, может быть, это не он виноват, а нижележащая ОС, но мне лень копаться в настройках самой винды...

Компилятор
Отладчик
Редактор
Ведение версий
Visual Studio, по моему мнению,- очень хорошая интегрированная среда, и я не разделяю практически ни одного из критических замечаний о ней, которые мне приходилось слышать. Inellisense и другие удобства, которые некоторые презрительно именуют "свисточками и звоночками", реально помогают мне программировать и существенно облегчают и ускоряют мою работу. К сожалению, для работы с Си++ и в особенности с ASP.NET уровень поддержки со стороны среды заметно слабее, чем для C#. Версию VS не указываю, так как использую несколько на разных компьютерах.

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

Интернет-броузер
Я ни разу не фанат ни самого Микрософта, ни его продуктов, но - опять-таки - считаю, что IE - вполне приличный инструмент, и не испытываю серьезных проблем в работе с ним. Да, иногда он тормозит и даже, бывает, слетает, но кто скажет, что другие приборы всегда быстры и супернадежны? Кроме того, мне важно, что с ним интегрирован Onfolio (см.ниже). Да и вообще, чтобы перейти на другой броузер, мне нужны - кроме простого человеческого любопытства - достаточно весомые причины...

Почтовая программа
Плюсы GMail всем известны - быстрота, простота, надежность - у меня ни разу не было проблем вроде пропажи аккаунта или (части) писем. Письма приходят ко мне и от меня к моим адресатам без заметных задержек, что иногда случалось с другими почтовиками. Вполне приличный спам-фильтр. Плюс, конечно, возможность зайти в него отовсюду, где есть связь.

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

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

Отсутствие необходимости удалять ненужные письма, тоже выставляемое как просто-таки потрясающе революционное свойство - на самом деле очень смешная вещь: совершенно непонятно, почему пользователи должны бурно радоваться этому обстоятельству? Мы ведь все периодически убираем наши рабочие комнаты и рабочие компьютеры от ненужных бумаг (файлов), которые имеют обыкновение скапливаться на столах, в тумбочках и на жестких дисках с необыкновенной быстротой? И что будет, если нам вдруг скажут: ребята, теперь у вас в компьютере огроменный жесткий диск (если надо будет, еще один такой же поставим), поэтому операцию "удалить файл" вам теперь использовать нельзя?.. (Кстати, где-то читал, что поначалу кнопки "Удалить" в GMail не было вообще, и ввели ее с большой неохотой только по настоянию пользователей...)

Вообще, рискуя навлечь на себя шквал критики, скажу о некотором сходстве философии авторов GMail и... языка Си (!!!). Как мне кажется, оба эти инструмента создавались (кстати, и тот и другой - двумя друзьями!) согласно очень схожей философии: то, что удобно нам, авторам, будет, разумеется, удобно и всем остальным - как же может быть иначе? Вот и появилась совершенно безумная по дизайну нотация ("понятная, разве что, специалистам по криптографии", как сказано в одной старой книге), к которой, однако, привыкла тесная компания разработчиков UNIX, и почтовая программа, в которой все письма лежат бессистемной кучей, а единственным средством в этой куче разобраться служит "революционный" поиск нужного письма по куску текста из него, который несовершенная наша память успела запомнить...

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

Персональные организаторы
(Схитрил: в одну позицию запихал сразу две программы, но они того стоят): The Journal и Onfolio.

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

The Journal (http://www.davidrm.com/) – в нем я веду профессиональный дневник (только для себя), сохраняю наиболее важные письма, готовлю тексты для блога, составляю и веду различные рабочие планы и вообще, храню всю текстовую информацию, имеющую отношение к моим проектам. Очень удобная программа: то, что действительно важно, она автоматизирует (например, ведение дневника), второстепенные детали оставляет на усмотрение пользователя. Документы можно организовывать в виде древовидной структуры любой сложности. С точки зрения дизайна программа вполне традиционная и не требует много времени на освоение. Встроенный редактор сделан на движке от Ворда и предоставляет вполне адекватную моим потребностям функциональность, включая хорошую поддержку таблиц. Вполне отрабатывает свои 40 долларов :-).

Onfolio – средство для сбора информации из Интернета. Можно собирать и структурировать ссылки и делать вырезки из страниц сайтов. Есть известное количество программ, предоставляющих аналогичный сервис, но для меня эта - однозначно лучшая. Вырезает куски на редкость адекватно, с полным сохранением оформления, позволяет редактировать вырезанное (правда, редактор все-таки слабоват). Структурируется информация традиционными парадигмами – есть понятие коллекции, в которой можно создавать каталоги, а в них – записи. Коллекция – это просто файл. При вырезании запоминается дата и адрес источника, можно добавлять свои атрибуты (заголовок, описание, цветной флажок). Очень не хватает тегов, средств упорядочения каталогов и цветового выделения заголовков записей. Собранные коллекции (части коллекций) можно экспортировать в виде единого mhtm-файла, который прекрасно отображается броузером. Разумеется, в записях можно хранить не только вырезки, но и произвольные тексты, PDF-документы, фотографии и прочее... Есть фид-агрегатор, но я его не использую. Программа встраивается в IE (в панели Windows Live Toolbar появляются дополнительные кнопочки) и управляется очень просто. Кроме плагина для IE, в комплекте есть и независимый вариант: Onfolio Deskbar.

В свое время я по-честному купил Onfolio и с удовольствием юзал ее года два, но в один прекрасный день фирму-разработчика купил Микрософт, и программа стала бесплатной составной частью Windows Live :-). Ссылку не даю – потерял, а снова искать лень. Программу точно можно найти в недрах микрософтовского сайта, но придется немного покопаться: прямая ссылка из раздела Windows Live не работает, придется искать обходные пути. Но она там точно лежит! :-)

Передаю эстафету (только троим; к сожалению, не все коллеги, предпочтения которых могли бы быть интересны, ведут свои блоги):

Александр Кротов
Дмитрий Гурьев
Сергей Розовик