Перекрыть Енисей или перекрыть функцию (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.
С уважением,
- Евгений Зуев.