The lonely compiler

Зачем Сколкову Микрософт?

2011-01-19T12:13:00.010+01:00

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

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

Так вот, что-то у меня возникли сомнения: действительно ли Сколково создается для таких коллективов? Эти сомнения появились, когда я прочитал, что в Сколково приглашаются... Микрософт, Cisco, Интел и (кажется) IBM. Причем, сообщения о (только даже предварительном!) согласии этих монстров сопровождались напыщенной просто-таки до неприличия городостью: смотрите, какие гиганты поддерживают и одобряют нашу инициативу и готовы, так сказать, влиться!..

Вот это мне как раз решительно непонятно! В самом деле, объясните мне, уважаемые авторы идеи: каким именно образом наличие в Сколково Микрософта может послужить делу модернизации/инновации???? (Дело, конечно, не в Микрософте как таковом: вместо него можно подставить любого гиганта из приведенных выше.)

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

Я хочу быть правильно понятым: я вовсе не против того, чтобы Cisco работала в России, и не призываю гнать "проклятых капиталистов" из страны "потенциального противника" каленой метлой. Чем больше таких "исследовательских центров" западных компаний будет, тем лучше. (Они, собственно, и сейчас возникают, и далеко не только в Москве/Питере.) Я только не понимаю одного: почему их так активно тянут именно в Сколково, которое, судя по заявлениям авторов инициативы, создается все-таки для поддержки перспективных разработок отечественных коллективов???

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

Дальше. Может быть, гигантов пускают в Сколково, чтобы они там на свои средства что-нибудь организовали? Ну там, "компьютерный класс" обрудовали? :-) Наверное, такое может быть, но, ей-Богу, это как-то несерьезно. Кроме того, объявлено ведь, что государственных денег в Сколково вбухивается немерено - может, и не нужны дополнительные вливания от того же Cisco?

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

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

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

В России - но не в Сколково! Оно для другого задумано.

Или... для того самого?..

Интерстрон: реализация нового стандарта Си++

2011-01-13T14:23:00.005+01:00

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

1. Спецификатор типа auto для переменных.
2. Спецификатор decltype.
3. Подряд идущие закрывающие угловые скобки >> в списках параметров шаблонов.
4. Конструкция static_assert.
5. Спецификатор extern для шаблонов: extern template.
6. Расширенное friend-объявление вида friend T, где T - параметр шаблона.
7. Предопределенная переменная __func__ для функций.
8. Обобщённые константные выражения.
9. R-ссылки и ref-квалификаторы.
10. Константа nullptr.
11. Шаблоны с переменным числом параметров (variadic templates).
12. Расширенные enum'ы.
13. Списки инициализаторов.
14. Спецификатор inline для пространств имен: inline namespace.
15. Шаблонные алиасы (template<...> using <новый тип> = ...)
16. Задание =delete и =default для функций.
17. Описатель explicit для функций преобразования типа.
18. Ослабление требований к union'ам.
19. Делегирование конструкторов.
20. Наследование конструкторов.

- ну и довольно много мелких усовершенствований.

В процессе реализации находятся такие свойства, как инициализаторы для нестатических членов класса и - конечно же!- лямбда-выражения и альтернативный синтаксис объявления функций (с типом возврата в конце после "стрелочки" ->). По нашим планам это будет ближе к концу февраля.

За такие вещи, как пользовательские литералы, циклы с range, атрибуты и конструкторы перемещения (move-конструкторы) пока не брались.

Сколково: угол зрения

2011-01-11T17:14:00.011+01:00

Ажиотаж в электронной (другой не читаю) печати насчет сколковской инициативы прошел, интенсивность обсуждений спадает, а я только спохватился. :-) Вот такое нехитрое соображение насчет всего этого.

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

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

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

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

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

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

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

Веб-сайт

2011-01-03T17:57:00.003+01:00

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

Вот, прошу любить и жаловать:

eugene.zouev.name

(обратите внимание, без www!)

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

В общем, не судите строго. :-)

Перевод Стандарта Си++

2011-01-03T17:50:00.002+01:00

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

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

Я очень хочу выпустить также и электронную версию; переговоры об этом тоже ведутся.

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

Перевод стандарта: последние новости

2010-10-15T11:38:00.005+02:00

Вот самая свежая информация.

Первое. Перевод полностью готов: написан (включая все запланированные приложения), отформатирован для печати, и все такое прочее. Больше 700 страниц текста формата А4. Более того, уже была договоренность с типографией о выпуске пробного тиража в 1000 экземпляров. И еще более того: была запланирована презентация книги на выставке CHIPEXPO в конце этого месяца...

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

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

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

Конференция "Разработка ПО 2010"

2010-10-13T16:40:00.003+02:00

В пятницу 15 октября выступаю на конференции "Разработка ПО 2010". Вот сайт конференции. Мое выступление (если организаторы в очередной раз не изменят расписание :-)) в 11.15 в комнате С, в самой маленькой из имеющихся аудиторий. Я не в претензии: мой доклад "Семантические интерфейсы языков программирования" вряд ли вызовет большой приток публики. :-)

Вроде бы, туда можно прийти даже без регистрации, просто послушать. Надо только иметь с собой паспорт. Адрес (где-то в районе Курского вокзала) и полное расписание есть на указанном сайте. Кстати, в ту же пятницу, в 16.30 там выступает Страуструп: "Введение в С++0x".

(Это я рекламирую конференцию по просьбе организаторов. :-))

Новости (важные!) о выходе перевода Стандарта С++ последуют завтра.

Code Contracts в .NET и монополия C#

2010-03-28T17:49:00.024+02:00

В последней (четвертой) версии .NET и, соответственно, в VS2010, появились средства спецификации параметров, пред- и постусловий, инвариантов классов и всего того, что с подачи Бертрана Майера называется Code Contracts или Design by Contract.

Вот пара ссылок:
- Объява из Микрософта;
- Список статей по теме.

Неутомимый и вездесущий Дино Эспозито уже, конечно, отозвался на это новшество несколькими постами:

- Assert/Assume
- Invariants
- Preconditions
- Postconditions

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

Многие интересующиеся об этом уже знают, но вот что интересно заметить. Возникает ощущение (и чем дальше, тем больше это ощущение крепнет), что Микрософт стремится втиснуть в .NET поддержку всего, что вообще есть в программировании. Начав с введения в виртуальную машину и MSIL нормальной системы типов и стековой модели выполнения, адекватной императивным языкам (и, естественно, отразив все это в базовом языке C#), они постепенно начали добавлять - и в систему, и в язык - все новые и новые возможности, иногда даже приниципиально отличающиеся от императивной парадигмы. Типовая параметризация, технология LINQ, динамическая типизация, теперь вот - контрактное программирование.

Каждое отдельное нововведение объясняется вполне понятными причинами: и обобщенное программирование нужно и полезно (кто спорит?), и работа с БД непосредственно из программ, и поддержка функциональной парадигмы ("функциональная мафия" из Кембриджского отделения Microsoft Research активность не снижает :-)), и динамическая типизация нужна, чтобы поддерживать скриптовые языки...

Принципиально важно в контексте моих рассуждений то, что все эти новшества получают свою поддержку в базовом языке. И вот в один прекрасный день обнаружится, что программировать под .NET имеет смысл только в этом базовом языке - в C# есть все, и это "все" адекватно поддерживается платформой .NET!

Наверное, я несколько сгущаю краски, и всегда останутся энтузиасты, предпочитающие и в .NET программировать на F#, Nemerle, Хаскелле, Питоне. Просто ниша для использования этих языков в рамках .NET сузится до совершенно микроскопических размеров.

Но вот как быть с такими промышленными языками, как Eiffel и Scala? С введением поддержки контрактного программирования C# практически полностью "покроет" почти все преимущества Эйфеля, а то немногое особенное, что еще есть в этом языке, вряд ли окажется причиной выбора этого языка для реальных проектов. И сейчас не очень понятно, какова популярность Эйфеля как такового (в индексе TIOBE он сильно ниже первых пятидесяти языков), а его присутствие в мире .NET кажется совершенно эфемерным...

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

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

"Пусть расцветает тысяча цветов" (или как это китайцы говорили)...

Перевод Стандарта С++: финиш близок

2010-01-07T13:41:00.004+01:00

В конце ноября появились сразу две очередные версии черновика стандарта (драфта): документы с номерами n2960 и n3000. Пришлось заново проходить весь перевод, вносить правки и переводить новые фрагменты.

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

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

В чем существо модификаций:

- Разделы 14.10 и 14.11 о концептах удалены полностью. Также удалены все ссылки на него и на его подразделы, а эти ссылки были разбросаны по всему тексту.

- Раздел 5.1 (он превратился в подраздел 5.1.2) о лямбда-выражениях полностью переписан. Слава Богу, в нем появились примеры, так что самому не нужно теперь их придумывать (а уж собрался было). Однако, переводить пришлось все заново.

- Очень много мелких правок по всему тексту. Где опечатка исправлена, где уточнение сделано... Вносить их нетрудно, но все равно, занятие это на редкость занудное.

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

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

Зато будет несколько собственных приложений, и вот их-то я сейчас и готовлю. Очень коротко, что там будет:

- Сводка основных понятий/свойств языка: название (в оригинале и в переводе), его определение, ссылка на место в стандарте и, возможно, комментарий. В общем, "Краткий курс" С++ :-)

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

- Грамматика С++ в форме входного языка YACC/Bison. Разумеется, корректная (иначе и приложение из нее делать не стоило :-)), то есть, по ней Bison и некоторые известные его аналоги в состоянии сгенерировать правильный распознаватель. В грамматике, правда, сделаны кое-какие допущения (в чистом виде грамматика С++ в "бизонной" нотации непредставима), но что удивительно и замечательно, удалось свести эти допущения к совершенному минимуму. Технические подробности будут там же в комментариях.

Похожая грамматика С++ была в свое время опубликована в виде приложения к русскому переводу книги Ахо/Ульмана ("Dragon Book") - но здесь я целиком ее переписал, учтя все новые синтаксические конструкции.

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

- Удаленные разделы о концептах. Хотя концепты, по всей видимости, будут радикально переделаны, да и произойдет это только в будущих версиях стандарта, мы все-таки опубликуем эти удаленные разделы, пусть и в виде приложения. Определенная ценность в них есть, да и проделанной работы по переводу жалко. :-) К тому же, многие просят и советуют оставить.

Вот как-то так... :-)

Заспамили...

2010-01-04T17:39:00.003+01:00

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

"Хорошо пишете. Надеюсь, когда-нибудь увижу нечто подобное и на своем блоге…"

"Без особого преувеличения можно точно сказать, что пост тему раскрыл на все 100 процентов"

"Да уж… Тут как говорится: Амбар крепок, да углы худы"

"Так-так… надо будет присмотреться к этой области"

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

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

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

А пока - всех с Новым годом!!!
(В России, вроде, еще каникулы, а у нас в Европах праздники кончились, настали рабочие будни...)

Опять хвастаюсь :-))

2009-11-16T12:58:00.000+01:00

Шпрехен зи руссиш?

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

Зуев прошел этот тест с результатом:

Ни одной ошибки! Столь доскональное знание русского языка выдаёт в вас профессионала.

→ Пройти тест "Шпрехен зи руссиш?"
→ Все познавательные тесты на ШколаЖизни.ру

Хвастаюсь :-)

2009-10-08T16:24:00.003+02:00

Хотя моей заслуги тут никакой, но все-таки...

Опубликован рейтинг двухсот лучших университетов мира за 2009 год.

http://www.timeshighereducation.co.uk/Rankings2009-Top200.html

ETH Zurich, в котором я проработал шесть лет,- на 20-м месте: лучший университет в континентальной Европе (выше только штатовские и английские универы).

EPFL Lausanne, где я работаю сейчас,- на 42-месте.

Для сравнения: МГУ на 155 месте, питерский универ - на 168-м

(в МГУ, впрочем, я тоже работал :-))

Хорошо забытое старое

2009-10-01T15:57:00.006+02:00

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

Пересмотренное сообщение об Алголе-68. Москва, "Мир", 1979 год. Под редакцией А.П.Ершова.

Вот скан обложки:

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

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

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

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

Так что ничего я не выдумал - все уже было...

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

Концепции или концепты?

2009-07-23T12:30:00.004+02:00

Появился комментарий такого рода:

...давайте концепции не будем обзывать концептами?

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

Конечно, английское concept вообще-то переводится на русский как "концепция", "понятие". Но, как мне кажется, было бы неправильно буквально использовать такой вариант перевода. Дело в том, что "прямой" перевод обозначает - по крайней мере, в русском языке - нечто обобщенное, абстрактное. Некую идею, на основе которой строится какая-то теория, система взглядов и т.п. Например, "концепция бесконечности Вселенной" или что-то подобное.

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

В английском языке, по-моему, не столь чувствуются подобные тонкие смысловые различия, потому они довольно легко используют для нового понятия любое более-менее подходящее слово. Не сомневаюсь, что они запросто могут выдать что-то вроде the concept of concepts. Но сказать по-русски "понятие концепции" или "механизм концепций" - как хотите, но это ужасно и выглядит как насилие над языком, и никто не заставит меня это повторить...

И последнее: пафос комментария словно бы предполагает, что C++ concepts уже широко обсуждаются в русскоязычных источниках и там уже вовсю называются концепциями. Рискну предположить, что это все-таки не совсем так. :-)

По всему по этому: только концепты. :-))

Concepts are gone!!

2009-07-23T11:54:00.004+02:00

Многие уже знают, но все равно: ошеломляющая новость!

Комитет по стандартизации C++ проголосовал за удаление механизма концептов из нового Стандарта Си++.

Вот ссылка, по которой рассказываются детали и обсуждаются причины и последствия:

http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441

Вот на что упал взгляд при первом чтении (перевод вольный):

В понедельник 13 июля на очередном заседании комитета по стандартизации С++ во Франкфурте по результатам голосования концепты были удалены из C++0x. Эта шокирующая новость вызывает множество вопросов и беспокойств... Когда я впервые об этом услышал, я просто не поверил... Концепты представляли собой наиболее существенное добавление в ядро С++ с 1998 года (с момента выпуска первого стандарта - Е.З.). В течение последних пяти лет обсуждение механизма концептов проходило на каждом заседании комитета... После десятков официальных сообщений, описаний и статей, посвященных представлению и продвижению концептов, казалось крайне маловероятным, что непосредственно перед финишной чертой, в результате драматического голосования этот механизм будет выброшен...

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

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

Примеры комментариев

2009-07-17T16:19:00.008+02:00

По просьбе Ilya Kulakov привожу два примера того, как могли бы выглядеть комментарии.

Первый пример (не знаю, хорошо ли будет видно...):

(Для особо внимательных: в этом кусочке есть опечатка. Она уже исправлена. Капчу переделывать лень. :-))

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

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

Перевод Стандарта: на распутье...

2009-07-16T17:17:00.004+02:00

Тут вот какое дело.

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

Комментарии! Проблема в том, что их... не то чтобы мало, но недостаточно для того, чтобы дать всей работе в целом некое новое качество, сделать ее в каком-то смысле уникальной - ну и, конечно, полезной для программистов и вообще всех, так или иначе причастных к разработке программ на Си++.

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

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

Какой вариант правильный - честно, не знаю. (И немного рассчитываю на "помощь зала" :-)).

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

- Скачать текст предварительного Стандарта.

- Найти в нем раздел/абзац, относящийся к интересующей теме.

- Написать к нему комментарий!

- Прислать его мне. :-)

Может, попробовать?

Если кому-то это предложение покажется интересным, то вот некоторые детали:

- Текст предварительного стандарта находится по адресу
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf

- Комментарии пишутся по-русски

- Комментарий должен явно относиться к конкретному абзацу или разделу текста

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

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

- Комментарии могут содержать ссылки на известные публикации, типа книг Страуструпа, Саттера, Александреску, Мейера и т.д., в которых комментируемое свойство объяснено подробнее и понятнее, чем в Стандарте. Допускаются прямые цитаты из подобных источников (разумеется, с указанием этих источников).

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

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

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

(Расписался... Начал "заупокой" и в процессе сам увлекся этой идеей. :-))

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

- Лямбда-выражения (раздел 5.1.1) - текст короткий, но важный, и ни одного примера!- вот бы кто-нибудь с "функционально-устроенной головой" высказал свое отношение! :-))

- Шаблоны в целом (глава 14) и механизм концептов в особенности (разделы 14.9, 14.10)

- Совместное использования (глава 13)

- Обработка исключительных ситуаций (глава 15)

Вот как-то так. :-)

Новое в Си++: концепты

2009-07-09T13:30:00.005+02:00

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

Обзор по моей просьбе написан Станиславом Михалковичем, доцентом Южного Федерального университета (Ростов-на-Дону), и выкладывается здесь с его любезного разрешения. Я сделал только очень небольшие редакторские правки и добавил немного замечаний (синим шрифтом), иногда эмоционально-окрашенных. J

В обзор вошли не все аспекты механизма концептов; в частности, ничего не сказано об архетипах и аксиомах. Но не все же сразу. J От обсуждений типа «зачем это нужно», «нужно ли вообще» давайте пока воздержимся. В том или ином виде ограничения на параметры шаблона можно задавать почти во всех современных языках, содержащих подобные средства: в Аде, в Java/C#, в Scala.

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

Рассмотрим вначале пример шаблона стандартного алгоритма find без использования концептов:

template<typename Iter, typename V>
Iter find(Iter first, Iter last, V v) {
while (first != last && *first != v)
++first;
return first;
}

Очевидно, что тип Iter должен удовлетворять следующим условиям:

Объекты типа Iter должны быть сравнимы на !=.
К объектам типа Iter можно применять префиксную операцию ++.
Объекты типа Iter можно разыменовывать.

Кроме того, имеется условие, связывающее типы Iter и V:

Разыменованные объекты типа Iter можно сравнивать с объектами типа V на !=.

В C++ стандарта 1998/2003 гг. проверка данных условий осуществляется при настройке шаблона. Например, при компиляции вызова find(1,5,0) в результате выведения получим: Iter=int, V=int. При попытке компиляции тела функции find с указанными типами возникнет ошибка: условие 3 не выполняется. Таким образом, ошибка компиляции возникнет на достаточно позднем этапе – при попытке компиляции тела настроенной версии find<int,int>. На практике это приводит к неадекватным по существу и совершенно безумным по форме диагностическим сообщениям, в которых фигурируют длиннейшие абсолютно нечитаемые имена настроенных шаблонов (в которых уже сделаны подстановки).

Рассмотрим теперь версию того же алгоритма find с использованием концептов:

template<typename V>
requires EqualityComparable
Iter find(Iter first, Iter last, V v) { ... }

Здесь тип Iter удовлетворяет концепту InputIterator, содержащему требования 1, 2 и 3, а также типы Iter::value_type и V связаны концептом EqualityComparable, содержащим требование 4. Теперь при вызове find(1,5,0) компилятор осуществит проверку типов Iter=int и V=int на соответствие концептам InputIterator и EqualityComparable, и мы получим сообщение об ошибке вида «Тип int не удовлетворяет концепту InputIterator». При этом в отличие от предыдущего примера тело функции find не будет компилироваться вообще, т.е. ошибка компиляции обнаружится на более раннем этапе.

Заметим, что условие удовлетворения типов концепту может записываться как в секции requires, так и в угловых скобках; в последнем случае ключевое слово typename заменяется на имя концепта, которому должен удовлетворять тип. Задание имени концепта в угловых скобках – более простой способ, он позволяет наложить на тип ограничения одного концепта. Для типов, удовлетворяющих нескольким концептам, а также для концептов, затрагивающих несколько типов, следует использовать вариант с requires, разделяя различные требования символом &&. Так, последний пример можно записать следующим образом:

template<typename Iter, typename V>
requires InputIterator && EqualityComparable
Iter find(Iter first, Iter last, V v) { ... }

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

template<typename V>
requires EqualityComparable
Iter find(Iter first, Iter last, V v) {
while (first < last && *first != v)
++first;
return first;
}

Такое описание find не позволяет использовать его для списков: в итераторе списка отсутствует операция <. Без использования концептов ошибка будет обнаружена только при попытке компиляции тела настроенного шаблона find<list<int>::iterator,int>, т.е. на позднем этапе. При использовании концептов ошибка компиляции будет получена при первой компиляции тела шаблона и проверке входящих в него типов на соответствие концептам InputIterator и EqualityComparable, т.е. на существенно более раннем этапе.

Приведем определение концепта EqualityComparable:

template<typename T>
concept EqualityComparable {
bool operator==(T, T);
bool operator!=(T, T);
};

Оно напоминает определение интерфейса в таких языках программирования как Java и C#. Однако, в Java и C# уже при определении типа T надо описать все возможные интерфейсы, которым он удовлетворяет. Концепты позволяют, не затрагивая определение типа T, наложить на него ограничения позже. Такой способ является значительно более гибким, поскольку невозможно заранее предугадать все требования, накладываемые на тип T при его определении.

Функции, определенные внутри концепта, называются ассоциированными функциями. Так, в предыдущем объявлении bool operator==(T, T) является ассоциированной функцией. Кроме этого, внутри концепта могут определяться так называемые ассоциированные типы. Ассоциированные типы, как правило, используются для представления типов параметров и типов возвращаемых значений ассоциированных функций. Например, операция operator*, определенная в концепте InputIterator, возвращает некий тип value_type, который следует определить в концепте InputIterator следующим образом:

concept InputIterator<typename Iter> {
typename value_type;
value_type operator*(Iter);
...
};

Все типы, удовлетворяющие концепту InputIterator, должны определять тип InputIterator::value_type, а ссылка на этот тип может фигурировать, например, при наложении ограничений в секции requires, как в примере с алгоритмом find:

requires EqualityComparable

Обычно концепты определяются со служебным словом auto (такие концепты называются автоматическими):

auto template<typename T>
concept EqualityComparable {
bool operator==(T, T);
bool operator!=(T, T);
};

В этом случае любой тип, имеющий операции == и !=, удовлетворяет концепту. В частности, таковыми являются все стандартные числовые типы, тип string и пр. Если концепт определен без служебного слова auto или если в типе отсутствуют функции или операции с такими именами, то для того, чтобы тип удовлетворял концепту, необходимо объявить для него так называемое отображение концепта (concept_map). Отображение концепта для данного типа должно удовлетворять каждой ассоциированной функции и реализовывать каждый ассоциированный тип из концепта. Например, чтобы тип

struct Person {
string name;
int age;
};

удовлетворял концепту EqualityComparable в смысле равенства только полей name, необходимо объявить следующее отображение концепта:

concept_map EqualityComparable {
bool operator==(const Person& p1, const Person& p2)
{ return p1.name == p2.name; }
bool operator!=(const Person& p1, const Person& p2);
{ return !(p1 == p2); }
};

Чтобы не повторять очевидную реализацию operator!=, в концепте EqualityComparable следует задать для operator!= реализацию по умолчанию:

auto template<typename T>
concept EqualityComparable {
bool operator==(T, T);
bool operator!=(T t1, T t2) { return !(t1 == t2); }
};

В этом случае если объявление операции != в типе или его отображении концепта отсутствует, то берется реализация по умолчанию.

Отображение концепта само может быть шаблонным. Например, чтобы тип vector<T> удовлетворял концепту

concept Stack<typename X> {
typename value_type;
void push(X&, value_type);
void pop(X&);
};

следует определить шаблон отображения концепта

template<typename T>
concept_map Stack > {
typedef T value_type;
void push(std::vector& v, const T& x) { v.push_back(x); }
void pop(std::vector& v) { v.pop_back(); }
};

Обратим внимание, что отображение ассоциированного типа выполняется с помощью директивы typedef.

Концепты могут наследоваться (уточняться). Например:

concept ForwardIterator<typename Iter> { ... };
concept RandomAccessIterator<typename Iter>: ForwardIterator
{ ... };

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

template
void advance(Iter& p, int n) { while (n--) ++p; }
template
void advance(Iter& p, int n) { p += n; }

при вызове

vector<int> v(10);
vector<int>::iterator vi = v.begin();
advance(vi,5);

предпочтение отдается более специализированной версии advance, в которой тип Iter удовлетворяет концепту RandomAccessIterator.

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

Комментированный перевод Стандарта Си++: текущее состояние

2009-07-09T13:11:00.003+02:00

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

Ну, а пока – просто для памяти: краткий список основных нововведений в стандарт Си++. Там есть много по мелочам, но эти вроде как наиболее значимые.

Пакеты параметров
Атрибуты сущностей
Новая семанттика спецификатора auto
Лямбда-выражения (closures, «замыкания»)
Концепты для задания ограничений на параметры шаблонов
Спецификатор constexpr
Спецификатор decltype
Спецификатор выравнивания alignas
Литералы, определяемые пользователем
Делегирование между конструкторами (наследование конструкторов)
Подставляемые пространства имен (inline namespaces)
Алиасы (псевдонимы) шаблонов

Может, что-то забыл впопыхах. Если вспомню, добавлю.

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

2008-11-18T22:38:00.004+01:00

Этот текст (см. ниже) на днях появится на сайте компании Интерстрон (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: финальная фаза

2008-11-01T01:50:00.007+01:00

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

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

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

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

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

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

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

2008-09-07T19:38:00.007+02:00

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

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

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

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

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

Ну действительно, 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++ - хорошо бы хранить в каком-то стандартном бинарном виде заголовочные файлы - а то они каждый раз перекомпилируются - пещерный век!

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

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

2008-09-05T19:04:00.016+02:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2008-09-05T18:39:00.007+02:00

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

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

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

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

2008-06-17T17:30:00.004+02:00

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

Я проверил свои знания русского языка и получил пятерку.

Сходи, проверься?

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

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

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

2008-05-17T23:24:00.006+02:00

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

Я уже несколько раз писал о своей старой идее выпуска комментированного стандарта 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++ («Краткий стандарт», или просто «Краткий курс» :-)), обоснование выбранных вариантов перевода технических терминов, синтаксические диаграммы и кое-что еще.

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

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

2008-04-28T12:37:00.005+02:00

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

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

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

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

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

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

2008-04-05T21:46:00.005+02:00

Недавно, 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 на "Эльбрусе" (вторая предыстория)

2008-03-10T20:13:00.002+01:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2008-03-08T21:03:00.024+01:00

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

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

                      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 не работает, придется искать обходные пути. Но она там точно лежит! :-)

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

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

"Древовидный" C++

2007-11-06T17:14:00.000+01:00

Сергей Прохоренко в комментарии написал:

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

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

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

Хочу подчеркнуть, что структура программы (компилируемые модули, области видимости имен, объекты) и структура модели (подсистемы, элементы) вообще говоря не обязаны совпадать. При разработке сверху вниз следует начинать со структуры модели, на которую затем накладывать структуру программы.

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

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

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

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

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

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

(Между прочим, редактор Visual Studio включает элементы «древовидного» подхода – фрагменты текста программы, соответствующие отдельным синтаксическим конструкциям, можно избирательно сворачивать и разворачивать. К сожалению, набор языковых конструкций, управляемых редактором, ограничивается пространствами имен, классами, функциями и комментариями и не распространяется на «внутренности» функций. Скорее всего, нечто подобное и в Эклипсе есть; может, даже и получше, чем в VS?)

Недавняя статья Страуструпа

2007-11-06T15:25:00.000+01:00

Evolving a language in and for the real world: C++ 1991 - 2006
Ссылка: http://www.research.att.com/~bs/hopl-almost-final.pdf
Статья большая, почти 60 страниц.
Написана для очередной конференции по истории языков программирования.

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

В целом, статья, безусловно, стоит того, чтобы ее внимательно прочитать.

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

C++'s success in real-world use also led to influences that are less beneficial. The frequent use of ugly and irregular C++ style of syntax in modern languages is not something I'm proud of. It is, however, an excellent indicator of C++ influence - nobody would come up with such syntax from first principles.

Удивительно видеть такую трезвую и недвусмысленную оценку «большого стиля» C++ от самого создателя этого языка! И одновременно, с чувством глубокого удовлетворения наблюдать такой классный пинок тем, кто копирует «ugly and irregular style of syntax» из примитивно понятых «маркетинговых» соображений... Все ведь понимают, в чей огород этот камень.

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

XML как замена всему :-)

2007-11-05T12:26:00.000+01:00

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

- Авек плезир! - отозвался Фагот, - но почему же
с вами одним? Все примут горячее участие!
(«Мастер и Маргарита»)

А почему же только Лисп? См. второй эпиграф.
А почему только синтаксис? Почему не задавить заодно и семантику? :-)

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

Program ::= List
List ::= '(' { Element } ')'
Element ::= List | Atom

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

Насколько это упрощает/усложняет программирование и чтение Лисп-программ – давайте не будем касаться этого вопроса. Сейчас мне хочется просто отметить интересное сходство Лиспа и... XML.

В самом деле, XML ведь тоже (опять-таки, если не брать во внимание второстепенные технические детали), предельно прост:

XMLDocument ::= Element
Element ::= StartTag { Content } EndTag
Content ::= Element | NonstructuredText

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

У XML, в отличие от Лиспа, нет собственной семантики – это всего лишь язык разметки. Смысл XML-документу придают агенты, его воспринимающие – либо люди, либо программы, с ним работающие. Но отсутствие семантики парадоксальным образом оборачивается невиданным расширением сфер использования: с помощью XML можно описать практически все на свете; главное – договориться, как именно описывать и как понимать/интерпретировать такое XML-описание. Для первого служат DTD, Schema или различные неформальные соглашения, для второго – шаблоны XSLT плюс смежные технологии, а также стандартизованные программные интерфейсы – DOM, SAX и подобные.

Вообще-то писать на эту тему можно очень много, но сейчас я хочу только лишь указать на проект Superx++ (http://xplusplus.sourceforge.net/), интересный как раз попыткой предложить XML как замену синтаксиса всеми нами любимого языка C++.

Собственно, смысл проекта достаточно прост: предлагается нотация, полностью заменяющая синтаксис C++ эквивалентными XML-конструкциями. Правда, более внимательное чтение примеров не подтверждает полной замены: автор не решился «xml-изировать» язык целиком и синтаксис выражений оставил в исходном виде. Более того, в какой-то момент он, похоже, испугался собственного радикализма и предложил некий «промежуточный» вариант под названием shortx, в котором язык переведен в XML-нотацию только частично...

Вот, полюбуйтесь: объявление класса в XML-нотации. Исходное, «плюсовое» объявление легко восстановить.

<class name="XTree">
  <scope type="public">
    <func name="GetSize" type="int">
      <return>
        <eval member="Size" object="this">
      </return>
    </func>
    <var name="Size" type="int">200</var>
  </scope>
</class>

Отметим, что (само)уверенности автору не занимать: одна из его первых статей на эту тему называется так: x++: The World's First Full XML-Based Programming Language Released!

(Сначала язык назывался X++, но это имя оказалось занято более «авторитетными» компаниями, и автору пришлось сменить его на superx++.)

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

Для superx++ автор сделал интерпретатор, причем написал его на плюсах. А почему не попытаться применить для этой же цели XSLT? Это выглядело бы логично: ведь он как бы хочет по максимуму использовать преимущества XML-технологий? Понятно, что автор хотел сделать эффективный инструмент, так как надеялся найти практическое применение своему проекту (даже фирму специально для этого сделал), но мне кажется, исследователькая ценность проекта от такого выбора только бы возросла, при этом совершенно неважно, в какой мере это ему бы в итоге удалось. Даже отрицательный результат здесь был бы очень интересен; по крайней мере, мы бы лучше себе представляли границы применимости шаблонов XSLT. Я, например, давно хочу эти границы применимости почувствовать...

UPDATE: совершенно случайно вдруг увидел старую статью В.Турчина:

Рефал как язык для обработки xml-документов
Валентин Турчин

Опубликовано в журнале "Компьютерра" №25 от 02 июля 2001 года
Ссылка: http://www.computerra.ru/2001/402/10900/

Там, помимо вопросов обработки XML-документов средствами Рефала, обсуждается и вариант XML-нотации для этого языка...

Простота и сложность: завершение

2007-10-31T12:32:00.000+01:00

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

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

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

> Си: линейная последовательность функций. Си-функция не может хранить собственный контекст между своими вызовами (это «stateless»-компонент), поэтому для обеспечения сколько-нибудь нетривиального взаимодействия приходится активно использовать глобальные переменные.

То есть как так? А как же static-переменные внутри функций? Они же инициализируются один раз при первом вызове функции, а затем сохраняют своё значение между вызовами функций:

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

Кроме того, и к самой теме поста – «какая модульность мне нужна» - этот пассаж не имеет особого отношения. Функции в Си если и могут быть названы модулями, то разве только совсем уж «кончеными» фанатами Си. :-)

Править основной текст после появления справедливых комментариев – не слишком корректно, потому ограничусь этим ответом.

Комментарии AVP и мои комментарии на комментарии :-)

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

С тем, что модульность иногда важнее ООП, согласен. Но не понимаю, чем Вам раздельная компиляция "не угодила"? :)

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

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

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

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

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

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

Конечно, линейный. Отношения импорта/экспорта сами по себе не дают нового качества. Функции в Си характеризуются такими же по сути отношениями импорта/экспорта: каждая функция экспортирует свое имя и импортирует имена всех доступных функций и глобалов. Оберон-модули как таковые не образуют расширяемую иерархическую структуру: такую структуру образуют расширяемые типы внутри модулей. Структура Оберон-программы, скорее, маскирует, скрывает расширяемую иерархию типов. Иными словами, сейчас Оберон-модули – это однородный набор контейнеров, по которым распределено дерево типов.

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

Так, да не совсем: расширяемые записи (аналог классов в более распространенных языках) не являются средством структурирования программы в целом.

Слишком категорично сказано, вызывает сомнение.

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

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

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

А мне думается, что обероновское решение, дублированное в Аде, вводит принципиально другую (новую, если сравнивать с Си/Си++) архитектуру ПО: "тэгированную" (типизированную) память.

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

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

А что значит программировать объектно? Возьмем в качестве примера (абстрактную) современную графическую ОС, основанную на обмене сообщениями. Ее объектная ориентированность вроде бы не подлежит сомнению. И на каком языке ее лучше программировать: на Си++ с его first-class классами :) или Обероне с его расширяемыми записями и проверкой динамического типа всего за одно сравнение? Можно даже сказать, что обероновская программная шина представляет собой простейшую реализацию схемы двойной диспетчеризации.

Честно говоря, я бы уклонился от общей дискуссии об ООП; наверное, я не чувствую себя для этого достаточно подготовленным (это все-таки не совсем компиляторная тема :-)). Пишу «объектно» вполне уверенно, а вот рассуждать и дискутировать... Извините.

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

Надеюсь, из сказанного примерно понятно, чего мне недостает в Обероне.

Если я правильно понял, в Обероне Вам в основном недостает (1) более разнообразной (специалированной) модульности и (2) классов.

Примерно так. Только я не стал бы разделять эти два пункта. Мне представляется, что «класс» в том виде, как он есть в том же Си++, должен иметь статус полноправного (специализированного) модуля, наряду с другими.

Честно говоря, с первым согласиться легче. :)
Второе, по видимости, движение в том же направлении (по Мейеру, класс = тип + модуль), но вызывает большее сомнение: как уживутся "две женщины на одной кухне" (класс и модуль :) ).

Что значит «уживутся»? Они друг другу никак не мешают, скорее необорот, помогают и дополняют, и вместо Вашего образа двух женщин на одной кухне я бы предложил, скажем, двух рабочих, несущих что-то тяжелое. Любой из них в одиночку груз даже не поднимет, а вместе они его не просто подняли, но даже и перенесли и поставили куда надо...

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

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

Не могли бы Вы подкинуть немного "инсайдерской" информации и ответить на давно мучающий меня вопрос? :)

Почему в Обероне нет шаблонов - понятно. Но почему в нем не прижились даже "облегченные" дженерики, предлагавщиеся в середине 90-х Шиперским?

Я задавал когда-то подобный вопрос Гуткнехту, но, к сожалению, не понял ответа (вероятно, помешал языковой барьер).

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

Я несколько раз говорил с Виртом насчет generic programming (пытался рассказать ему, о чем, собственно, читаю лекции в ETH :-)), но особого интереса не почувствовал. Он когда-то общался с Александром Степановым, и мне показалось, что и тот не смог объяснить ему, чем важны и хороши дженерики... Кроме того, у Вирта, если я правильно ощутил, есть какое-то неприятие Степанова лично. Впрочем, не уверен, могу ошибаться. Возможно, он просто не считает GP столь уж важным подходом и потому относится не слишком серьезно и к его создателю.

Простота и сложность (2)

2007-10-20T01:15:00.000+02:00

Позавчера пришел такой комментарий:

> Для их создания приходится использовать адекватные инструменты, которые не могут не соответствовать сложности и ответственности задач и потому объективно не могут быть простыми. (это был мой текст)

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

Кстати, с большим интересом прочитал бы ваше мнения о Java и C# как о языках (в некотором отрыве от виртуальной машины и фреймворка).

Во-первых, я не хотел бы «сваливаться» в неформальное сравнение языков (обещание себе дал :-). Если уж сравнивать, то глубоко, предельно конкретно (по существу), тщательно и непредвзято. Для этого нужен традиционный формат журнальной статьи, причем в журнал уровня Software: Practice & Experience или по крайней мере C++ User’s Journal, но уж конечно, не заметка в блог. (Кстати, что-то не припомню подобного сравнительного анализа!- по большей части, встречал только что-то вроде «Critique of C++» или известные едкие пассажи про «Жабу»...)

Тем не менее, кое-что сказать можно. Конечно, Java проще и стройней (и чисто по-человечески – мне, по крайней мере - писать на ней, как и на C#, не в пример удобнее и приятнее, чем на плюсах). Что же касается решения сложных задач, то их ведь решают на всех языках – и на чистом Си, и на Обероне, в том числе. Я лично знаю человека, который один написал больше полумиллиона строк на ассемблере БЭСМ-6 - и его программа была вполне рабочей, даже популярной - несколько десятков инсталляций по бывшему Советскому Союзу.

Вопрос, в конечном счете, заключается в том, какова цена решения, основанного на том или ином языке: какова вероятность завершения работы в заданный срок, насколько такое решение надежно, масштабируемо, развиваемо, сопровождаемо – прежде всего, в долговременном плане. Если брать в рассмотрение эти критерии, то мне все-таки кажется, что «простые» языки... ну, скажем мягко, не выглядят полностью адекватными им (этим критериям).

Насчет вторичности языка. Язык, конечно, вторичен, однако встык к Вашей цитате из Страуструпа я бы поставил цитату из Дейкстры (под рукой нет первоисточника, передаю смысл): «язык – это инструмент, но это такой инструмент, который оказывает глубокое (и тонкое!) влияние на мышление того, кто им пользуется». Рискну проиллюстрировать тезис классика вполне тривиальным примером.

Пусть вам нужно запрограммировать группу логически связанных действий, которые работают над некими общими для них данными. В простом Си у вас нет другого способа реализовать эти действия, кроме как определить данные в виде глобальных переменных (или структуры, неважно), а действия представить в виде простого набора функций. Если нужно как-то обособить этот код от других частей программы (уж не говорю – оформить его как независимый модуль!), то имеется, по существу, единственное решение -вырезать этот код (ножницами :-)) из программы, положить его в отдельный файл, а для «склейки» программы использовать текстовые инклюды. Написаны десятки статей, объясняющих недостатки и опасности такого решения, не буду повторять их,- но ведь в Си ничего другого нет! Ну, в крайнем случае можно попытаться откомпилировать этот фрагмент отдельно от основной программы, а потом прилинковать его; однако не всегда это возможно, а очень многие проблемы при этом остаются.

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

Давайте пойдем чуть дальше; заодно я отвечу на один недавний комментарий. Вот он:

AVC>Интересно, почему модульности очевидно недостаточно для борьбы со сложностью?

ЕЗ>Э-э-э... А что, достаточно? То есть, в языке достаточно иметь модули, и они одни способны решить все проблемы создания больших программ? Я что-то не понял реплики, простите.

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

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

Так вот, давайте тупо (с некоторым огрублением) сравним типичную структуру Си-программы и структуру Оберон-программы.

Си: линейная последовательность функций. Си-функция не может хранить собственный контекст между своими вызовами (это «stateless»-компонент), поэтому для обеспечения сколько-нибудь нетривиального взаимодействия приходится активно использовать глобальные переменные.

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

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

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

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

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

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

Такой подход кажется концептуально очень "чистым" и грамотным; он правилен и в практическом ключе: обеспечивается совместимость со старыми версиями языков. Однако, это решение оказалось очень ограниченным: "объектность" в обоих языках осталась "гражданином второго сорта", будучи всегда заключенной в рамки "более равных" программных единиц. Поэтому, между прочим, на обоих языках программировать объектно оказалось, попросту говоря, крайне неудобно. Как только потребности решаемой задачи выходят за рамки красивых и понятных примеров из руководств, начинается сущее мучение. В Аде, якобы, хотят как-то улучшить "юзабилити", предлагая нотацию вида "object.method", но для этого надо ждать нового стандарта...

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

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

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

Обобщая: различные виды модулей и развитые средства задания отношений между модулями. Скажем, в Аде можно делать вложенные модули (самый простой вид отношений), в последней Аде появились дочерние модули. В ней же есть задачи – модульные средства задания параллельного выполнения – и соответствующие средства синхронизации. В дополнение к задачам имеются "защищенные" модули (программируемый аналог монитора Хоара). В ООП-языках вводятся отношения наследования (пусть далеко не везде классы являются одновременно модулями, но сейчас важна идея). Вообще же классы должны быть first-class (полноправными) entities. Так, в Зонноне есть традиционные модули, интерфейсы, их реализации («обычные» классы), и еще есть средства задания протоколов взаимодействия модулей (в том числе, и асинхронных взаимодействий). В Аде модулем может выступать как «пакет» или «задача», так и одиночная подпрограмма. В ней же есть separate-подпрограммы (пусть с довольно слабой семантикой и с ограничениями).

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

Annotated C# Standard

2007-10-19T20:45:00.001+02:00

Вот, сегодня пришло извещение от Amazon:

C# Annotated Standard (Morgan Kaufmann) Jon Jagger
EUR 47,03

Судя по заголовку, практически то же, что я задумал со стандартом C++. Жалко, что не выложили какую-нибудь главу (только предисловие и индекс); интересно было бы взглянуть, как они текст/комментарии организовали. Придется, наверное, саму книгу заказывать, чтобы было с чего пример брать. :-)

Вот, кстати, синопсис. Английскими словами - практически то же обоснование, что и я выдвигал по поводу Аннотированного Стандарта C++:

Synopsis
Standards, while being definitive, do not usually serve as the best reference to the use of a programming language. Books on languages usually are able to explain usage better, but lack the definitive precision of a standard. This book combines the two; it is the standard with added explanatory material. Written by members of the standards committee, it annotates the standard with practical implementation advice. It is the definitive reference to the C# International Standard.