Перекрыть Енисей или перекрыть функцию (2)

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

Уважаемый Евгений!

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


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


Ваше возражение против слова "инструкция" сводится к тому, что оно плохое потому, что используется при описании ассемблера (Instruction Set). На самом деле во многих переводах книг по ассемблеру Вы встретите "оператор ассемблера"! В них (некоторых из них) нет слова "инструкция". Но главное другое. Допустим слово "инструкция" используется при переводе книг по ассемблеру. Ну и что? Чем оно от этого становится хуже? Неоднозначность? Но книга про С++, а не про ассемблер. И разве нам привыкать к перегруженным терминам (возьмите, например, слово "поток")? Ваш вариант с "предложением" тоже вполне приемлем. <...>


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

> Запись a = b; не может быть "инструкцией присваивания", даже если иметь в виду, что
> под "инструкцией" понимается statement. По Стандарту эта конструкция называется
> expression-statement

Я не помню, где в оригинале написано "expression-statement". И в каком контексте.

<...>

> почему "перегрузка операторов", но "переопределение функций"?
> В оригинальных английских текстах используется одно и то же слово overloading:

Не могли бы Вы привести пример?

> решительно все термины, ... уже имеют выбранные профессионалами,
> вполне определенные, обоснованные и исторически прижившиеся русские эквиваленты.

Это не так. Если бы они были вполне обоснованы и полностью прижившимися, не было бы этой переписки и разноголосицы в переводах. Я понимаю, что Вам неприятно встречать в книге термины, которые Вы считаете неправильными. Мне тоже очень неприятно видеть в книгах термины, с которыми я не согласен. Как правило я сначала страшно ругаюсь на переводчиков и редакторов книг. Потом я пытаюсь понять - чем их термин хуже моего. И хуже ли? Может быть они имели ввиду значение слова, которое сразу не очевидно. И т.д.
<...>

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

С уважением, <...>


Уважаемый <...>

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


Да почему они должны были быть "во многом не согласны"? Откуда это следует? Как раз наоборот, все развивались, в общем, в одном русле. Те российские школы, которые я упомянул, вовсе не были антагонистами. И, скажем, Андрей Петрович Ершов (слышали про такого?), автор оптимизирующего компилятора Algol-60 и член IFIP,- если и был в чем-то не согласен с зарубежными авторитетами, но, конечно же, не потому, что работал в Новосибирске, а не в Беркли.

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

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

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

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


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

>Не было и нет единой общепризнанной традиции. Возьмите первое издание
>Страуструпа и перевод книги Эллис, Страуструп. Там используются разные термины.


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

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

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

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

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


Позвольте привести еще один пример. Первые книги по системе UNIX появились у нас довольно скоро после того, как эта система получила известность. В переводах этих книг для термина handle (file handle) был предложен вариант "дескриптор", "дескриптор файла". Не Бог весть какое красивое название, но точно отражает суть дела: это описатель файла. Так или иначе, это название активно использовалось (и при описании других ОС и машинных архитектур).


В системе MS-DOS, которая появилась спустя десяток лет, этот же термин handle использовался для обозначения семантически того же самого понятия. Но книги по MS-DOS переводили совсем другие люди! У них не было background'а, они просто не читали тех, уже классических книг, а знали только английские help'ы. Они попросту были плохо образованы. Хорошо понимая, что такое handle, они решительно не знали, как перевести это слово. И не долго думая, написали... хендл.


Неужели это правильно????? Неужели мы с Вами должны следовать за этими "переводчиками", лишенными чувства языка?


Конечно, есть термины, которых лет десять назад не существовало, например, те же function overloading (хотя сам механизм в ЯП, конечно, был известен). Но тут уж для выбора адекватного перевода требуется чувство языка (русского/английского) и, конечно же, четкое понимание сути термина. Ваша метафора с тенями на плоскости иллюстрирует только многозначность русского языка. Еще раз: "перекрытие" чего-то чем-то подразумевает, что перекрывающий объект делает невидимым, недоступным, неактуальным перекрываемый объект. Для overloading functions, равно как и для overloading operators это принципиально не так. Все одноименные функции и все функции-операции одновременно актуальны; никакая из них не "перекрывает" никакую другую. Они все, вот именно, совместно используются.


>Насколько я понял, Вы предлагаете переводить statement как "оператор", а
>operator как "операция". Такой вариант можно было бы рассматривать...


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

<...>

>В английском есть слова operator и
>operation. И если бы они хотели сказать "операция", они бы сказали.


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


>> Запись a = b; не может быть "инструкцией присваивания", даже если иметь
>> в виду, что под
>> "инструкцией" понимается statement. По Стандарту эта конструкция
>>называется expression-statement
>Я не помню, где в оригинале написано "expression-statement". И в каком
>контексте.


Expression-statement - это термин Стандарта Си++ (оператор-выражение); в данном случае он отражает тот факт, что a=b - не оператор в традиционном понимании (как, например, в Pascal'е), а бинарная операция, которая вырабатывает значение и, как и многие другие операции, может совместно использоваться.


>> почему "перегрузка операторов", но "переопределение функций"?
>> В оригинальных английских текстах используется одно и то же слово overloading:
>Не могли бы Вы привести пример?


Да пожалуйста: вся глава 13 Стандарта посвящена именно этому. Там для языкового механизма как такового используется термин overloading. Для обычных функций и функций-членов классов - термин function overloading; сами такие функции называются overloaded functions, а функции-операции - overloaded operators.


С уважением,
- Евгений Зуев.

Перекрыть Енисей или перекрыть функцию

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

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

Обсуждая со студентами вопросы программирования на Си++, часто приходится сталкиваться с достаточно вольным обращением с терминологией. В основном, эти вольности проистекают от прямой транслитерации англоязычных терминов из западных описаний и руководств и недостаточного знакомства с квалифицированными переводами. Со временем я научился терпимо относиться к подобной "терминологии", помня, что устная речь, в том числе и профессиональная, может несколько отличаться от письменной в сторону большей свободы. Я даже научился не морщиться от "перекрытых функций"; иной раз, правда, не выдерживаю: "Функция - не Енисей, ее не перекрывают". Но, честно говоря, я никак не ожидал подобного от переводчиков Бьярна Строуструпа!

Недавно вышло в свет долгожданное третье издание Б. Строуструпа "Язык программирования C++" (издательство "БИНОМ"). Впечатление от оригинальной версии книги создалось весьма положительное, так что появление перевода следует всячески приветствовать.

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

Слово "statement" принято переводить на русский язык как "оператор". Мы привыкли к тому, что if, while, case и т. д. - это операторы. Увы, в контексте С++ такой перевод неприемлем. Дело в том, что в С++ слово "operator" (которое и переведено как "оператор") имеет совсем другое значение. Оно применяется для обозначения сложения (оператор +), разыменования (оператор *), выяснения размера (оператор sizeof ()) и в других подобных случаях…

…Что же касается термина "statement", то из предлагаемых различными словарями вариантов "утверждение", "предложение" и "инструкция" мы избрали последний, так как он, по-видимому, лучше всего соответствует сущности обозначаемых словом "statement" конструкций С++ и, кроме того, периодически встречается в книгах и документации в нужном значении…

Си++ - типичный операторный язык; в этом смысле он ничем не отличается от своих предшественников и других алгоритмических языков программирования - Алгол-60, Паскаль, Си, Ада. Тот факт, что в Си++ присваивание считается бинарной операцией, вырабатывающей значение, не меняет существа дела - в Си ситуация точно такая же. Уже по одной этой причине нет решительно никаких оснований вводить для традиционных операторов - условного, цикла и т.д.- новое название. И уж совсем диким выглядит конкретный вариант перевода для английского statement - инструкция! Конечно, любой англо-русский словарь добросовестно перечислит весь спектр возможных значений для того или иного английского слова; наверное, в каком-нибудь из них и можно найти и такой вариант. Но это же не основание для того, чтобы выбрать для фундаментальной книги по программированию на Си++ слово, традиционно используемое - даже не для языка ассемблера, а в описании системы команд какого-нибудь процессора! Instruction set - устойчивое сочетание в книгах о процессорных архитектурах.

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

На самом деле авторы перевода тут же простодушно поясняют свой выбор. Дело в том, что так они надеялись решить проблему с другим понятием языка, выражаемым словом operator. Действительно, как же иначе перевести это слово, как не побуквенно! Вот и получается, что слово "оператор" уже занято… И statement становится - инструкцией.

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

В результате получаем следующий пассаж авторов перевода:

В частности, = - это оператор присваивания, семантику которого можно изменить путем перегрузки, а вот запись a = b; является инструкцией присваивания, семантика которой неизменна, фиксирована языком и состоит в вызове (возможно перегруженного) оператора присваивания с аргументами a и b.

Запись a = b; не может быть "инструкцией присваивания", даже если иметь в виду, что под "инструкцией" понимается statement. По Стандарту эта конструкция называется expression-statement (оператор-выражение, согласно переводу предварительной версии стандарта, см. конец заметки). Иными словами, присваивание (операция присваивания!) - это частный случай выражения, а выражение в позиции, не вырабатывающей значения, считается именно оператором-выражением. Семантика же этой конструкции вовсе не обязательно заключается в вызове какой-либо функции; возможно (для базовых типов) и непосредственное копирование значения. Кстати, как можно вызвать "оператор присваивания"? Вроде бы, вызвать можно только функцию… На самом деле авторы перевода имели в виду функцию-операцию (в Стандарте - operator function).

Далее авторы перевода пишут:

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

Сходство функций и операций - давно осознанный и освоенный наукой программирования факт. Скажем, в языке Clu, появление которого в свое время было воспринято как заметное событие, традиционные операции в инфиксной форме рассматривались как излишество, "синтаксический сахар", уступка привычкам, а первичной конструкцией считался как раз вызов функции. Так что приведенная выше цитата не имеет прямого отношения к выбранной терминологии. Отметим только некоторую словесную кашу: если "операторы в Си++ сродни функциям", то почему "перегрузка операторов", но "переопределение функций"? В оригинальных английских текстах используется одно и то же слово overloading…

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

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

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

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

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

Кстати, в этой же книге для терминов declaration и definition используются, соответственно, переводы "объявление" и "описание". Неужели и здесь было совершенно необходимо непременно сказать свое слово, переведя definition как "определение"?

Стандарт языка C++ с комментариями (предложение по публикации)

Уже довольно давно я вынашиваю идею выпуска комментированного перевода Стандарта C++. Писал и говорил об этом я настолько часто (начиная с "Редкой профессии"), что уже и неловко отвечать на вопросы, которые до сих пор иногда возникают: "Где перевод?", "Когда будет перевод?" и т.п.

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

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

Язык программирования C++ [1] является в настоящее время наиболее распространенным и популярным инструментальным средством для профессиональной разработки больших и сложных программных систем. Несмотря на активное продвижение альтернативных языковых средств и платформ (прежде всего, Java и C#) и на полное отсутствие пропаганды C++, этот язык остается уверенным лидером в области средств разработки. Анализ [2] показывает, что этот язык используется при создании как широко распространенных программ, ориентированных на максимально широкий круг пользователей, так и систем весьма специального назначения, зачастую с повышенными требованиями к надежности и производительности.

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

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

По моему мнению, лучшим вариантом книги по языку C++ является текст Международного Стандарта C++, который строго и недвусмысленно представляет весь язык. Чтение текста Стандарта - лучший путь изучения языка (это относится не только к C++, но в случае с этим языком это особенно ясно). В то же время, оригинальный текст стандарта на английском языке - не самое легкое чтение, потому необходим адекватный и качественный перевод. В то же время, имеет очень большой смысл предоставить читателю и оригинальный текст. Кстати, в свое время именно в такой форме (как двуязычный текст) был опубликован стандарт языка Алгол-68.

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

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

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

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

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

Вот еще несколько весьма существенных моментов, связанных с моим предложением. Стандарт C++ - собственность международного комитета ISO. Его официальный перевод, стало быть, должен быть соответствующим образом легализован с точки зрения существующих юридических правил. Каков в точности механизм этой легализации, мне не известно. Возможно, имеет смысл сделать так, чтобы выпуск предлагаемой книги был не просто частной инициативой одной компании или издательства, а был как-то согласован с Госстандартом России. Я знаю, что в Госстандарте интересуются процессом стандартизации C++ и с интересом воспримут сам факт появления такого перевода. Я предполагаю, что у них есть интерес к выпуску российского стандарта C++ (на основе Стандарта ISO). Поэтому какое-то (хотя бы вполне нейтральное) согласование и/или одобрение Госстандарта получить, мне кажется, будет вполне реально.

В заключение хотел бы заметить, что этот проект, в том виде, как он описан выше, является в своем роде уникальным не только в России, но и в мире. Попросту говоря, изданий, аналогичных предлагаемому, я не знаю. В начале 90-х годов автор языка C++ Б. Страуструп выпустил подобную книгу, трактующую предварительную версию языка C++, которая предлагалась в качестве исходной для начинавшегося процесса стандартизации языка. Эта книга в русском переводе [3] мгновенно стала библиографической редкостью и, по моему мнению, по настоящее время остается одним из лучших описаний C++ (даже несмотря на то, что она представляет сильно устаревшую версию языка). Недавно Б. Страуструп в одном из интервью высказал идею написания подобной книги по итоговой («стандартной») версии, однако он специально отметил, что ни сроков начала такой работы, ни ее возможную длительность обсуждать не готов.

Несколько технических подробностей.
Полный объем Стандарта – 748 печатных страниц формата A4. Объем описания первой части Стандарта (ядра языка, то есть без учета описания стандартных библиотек) – 310 печатных страниц. Представляется целесообразным ограничиться (по крайней мере, вначале) выпуском комментированного перевода именно ядра языка. Мной к настоящему времени уже выполнен перевод примерно 95 процентов текста, а также подготовлена значительная часть справочного аппарата, о котором шла речь выше. Таким образом, основное время будет посвящено написанию комментариев. К этой работе хотелось бы привлечь ряд авторитетных отечественных специалистов по языку C++, а также использовать наиболее интересные и глубокие работы зарубежных авторов.

Ссылки:

1. ISO/IEC International Standard – C++ ISO/IEC 14882, 1998(E)
2. Руслан Богатырев. Летопись языков: Си++. Мир ПК, #01/2003
3. М.Эллис, Б.Строуструп. Справочное руководство по языку программирования Си++ с комментариями. Москва, «Мир», 1992.