Русскоязычная терминология

[Dale]

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

Вот и я при переводе одной статьи попал в аналогичную ловушку. Пока затруднения вызвали следующие термины:

• firmware
• mock
• constructor injection

Это только самое начало, наверняка будут и другие.

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

[Sla]

firmware - внутреннее ПО

mock - надо смотреть в контенте.

может там что-то наподобие mock up, а может подразумевается как хитрый хак, который "моском" понять невозможно

[Алексей++]

какой из перечисленных вариантов кажется предпочтительнее

а где варианты то ? И про что статья (а ещё лучше саму статью)

[Sel]

Я не программист, мне судить сложно, но словарь http://multitran.ru дает несколько вариантов переводов каждого из этих слов.
Например,  http://multitran.ru/c/m.exe?l1=2&l2=1&s=firmware

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

[Dale]

а где варианты то ?

Вот эти:

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

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

И про что статья (а ещё лучше саму статью)

Статья про цивильные методы программирования микроконтроллеров. Оригинал здесь: http://www2.enel.ucalgary.ca/People/Smith/2008webs/encm515_08/08ReferenceMaterial/evolving_into_embedded_development_paper.pdf

[RXL]

"firmware", если применять его контекстно, то я бы назвал "прошивкой". Если отдельно стоящее слово и не ясен контекст, то да - "внутреннее ПО" - короче и емче не знаю.

[Алексей++]

mock
http://ru.wikipedia.org/wiki/Mock-%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82

[Dale]

mock - надо смотреть в контенте.

может там что-то наподобие mock up, а может подразумевается как хитрый хак, который "моском" понять невозможно

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

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

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

Наверное, придется заменить mock на "объект-заглушка"... Режет глаз, но "мок", по-моему, еще хуже.

[Алексей++]

In an object-oriented language, we’d normally insert mocks into
our objects under test using constructor injection. Since we
were using C, we couldn’t use constructor injection, so instead
we simply manipulated which object files were linked
into our test files.

наверное, constructor injection , можно перевести как ~"передача конекста через конструктор"

[Алексей++]

"заглушка" не режет глаз, вполне привычное словцо ) Ещё можно "затычка"

[Sel]

Смысл понятен, но как сказать по-русски красиво, надо подумать. "Мок", на мой взгляд, вообще ужасно. Или если ты решишь оставлят англ. вариант. Что портит перевод, сам понимаешь...
А "тестовый вариант" какой-нибудь не подойдет?..

P.S. и уж конечно, никаких "затычек".

[Dale]

mock
http://ru.wikipedia.org/wiki/Mock-%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82

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

[Sel]

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

[Dale]

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

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

"Мок", на мой взгляд, вообще ужасно.

100%. Стиль юного какера.

Или если ты решишь оставлят англ. вариант. Что портит перевод, сам понимаешь...

Это и переводом будет трудно назвать... Русские слова останутся только в виде связок: "использование mock при unit-тестировании в процессе разработки firmware"... Проще оставить в первозданном виде, легче читается.

А "тестовый вариант" какой-нибудь не подойдет?..

Думаю, неконкретно будет. Mock - это довольно устоявшийся термин, все, кто в теме, точно понимают, о чем речь. А  вот над "тестовым вариантом" я бы крепко задумался, что именно имеют в виду.

[Dale]

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

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

Кстати, есть желающие потом почитать результат? Или firmware не ложится в тематику сайта?

[Sel]

Это и переводом будет трудно назвать... Русские слова останутся только в виде связок: "использование mock при unit-тестировании в процессе разработки firmware"... Проще оставить в первозданном виде, легче читается.

Нравится мне твой подход.

Думаю, неконкретно будет. Mock - это довольно устоявшийся термин, все, кто в теме, точно понимают, о чем речь. А  вот над "тестовым вариантом" я бы крепко задумался, что именно имеют в виду.

В таком случае, смотри на меня. Я - не программер. Твоя задача - объяснить мне все эти непонятные термины как можно более кратко. Какие слова ты подберешь? Это и будет переводом.

Кстати, есть желающие потом почитать результат? Или firmware не ложится в тематику сайта?

С удовольствием помогу, чем смогу...

[Dale]

"firmware", если применять его контекстно, то я бы назвал "прошивкой". Если отдельно стоящее слово и не ясен контекст, то да - "внутреннее ПО" - короче и емче не знаю.

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

[Dale]

С удовольствием помогу, чем смогу...

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

[Джон]

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

А вобще-то в таких случах я поступаю след. образом:

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

если не нашёл...

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

если не нашёл...

3. Пробую на грамота.ру различные написания слова транслитеративно.

если не нашёл...

4. Если не очень важно (типа читатель сам может в словаре посмотреть, либо же ДОЛЖЕН знать), оставляю оригинал. Если заранее знаю, что оригинал не поможет, то привожу его транслитеративную версию и делаю сноску с объяснением. Далее в тексте фигурирует уже транслитерация.

[Dale]

Вот еще наткнулся на термин - toolchain. Кому-нибудь попадался русский аналог?

[RXL]

В Википедии есть только это: http://ru.wikipedia.org/wiki/GNU_toolchain

Если кратко, то я бы сказал "набор средств компиляции".

[Dale]

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

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

[Алексей++]

конвеер

[RXL]

FAQ можно пополнить.

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

[Dale]

конвеер

Не годится, термин уже устаканился для процессорных структур

FAQ можно пополнить.

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

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

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

[Алексей++]

а неудобопроизносимый "фреймворк" можно заменить на "платформа"

[RXL]

Dale, я это и имел в виду. У меня в подписи ссылка и также в меню в шапке форума.
Там отдельная от форума регистрация и права на создание и редактирования даются отдельно админами (защита от спама).
Описания разметки есть тут: http://wiki.shelek.ru/index.php/%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0_%D1%80%D0%B0%D0%B7%D0%BC%D0%B5%D1%82%D0%BA%D0%B8_Wiki

[Dale]

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

[Джон]

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

Судя по толкованию на аглицкой вики, это типичная IDE

In software, a toolchain is the set of programming tools that are used to create a product (typically another computer program or system of programs). The tools may be used in a chain, so that the output of each tool becomes the input for the next, but the term is used widely to refer to any set of linked development tools.

A simple software development toolchain consists of a text editor for editing source code, a compiler and linker to transform the source code into an executable program, libraries to provide interfaces to the operating system, and a debugger. A complex product such as a video game needs tools for preparing sound effects, music, textures, 3-dimensional models, and animations, and further tools for combining these resources into the finished product.

[Sla]

ну тогда "пакет инструментов"

[Dale]

а неудобопроизносимый "фреймворк" можно заменить на "платформа"

Тоже плохо, IMHO. Термин "платформа" слишком заездили, причем совершенно неоднозначно. Intel и SPARC - платформы, Windows и Linux - платформы, .NET и Java - тоже платформы... Слово практически утратило смысл, его начали употреблять исключительно для эмуляции глубокомысленности. "Фреймворк" гораздо конкретнее, хоть и неблагозвучно. Но ведь привыкли к драйверам и трансляторам, не заменяем их "водителями" и "переводчиками". Глядишь, и "моки" с "тулчейнами" приживутся со временем.

[Dale]

Судя по толкованию на аглицкой вики, это типичная IDE

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

Тулчейн можно прикручивать к разным IDE. Например, у меня одни и те же тулчейны работают и в среде разработки, и в среде моделирования схем.

Точнее будет сказать, что toolchain != IDE, но IDE + toolchain = framework. Но опять же не по-русски, сплошной пиджин.

[Dale]

Я, пожалуй, сделаю так.

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

[Джон]

Точнее будет сказать, что toolchain != IDE, но IDE + toolchain = framework. Но опять же не по-русски, сплошной пиджин.

Ну в принципе согласен. IDE слишком объёмно. Под IDE я просто понимал не обязательно продвинутые современные среды а ля Студия, а именно одну toolchain из них: сохранение кода после редактирования (редактор), комиляция, линковка, запуск. Но по сути это есть toolchain.

Буду пока включать английский оригинал, а в нашей Вики представлю свое толкование термина.

ИМХО самое идеальное решение.

зы По ходу мысли, как вариант:

"пакетная обработка" / "пакетный обработчик" задач.

[Dale]

ИМХО самое идеальное решение.

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

[Джон]

Конечно получится. В этом вся соль. Я такое (термины со ссылками на вики) когда-то хотел в разделе "Фото" сделать, но до сих пор руки не дошли.

[Dale]

Перевод почти готов. Кто подскажет, каким образом его лучше выложить на обсуждение?

[Sla]

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

[Dimka]

Я не согласен, что framework - это синоним toolchain. Framework - это понятие, по смыслу более близкое к библиотеке (library), нежели к интегрированной среде разработки (IDE). Если библиотека предоставляет множество полезных наработок, могущих использоваться как "кубики конструктора", ускоряющих разработку программы, то framework помимо "кубиков" содержит ещё и методику работы с ними, и готовые расширяемые и адаптируемые под конкретные нужды типовые решения и схемы решений.

[Finch]

Dale, Я тебя добавил в группу "Авторы" Должен появится доступ https://forum.shelek.ru/index.php/board,118.0.html

[Dale]

Finch, спасибо. Попробую в ближайшее время, мне уже совсем немного осталось доделать.

[RXL]

В Вики сделал раздел для терминов: Перевод технических терминов на русский язык.
На той странице надо добавлять ссылки по следующему типу:

Код:

* [[Firmware]]
* [[Framework|Иное написание ссылки, если нужно]]

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

Код:

[[Category:Русские термины]]

Напоминаю, что в формате Вики одиночный перевод строки рассматривается как пробел, два - как новый абзац, а все более двух - как пустые строки (<br>).
Описание формата можно прочесть здесь: язык разметки Вики.

[Dale]

Спасибо, я нашел справку. Вроде описано подробно, лишних вопросов не должно возникнуть.

В Вики сделал раздел для терминов: Перевод технических терминов на русский язык

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

[RXL]

"Глоссарий" добавил как пункт данной статьи. В саму статью в начало можно написать еще некоторый вступительно-описательный текст.

[RXL]

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

[Dale]

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

[RXL]

Ну, это другое дело...

Например (также раскидал текст по частям и подправил последнее предложение):

Код:

__TOC__

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

==Варианты трактования==
===Программно-аппаратное обеспечение микроконтроллера===
Возможные значения перевода:  «программно-аппаратное обеспечение микроконтроллера», «микроконтроллер».

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

===Программное обеспечение микроконтроллера===
Возможные значения перевода: «программное обеспечение микроконтроллера», «прошивка», «микропрограмма».

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

==Внешние источники==
В Википедии запрос «[http://ru.wikipedia.org/wiki/Firmware Firmware]» автоматически перенаправляется на статью «[http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0 Микропрограмма]», однако с такой однозначной интерпретацией трудно согласиться.

[[Category:Русские термины]]

В Вики это не заносил.

[Dale]

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

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

[Dale]

В блоге генерального директора издательства "Диалектика-Вильямс" Виктора Штонды попались мнения читателей по обсуждаемой теме:

У меня есть только одно пожелание, наверняка субъективное и спорное, но все же озвучу: возможно, не стоит переводить общеизвестные аббревиатуры и сочетания слов, такие как Test-Driven Development, Domain Driven Design, Continuous Integration, Dependency Injection и многие другие. Когда читал перевод книги Нильсона - спотыкался об них первые полкниги. Возможно, это вопрос привычки, но, думаю, для многих программистов эти термины более знакомы в их англоязычном эквиваленте.

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

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

Вывод: лучший вариант оставить термины на английском, но для любителей в конце книги дать словарь переводов

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

Присоединяюсь к мнению, что термины переводить не нужно. Перевод очень (нет - ОЧЕНЬ!) мешает. Хотя бы в скобках оставляйте оригинальное название. Когда читал книгу Джимми Нильссона постоянно делал мысленное упражнение - замену русского термина на английский перед осмыслением предложения.
Перевод конечно же должен быть. Но практика такова, что в жизни все используют английские термины. И будут использовать всегда по одной простой причине - разработчики 70-95% технических текстов воспринимают на английском. Это блоги, статьи, форумы, справка средства разработки, книги, общение с коллегами и прочее. Кроме того, к моменту выхода книги даже на английском термины уже успевают устояться - они встречаются в блогах, статьях, реальных продуктах. Русский аналог становится бесполезным.
Поэтому, например, "DDD" так и останется "DDD".

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

Переводить термины в технической литературе НЕЛЬЗЯ! Последий мой негативный опыт в этой области -- попытка чтения "Шаблоны тестирования xUnit: рефакторинг кода тестов". Я не смог осилить и пятидесяти страниц (при том, что в оригинале прочитал всю книгу).

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

По-моему, заслуживает внимания.

[baldr]

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

[Dale]

Да, но согласно диалектике все равно сначала должна пройти стадия отрицания

[Dimka]

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

Почему им (англоязычным) можно изобретать термины (далеко не всегда удачные) на родном языке, а нам (русскоязычным) нельзя?

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

Бывают отдельные термины, перевод которых сложен. Хотя бы "to instantiate ... [something]". Русское "породить экземпляр ... [чего-нибудь]" хотя и наиболее близко по смыслу, но всё же не совсем удачно. А от "инстанцировать" лично меня коробит.

[Dale]

Увидел цитату

Переводить термины в технической литературе НЕЛЬЗЯ! Последий мой негативный опыт в этой области -- попытка чтения "Шаблоны тестирования xUnit: рефакторинг кода тестов". Я не смог осилить и пятидесяти страниц (при том, что в оригинале прочитал всю книгу).

и вспомнилось, как приобрел книгу Дубейковского "Практика функционального моделирования с All Fusion Process Modeler 4.1". Раскрыл и обнаружил, что почти ничего из прочитанного не могу понять. Вроде и сама тема для меня не новая, и программа знакомая, а вот не идет. Смысл предложения неуловимо ускользает, не могу ухватить.

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

Еще в тему: в многочисленных книгах по алголам-паскалям-сям и иже с ними орды переводчиков десятилетиями дружно переводили statement как "оператор". И все было чудесно, пока не появился Страуструп со своим C++, в котором, помимо statement, присутствовал еще и operator. Вышел конфуз: прежние "операторы" вдруг дружно перестали быть таковыми, сея в рядах программистов раздор и смуту. (В параллельной теме возможная замена "платы" на "контроллер" могла бы привести к подобному результату).

[Dimka]

"Оператор" (operator) - это часть "выражения" (expression), которое, в свою очередь, является частью законченного утверждения (буквальный перевод statement), подлежащего выполнению машиной как единое целое, однако словом "утверждение" у нас уже переводят слово assertion ("контрольное утверждение"), хотя, быть может, более правильным было бы перевести assertion как "отношение", поскольку так или иначе оно содержит сравнения (логические отношения между значениями переменных в математическом смысле) и является предикатом, который обязан быть истинным. Но и слово "отношение" уже занято в качестве перевода relation[ship], которое в данном случае даже подходит, но совершенно лишено намёка на предикат.

Остаются слова-синонимы:
- "действие" (action), но по смыслу оно означает единичный и самостоятельный акт, не часть последовательности, поэтому неудачно;
- "команда" (command), но этим словом обычно обозначают приказ выполнить действие, поэтому см. выше;
- "операция" (operation) - подходящее слово, означающее как отдельное действие, так и множество действий по плану для достижения общей цели;
- "инструкция" (instruction) - подходящее слово, означающее план или предписание о порядке выполнения операции.

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

[Dale]

...наиболее удачным переводом для statement мне кажется именно слово "инструкция".

Именно так и переведен на русский язык Страуструп. Но ведь остались тонны макулатуры, в которой statement =оператор, и десятки тысяч голов (считая мою), в которые это прочно вбито со студенческих пор.

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

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

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

[Dimka]

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

[Dale]

В таком случае забираю обратно свою похвалу переводчикам.

Кстати, интересно, как они будут выкручиваться, если темой статьи будет применение ассемблерных вставок в программах на C++. Забавно было бы посмотреть, как они разрулят коллизию instruction/statement/operator, постоянно сваливаясь в собственноручно вырытую яму.

[Dimka]

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

[Dale]

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

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

[RXL]

Или еще иногда попадается столь же нелепое сочетание "пакет Ethernet"...

А у тебя есть альтернатива термину "Ethernet"?

[Dale]

А у тебя есть альтернатива термину "Ethernet"?

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

[RXL]

Dale, в оригинальных доках идет речь о кадрах (frames). Но велика ли разница между кадрами и пакетами...
Или ты что-то другое имел в виду? Я не уверен, что правильно тебя понял.

[Dale]

Именно это. В эталонной 7-уровневой модели OSI на канальном уровне речь действительно идет о фреймах. Пакеты появляются лишь на следующем, сетевом уровне.

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

[RXL]

Для уточнения уровня и добавляют: "Ethernet", "IP", "TCP" и т.п.
Лично я запутался бы в русскоязычном тексте, если переводчик или автор опирался бы только на "кадры" и "пакеты" для разделения Etehrnet и IP, без пояснения протокола.

[Dale]

Видимо, дело привычки. Это сейчас Ethernet фактически вытеснил остальные проводные локальные сети. Еще не так давно на канальном уровне попадались и DL-KICI, и HDLC, и ARCnet, и TokenRing... У нас до сих пор используются звенья X.25. В смешанных сетях разница между фреймом и пакетом прослеживается особенно четко, да и "фрейм" вовсе не всегда "фрейм Ethernet".

TCP/IP тоже не сразу стал стандартом де-факто, долгое время с ним сосуществовали IPX/SPX и NetBEUI. Поэтому в общем случае говорилось просто "фрейм" либо "пакет", без уточнения конкретной реализации.

[Dimka]

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

Что от этого действительно отличается, так это:
- физический термин "волновой пакет" (waves packet) и т.п.;
- пакетный режим работы ОС - batch mode (очередь бездиалоговых программ на исполнение);
- "пакет прикладных программ" (application package)...

В последнем случае package в смысле Java корнями уходит именно в application package (как множество скомпилированных class-файлов, входящих в один модуль/пространство имён)

Кто ещё что скажет про packet/package/batch/bundle?

[Dale]

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

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

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

[RXL]

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

Зато ассоциативно и потому легко воспринимается людьми с разным уровнем знаний в предметной области.


Кстати, о привычках — о них не стоит забывать. Это небольшое отступление от текущего обсуждения, но полезно для темы в целом, чтобы за частностями не забывать большего. Зачастую специалисты привыкают к определенной терминологии, краткой трактовке чело-либо сложного и т.п. Недавно я имел беседу с одними спецами, занимающимися интересной для меня сейчас областью — кластеры, виртуализация, сети хранения данных. На мое сообщение, что VMware ESX базируется на некой ОС он парировал заученным термином, что эта система "работает на голом железе". Архитектурно это утверждение не лишено смысла: гипервизор управляет процессором и памятью, контролирует доступ к IO для виртуальных машин, одной из которых является управляющая ОС. Но есть нюанс: гипервизор без ОС, управляющей устройствами системы (драйвера никто не отменял) и самим гипервизором, — вещь сама в себе и нафиг не нужен. Т.ч. одно от другого не отделимо и термин "работает на голом железе" можно считать некорректным. (Я не стал это говорить тому спецу, т.к. он и так замучил нас 2.5 часа своими рассказами, содержащими больше воды и самых азов, чем полезных сведений. Если бы говорил по делу, то уложился бы в час.)

[Dale]

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

Протокол передачи файлов FTP

Завершая тему устройства и принципов работы Интернета, хочу коснуться еще одного сетевого протокола -- протокола передачи файлов FTP (File Transfer Protocol).

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

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

Еще перлы:

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

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

Перевели дыхание от смеха? Рано расслабились, у автора есть еще козыри в рукаве:

Таблица 1.2. Значение выделенных IP-адресов IP-адрес Значение 0.0.0.0 Данный хост Номер сети.0.0.0 Данная IP-сеть 0.0.0.номер хоста Конкретный компьютер в данной локальной сети 1.1.1.1 Все компьютеры в данной локальной сети Номер сети.1.1.1 Все компьютеры в указанной IP-сети

Это не просто домашняя страничка Васи Пупкина, на которой может быть что угодно. Это вполне реальная книга, изданная издательством "Питер", и мне даже посчастливилось быть обладателем бумажного экземпляра. Пруфлинк здесь: http://www.piter.com/attachment.php?barcode=978527200338&at=exc&n=0 . Почитайте, не пожалеете, там еще много смешного.

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

[RXL]

Dale, судя по приведенным цитатам, книгу он не писал, а переводил с неизвестного языка.
Посмотри список книг автора — его вообще нельзя рассматривать серьезно. И "пакеты" тут не при чем.

[Алексей++]

а мне первые слова по ссылке понравились ))

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

особенно про тягу к открытию чего-то скучного )

[Dale]

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

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

[Алексей++]

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

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

[Dale]

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

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

Примерно как сейчас маргинальные бабушки дефилируют с плакатами "Верните нам Малахова!"...

[Sla]

Предлагаю устроить охоту на хомячков.

[Алексей++]

а что, малахова уже куда-то дели ? ))

[Dale]

Поздно... Книга была издана в 2001 году. Второе издание вышло в 2003, и все лулзы, на которые я указал автору, были аккуратно изъяты, хоть аффтар поначалу и ерепенился.. Уже и пруфлинков-то почти не осталось: бумажную книгу я подарил какому-то начинающему веб-дизайнеру, а сканы нашел только 2-го издания. Приведенная ссылка чудом сохранилась.

[Dale]

а что, малахова уже куда-то дели ? ))

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

[Вад]

Пруфлинк здесь: http://www.piter.com/attachment.php?barcode=978527200338&at=exc&n=0 . Почитайте, не пожалеете, там еще много смешного.

Отзывы читателей на 1е издание (http://www.piter.com/book.phtml?978527200338) тоже блещут оригинальностью. Может, это живые люди, но я что-то не верю. Или критика выпиливалась издательством

[Алексей++]

а щас проверим, как работает цензура )

[Алексей++]

вот и ответ

[Dale]

Или критика выпиливалась издательством

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

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

[Dimka]

Протокол передачи файлов FTP

Завершая тему устройства и принципов работы Интернета, хочу коснуться еще одного сетевого протокола -- протокола передачи файлов FTP (File Transfer Protocol).

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

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

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

Вот про UDP - чей-то бред. И таблица некорректна.

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

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

[Dale]

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

А мне эти "даонлоады" напомнили одного товарища, который учил немецкий. Когда он пришел потолковать о Паскале, я еще догадался, что "врите" - это не призыв лгать, а процедура вывода. Но когда речь зашла об операторе "цазе", я так и не смог ничего понять, пока он не ткнул пальцем в case. Извращения над терминами все же должны иметь какой-то предел. Неужели так сложно заглянуть в словарь и посмотреть транскрипцию этого слова ['daunləud]?

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

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

[Dimka]

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

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

[Dale]

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

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

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