Здравствуйте, LaptevVV, Вы писали:
LVV>Вышел перевод книжки по оптимизации программ на С++.
Интересно, в разделе "Эффективно использовать функции потокового ввода-вывода C++" там просто написано "Не используйте функции потокового ввода-вывода C++"?
Здравствуйте, kaa.python, Вы писали:
LVV>>Это, наверно, big-endian и little-endian? :)) KP>Да, оно. Но блин, нельзя же даже оглавление так халтурно переводить-то. На нем же первое ощущение базируется.
Это не халтурный перевод. Это культурный референс к произведению Джонатана Свифта
Здравствуйте, disputANT, Вы писали:
ANT>Уж что-что, а little endian и big endian перевод имеют давний и устоявшийся — прямой и обратный порядок байтов.
А какой из них прямой, и какой — обратный?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, cures, Вы писали:
C>Вот тогда получится полная фигня, ибо англоязычная аудитория отлично знает, что такое big-endian и little-endian, откуда они взялись, а у русскоязычной нет этих слов в общекультурном контексте, хотя есть их классический перевод. Это будет больше похоже на подстрочник, а не на литературный перевод.
Фигня получается, когда есть непонятный перевод, будь он хоть 10 раз литературный, тут не художественную литературу переводят. У той аудитории, для которой книга предназначена, LE/BE вполне рабочие понятия, а вот за "остроконечными" придется лезть в первоисточник/словарь/гугл, чтобы вообще понять, что это такое.
Перевод должен упрощать чтение для тех, кому на английском не комфортно, а не ставить идиотские задачи по его расшифровке.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, cures, Вы писали:
C>Как, собственно, и сами переводимые термины. У нас это немножко по-дурацки звучит, так это с непривычки. C>А какие ещё есть варианты перевода?
Не переводить. Как минимум не переводить то, что не имеет устоявшегося перевода, пусть даже и сленгового.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Перевод должен упрощать чтение для тех, кому на английском не комфортно, а не ставить идиотские задачи по его расшифровке.
"Давайте спорить о вкусе омаров с теми, кто их ел". (с) Жванецкий
Не поленился, вчера сумел через третьи руки раздобыть текст этого раздела и даже набрал его
Остроконечные и тупоконечные слова
Из памяти может быть выбран один байт данных, но зачастую одновременно извлекается несколько последовательных байтов, образующих число. Например, в Microsoft Visual C++ значение типа int образуют четыре байта, считываемые из памяти вместе. Так как к памяти можно обращаться двумя способами, люди, которые проектируют компьютеры, должны ответить на важный вопрос: что содержится в первом байте (адрес которого наименьший) — старшие или младшие биты значения int?
На первый взгляд кажется, что это не должно иметь значения. Конечно, важно, чтобы все части компьютера одинаково считали, с какого конца int адрес меньше, иначе воцарится хаос. Вот в чем заключается разница между этими способами хранения. Если значение int, равное 0x01234567, хранится по адресам 1000–1003 и первым хранятся старшие биты, то по адресу 1000 содержится байт 0x01, а по адресу 1003 — байт 0x67, в то время как если сначала хранится младший байт, то по адресу 1000 содержится 0x67, а по адресу 1003 — 0x01. Компьютеры, которые хранят старшие биты в байте с младшим адресом, называются компьютерами с обратным порядком байтов ("тупоконечниками", big-endian). Компьютеры с прямым порядком байтов ("остроконечники", little-endian) сначала читают младшие биты. Итак, имеется два способа хранения целого числа (или указателя), и нет никаких причин предпочесть один другому, так что разные команды, работающие на разных процессорах для разных компаний, могут делать разный выбор.
Проблемы начинаются, когда данные, записанные на диск или отправленные по сети одним компьютером, должны быть прочитаны другим компьютером. Диски и сети пересылают информацию побайтно, а не весь int одновременно. Поэтому оказывается важно, какой конец числа сохраняется (или отправляется) первым. Если отправляющий и принимающий компьютеры не согласованы, то значение, отправляемое как 0x01234567, может быть получено как 0x67452301.
Порядок байтов является лишь одной из причин, по которым C++ не определяет, как биты располагаются в int или как значение одного поля в объединении влияет на другие поля. Это одна из причин, по которым программу можно написать так, что она будет успешно работать на компьютере одного вида, но приводить к аварийному завершению на другом.
Здравствуйте, disputANT, Вы писали:
ANT>Здравствуйте, netch80, Вы писали: N>>И ни одного реально "солидного" источника.
ANT>Ну приведите вы "солидные" источники. Критика должна быть конструктивной
Я привёл ссылки на academic.ru. Это, если говорить о русском языке, очень солидный источник.
Да, и напоминаю, что и Вы привели ссылку на вариант, где сделано по-моему (и ни одного возражения не было).
N>>Даже если Вы не согласны с принципом, то утверждать про "давний и устоявшийся" перевод — грубо неверно. (Ну а я считаю, что термины диверсионны, но только big-endian имеет право зваться прямым.)
ANT>Как только вы переведете и издадите пару книг, в которых будут ВАШИ термины, ваше мнение станет существенно весомее
Здравствуйте, LaptevVV, Вы писали:
V>>Книгу, может быть, и стоит почитать, но интересно, мне одному кажется что с ценой перегиб, или это сейчас ОК? LVV>Я заказал за 2, а потом она вдруг резко стала 3... :
Ну что вы зделали... теперь ясно кого винить .
Если серьезно, ну книга явно же из серии — пробежался по маленьким главам, убедился что с 80% согласен и всегда так делаешь сам. С++ программисты конечно хорошо получают, но они же не идиоты
Здравствуйте, rumit7, Вы писали:
R>теоретически в нэте имелась англ электронная версия, один мой знакомый даже читал
Да, я может тоже, если не лень будет, найду при случае такого знакомого
Проблемка в другом. Даже если какой-то русский знакомый вдруг её прочитает, он вряд ли слишком многим расскажет о своих впечатлениях. Поэтому у автора есть большой соблазн загнуть туда полной (или не совсем полной, по его мироощущению) мути и ждать классического развития событий: первая волна прочитавших порекомендует книгу второй волне, дабы не им одним оставаться в дураках. А потом обе волны вместе придут кидаться помидорами, но автор уже сделает ноги.
И даже при его полной сознательности, тема слишком волатильная, чтобы можно было опираться на когда-то сложившееся мнение одного человека, которое он продаёт за деньги. Поэтому трудно ожидать от подобного труда чего-то кроме беглого проскока по верхушкам. Ну и, когда я пытаюсь себе представить, как Фихтенгольц отводит первую пару глав на рассказ о том, как щас читатель научится круто рюхать задачки и грести бабло, и что ботать матан не так уж и западло, как принято считать, у меня это немножко не укладывается в голове
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, cures, Вы писали:
C>> Это будет больше похоже на подстрочник, а не на литературный перевод. E>Лит. перевод терминов -- зло. E>Например, как ты переведёшь русский IT-термин "магазин"?
Если ты про "стек", то слово "магазин" в этой роли, кажется, давно вымерло.
Если ты про интернет-магазин, то там кроме shop вариантов, кажется, и нет.
В чём проблема-то?
LVV>Устоявшегося термина нет. Предложите, как будет лучше.
future и promise. Надеюсь, в типографии латинские буквы не кончились.
Читатель сразу начнет понимать как обсуждаемые сущности соотносятся с классами стандартной библиотеки. Впрочем, первый раз используя термин, можно пояснить на русском как он переводится.
Здравствуйте, LaptevVV, Вы писали:
U>>Книга меня разочаровала. Читал в оригинале. Книга на уровне "делай это, того не делай". Ну и вода, куда-ж без неё. С практической точки зрения информации там мало. U>>Вообще, в последнее время ничего путнего по С++ не пишут. Скучно стало как-то. LVV>Да как-то уже понаписано дофига. LVV>А по поводу оптимизации... LVV>Иногда самые простые вещи неожиданно приносят потрясающий результат.
Интересный доклад, посвященный оптимизации, был на C++ Russia'17 (на страничке есть презенташка с доклада).
Вкратце: многие "документированные" трюки перестали работать. Причины: кеши процессора, многоядерность, оптимизирующие компиляторы...
_____________________
С уважением,
Stanislav V. Zudin
Просматривал книжку по диагонали.
1. Что-то как-то не попалось откровенных ляпов типа "остроконечные" и "тупоконечные".
Такое впечатление, что это в английском оригинале реальный намек на Свифта.
Что и воспроизвел переводчик. Наверное, надо было примечание переводчика добавить.
2. Книжка — не для крутых профи, а для въезда в предмет.
По ней неплохо лекции читать.
Отмечу, что в самом начале довольно подробно разбираются несколько функций WinAPI для работы со временем.
3. Довольно интересные врезки об оптимизационных войнах — истории из реальной жизни.
Одну я на лекции 2 курса уже использовал: про линейный и двоичный поиск...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Вышел перевод книжки по оптимизации программ на С++.
Книга меня разочаровала. Читал в оригинале. Книга на уровне "делай это, того не делай". Ну и вода, куда-ж без неё. С практической точки зрения информации там мало.
Вообще, в последнее время ничего путнего по С++ не пишут. Скучно стало как-то.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, disputANT, Вы писали:
ANT>>Уж что-что, а little endian и big endian перевод имеют давний и устоявшийся — прямой и обратный порядок байтов.
Ops>А какой из них прямой, и какой — обратный?
Здравствуйте, cures, Вы писали:
C>Здравствуйте, Qbit86, Вы писали:
Q>>Это не халтурный перевод. Это культурный референс к произведению Джонатана Свифта
C>Как, собственно, и сами переводимые термины. У нас это немножко по-дурацки звучит, так это с непривычки. C>А какие ещё есть варианты перевода?
Мне нравится вариант — "восходящий" и "нисходящий" порядок.
Это ещё и хорошо переводит конструкции типа "little-endian array of big-endian words" (например, про GMP на BE платформе). (И чего я вначале писал, что плохо переводит? не выспался, наверно)
Здравствуйте, Ops, Вы писали:
Ops>Не переводить. Как минимум не переводить то, что не имеет устоявшегося перевода, пусть даже и сленгового.
Вот тогда получится полная фигня, ибо англоязычная аудитория отлично знает, что такое big-endian и little-endian, откуда они взялись, а у русскоязычной нет этих слов в общекультурном контексте, хотя есть их классический перевод. Это будет больше похоже на подстрочник, а не на литературный перевод.
Здравствуйте, Ops, Вы писали:
C>>Вот тогда получится полная фигня, ибо англоязычная аудитория отлично знает, что такое big-endian и little-endian, откуда они взялись, а у русскоязычной нет этих слов в общекультурном контексте, хотя есть их классический перевод. Это будет больше похоже на подстрочник, а не на литературный перевод.
Ops>Фигня получается, когда есть непонятный перевод, будь он хоть 10 раз литературный, тут не художественную литературу переводят. У той аудитории, для которой книга предназначена, LE/BE вполне рабочие понятия, а вот за "остроконечными" придется лезть в первоисточник/словарь/гугл, чтобы вообще понять, что это такое.
Это проблема вообще с любыми неологизмами. Если её драматизировать, то и развивать язык нельзя.
Ops>Перевод должен упрощать чтение для тех, кому на английском не комфортно, а не ставить идиотские задачи по его расшифровке.
Один раз запомнил и пошёл дальше. Меня вначале больше смущал именно конкретный "маппинг" на понятия LE и BE, на каком бы языке они ни звучали. И это как раз то, о чём говорит cures@: "начинать" "есть" с какого конца — это от чтения Свифта, а для тех, кто этого не читал или давно забыл, требуется дополнительное пояснение.
Один мой знакомый, в остальном с неплохой памятью, никак не мог запомнить, когда AM, а когда PM. Кое-как вроде запомнил, что они по алфавиту. Это ровно та же проблема (для создания правильной сети ассоциаций надо хотя бы вчерне знать латынь).
Здравствуйте, cures, Вы писали:
C> Это будет больше похоже на подстрочник, а не на литературный перевод.
Лит. перевод терминов -- зло.
Например, как ты переведёшь русский IT-термин "магазин"?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Лит. перевод терминов -- зло.
Литературный перевод делается не терминов, а книг. Иначе в любой компьютерной или математической книжке литературными были бы только предлоги и союзы Подозреваю, что покупали бы подобные "переводы" гораздо хуже: те, кто готов читать их в таком виде, не обломится прочитать в оригинале.
Да и книжка эта скорее литературный продукт нежели технический, в ней главное — "cool story" ака увлекательность и заманчивость, как в пиратах. Тот, кто оптимизирует программы, просмотрит её по диагонали на предмет, не прошло ли мимо какое-то новшество. А кто никогда этого не делает — прочитает как про пиратов, повосхищается и помечтает.
E>Например, как ты переведёшь русский IT-термин "магазин"?
Перевод без контекста не делается же, выше уже написали.
Здравствуйте, netch80, Вы писали:
E>>Например, как ты переведёшь русский IT-термин "магазин"?
N>Если ты про "стек", то слово "магазин" в этой роли, кажется, давно вымерло.
Это в "це Европе" вымерло, а там, где свой армейский хайтек жив, всё живо...
Так, тем не менее, как так литературно перевести "stack" как "магазин" (или обратно)?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
LVV>>1. Что-то как-то не попалось откровенных ляпов типа "остроконечные" и "тупоконечные". U>в оглавлении "Обещания и фьючерсы"
Точно как в переводе книги Джоссатиса по STL.
Фьючерсы ИМХО вообще уже привычный термин.
Обещания — это promise.
Устоявшегося термина нет. Предложите, как будет лучше.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, uzhas, Вы писали:
U>это не перевод. это отсутствие перевода
с одной стороны книга на русском. с другой, примеры кода — на языке оригинала — на английском (мы не про 1С)
тут уместно оставить написание в оригинале (можно в начале книги дать пример чтения\транскрипцию)
возьмем std::cout. как его на русский перевести? "выхлоп" ? или "цэ наружу" ? "yeyf[" ? лучше оригинал оставить: cout
Здравствуйте, Ops, Вы писали:
N>>И ещё и потому я думаю, что "нисходящий" и "восходящий" удобны тем, что понятны сразу без таких связей.
Ops>Не думаю. "нисходящий" и "восходящий" — это верх и низ, а у меня в голове в этом контексте "право"-"лево", т.е. опять путаница.
С картинкой, как я уточнял для cures@, годится? Тут всё равно сложно что-то адекватное подобрать. Калька ("тупоконечный"/etc.) — не решение, а капитуляция.
Здравствуйте, Marty, Вы писали:
M>Кортеж в области БД хорош, он там давно прижился. А в ЯП как-то тупля привычнее. Ну, или "структура". Имхо, конечно
Вроде как в русскоязычной лит-ре "тупля" уже лет 50 называется кортежем...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, andyp, Вы писали:
E>>Ну если код базируется на английском, то там слово "кортеж" не нужно. А если на русском, то можно typedef сделать или ещё что.
A>Можно, но я так не делаю.
Ты пишешь код с русскими идентификаторами?
E>> Ну с терминами read write ты же как-то миришься?
A>Ты имеешь в виду, что я мирюсь с тем, что эти слова переводят на русский в переводных книжках? Ну да, мирюсь. Книжка станет менее понятной, если эти слова без перевода оставить. С tuple, как по мне, книжка будет более понятной и полезной без перевода этого слова (ну кроме того места, где это понятие вводится).
Вот есть функция WriteTupleToDst
Почему в описании её работы слово write переводить на русский надо, а слово tuple нет?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
M>>Ну, своё видение этого терминологического вопроса я описал. Кортежи изобрели давно. Тупли — позже. Еще вопросы?
E>"Тупли" тут про авторов или про структуру? E>Если про структуру, то чем "тупля" (или "тупль?) от кортежей отличаются? Индексируемая коллекция данных разных типов жеж?
Про структуру. Её еще иногда тьюплом кличут.
У меня как-то (сугубо лично, впрочем) впечатление, что кортежи это то, что выдает SQL запрос — что запросил, такой кортеж и получил. А структура — как в коде забито, то уже никуда не денешся
M>>Стек я изучал на Z80 по англоязычным описаниям и мутным переводам. А про "магазины" и автоматы с "магазинной памятью" рассказывали уже в институте. Магазин — неудачное слово, имеющее слишком много смыслов: E>Stack -- тоже слово многозначное. Основное значение -- что-то среднее между стогом сена и поленницей дров. E>Да и русское "стек" может означать палку, которой лошадь лупят.
Это скорее стимул
M>>магазин патронов (для ППШ тоже вроде магазин — но там точно стек?) E>Ну у ППШ точно, просто в бараний рог загнутый
Здравствуйте, Erop, Вы писали:
E>Я так и не понял, как ты собираешься решать, какие слова надо переводить, а какие нет.
Не я, а переводчик. Я лишь свое имхо выражаю, а за перевод книжек не берусь. Те термины, для которых есть классы в стандартной библиотеке — хорошие кандидаты. Также, есть много концепций из стандарта — типа sequenced before, shared state и иже с ними. Не замечал, что даже здесь народ их в русском тексте постоянно использует, чтобы избежать двусмысленности, ну и потому, что русские термины не устоялись или неизвестны пишущему?
E>Я уже не говорю, что использовать английские слова в русской речи неудобно. E>"Эти два кортежа в этом алгоритме самые важные" как надо писать в твоей стиллистике?
Достаточно удобно, когда про письменную речь разговор. Отбрасываешь русские падежные окончания, заменяешь английскими, если требуется, и пишешь. Это на слух звучит коряво, а в напечатанном тексте нормально воспринимается:
"Эти два tuples в этом алгоритме самые важные"
Ведь, собственно, и кортеж-то слово заимствованное. Из радостей его использования только то, что написано оно кириллицей и склонять его можно. Из минусов — при переходе на английскую тех. литературу придется сопоставлять известные понятия неизвестным английским словам. А прекрасно склоняемые "фьючерсы" и "промисы" на мой взгляд не менее оскорбительны для языкового пуриста.
V>Книгу, может быть, и стоит почитать, но интересно, мне одному кажется что с ценой перегиб, или это сейчас ОК?
Я заказал за 2, а потом она вдруг резко стала 3... :
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Videoman, Вы писали:
V>Если серьезно, ну книга явно же из серии — пробежался по маленьким главам, убедился что с 80% согласен и всегда так делаешь сам.
Или что не согласен, и сам никогда так не делаешь
V>С++ программисты конечно хорошо получают, но они же не идиоты
Но мы не можем заранее сказать то же самое про неизвестного нам автора.
Агнер к этому вопросу серьёзно подходит, и делает это доступно и свободно, каждый может обсудить. А тут проприетарная книжка незнакомого товарища, и что в ней написано — знают только купившие, но никому не скажут, ибо заплатили деньги и не хотят лишаться "конкурентного преимущества"
V>Книгу, может быть, и стоит почитать, но интересно, мне одному кажется что с ценой перегиб, или это сейчас ОК?
Это нам ещё скидку небольшую сделали, оригинал (печатный) в ихнем шопе стоит 60 баксов, то бишь 3400 по сегодняшнему курсу. Правда, там к нему за дополнительные 6 баксов предлагают электронную версию, у нас вряд ли так рискнут. Зато твёрдый переплёт, а про оригинал ничего не сказано. А в целом — грех не заработать на нежелающих учить английский.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, cures, Вы писали:
C>>Как, собственно, и сами переводимые термины. У нас это немножко по-дурацки звучит, так это с непривычки. C>>А какие ещё есть варианты перевода?
Ops>Не переводить. Как минимум не переводить то, что не имеет устоявшегося перевода, пусть даже и сленгового.
Уж что-что, а little endian и big endian перевод имеют давний и устоявшийся — прямой и обратный порядок байтов.
C>Агнер к этому вопросу серьёзно подходит, и делает это доступно и свободно, каждый может обсудить. А тут проприетарная книжка незнакомого товарища, и что в ней написано — знают только купившие, но никому не скажут, ибо заплатили деньги и не хотят лишаться "конкурентного преимущества"
Я расскажу, как прочитаю.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
C>>Агнер к этому вопросу серьёзно подходит, и делает это доступно и свободно, каждый может обсудить. А тут проприетарная книжка незнакомого товарища, и что в ней написано — знают только купившие, но никому не скажут, ибо заплатили деньги и не хотят лишаться "конкурентного преимущества" LVV>Я расскажу, как прочитаю.
теоретически в нэте имелась англ электронная версия, один мой знакомый даже читал
Здравствуйте, std.denis, Вы писали:
SD>ну например "У слов есть старший байт и младший байт" (ориг.: "Memory Words Have a Big End and a Little End")
В данной фразе — неплохой вариант, но надо смотреть на контекст. Я оригинал (как и перевод) не читал, а там сразу после этого может быть написано "поэтому есть два варианта расположения байт слова в памяти: big-endian и little-endian". И как сюда пришить наши старший-младший байты? Перевести варианты как "старшебайтный" и "младшебайтный"? Если бы автор хотел сказать так, он бы написал "have a high byte and a low byte".
Здравствуйте, disputANT, Вы писали:
ANT>>>Уж что-что, а little endian и big endian перевод имеют давний и устоявшийся — прямой и обратный порядок байтов.
Ops>>А какой из них прямой, и какой — обратный?
ANT>Смотрим навскидку:
Даже если Вы не согласны с принципом, то утверждать про "давний и устоявшийся" перевод — грубо неверно. (Ну а я считаю, что термины диверсионны, но только big-endian имеет право зваться прямым.)
UPD2: А Вы и не заметили, что по Вашей ссылке на хабр — прямым назван big-endian. Кто поспешит — насмешит
Здравствуйте, netch80, Вы писали: N>И ни одного реально "солидного" источника.
Ну приведите вы "солидные" источники. Критика должна быть конструктивной
N>Даже если Вы не согласны с принципом, то утверждать про "давний и устоявшийся" перевод — грубо неверно. (Ну а я считаю, что термины диверсионны, но только big-endian имеет право зваться прямым.)
Как только вы переведете и издадите пару книг, в которых будут ВАШИ термины, ваше мнение станет существенно весомее
Здравствуйте, netch80, Вы писали:
N>Это проблема вообще с любыми неологизмами. Если её драматизировать, то и развивать язык нельзя.
Скорее проблема в отсутствии авторитетного перевода, и в том, что авторы новых считают их понятными без пояснений.
N>Один раз запомнил и пошёл дальше. Меня вначале больше смущал именно конкретный "маппинг" на понятия LE и BE, на каком бы языке они ни звучали.
Так тут еще дополнительный маппинг, пусть и логичный, для тех, кто уже отмапил английские термины. Кстати, "отмапить" понятно без пояснений, а как это перевести литературно? Спроецировать?
N>И это как раз то, о чём говорит cures@: "начинать" "есть" с какого конца — это от чтения Свифта, а для тех, кто этого не читал или давно забыл, требуется дополнительное пояснение.
А Свифта большинство читало в переводе, вне связи с порядком байт. Я вот вообще до этой темы не знал, что BE/LE из него, хотя книжку слушал, емнип, еще с пластинки, не умея читать. Вероятно, большинство точно так же не видит этой отсылки, хотя, надо признать, перевод был бы неплохой, распространись он сразу в нужном контексте. Но что выросло — то выросло, давно уже живем с английскими.
N>Один мой знакомый, в остальном с неплохой памятью, никак не мог запомнить, когда AM, а когда PM. Кое-как вроде запомнил, что они по алфавиту. Это ровно та же проблема (для создания правильной сети ассоциаций надо хотя бы вчерне знать латынь).
Я тоже не помню, и каждый раз обдумываю
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
N>>Это проблема вообще с любыми неологизмами. Если её драматизировать, то и развивать язык нельзя. Ops>Скорее проблема в отсутствии авторитетного перевода, и в том, что авторы новых считают их понятными без пояснений.
Хм, ну, сколько я видел, обычно поясняют эти термины. А где не поясняют, там считают, что читатель и так должен обладать достаточным уровнем понятий в системном программировании (это всякие форумы и тому подобное).
N>>Один раз запомнил и пошёл дальше. Меня вначале больше смущал именно конкретный "маппинг" на понятия LE и BE, на каком бы языке они ни звучали. Ops>Так тут еще дополнительный маппинг, пусть и логичный, для тех, кто уже отмапил английские термины. Кстати, "отмапить" понятно без пояснений, а как это перевести литературно? Спроецировать?
Да, "спроецировать" очень хорошо подходит (хотя длиннее )
И ещё и потому я думаю, что "нисходящий" и "восходящий" удобны тем, что понятны сразу без таких связей.
N>>И это как раз то, о чём говорит cures@: "начинать" "есть" с какого конца — это от чтения Свифта, а для тех, кто этого не читал или давно забыл, требуется дополнительное пояснение. Ops>А Свифта большинство читало в переводе, вне связи с порядком байт. Я вот вообще до этой темы не знал, что BE/LE из него, хотя книжку слушал, емнип, еще с пластинки, не умея читать. Вероятно, большинство точно так же не видит этой отсылки, хотя, надо признать, перевод был бы неплохой, распространись он сразу в нужном контексте. Но что выросло — то выросло, давно уже живем с английскими.
Я просто тоже из Свифта не помнил. Но это скорее детское восприятие — тема войны за разбитие яйца неинтересна.
Здравствуйте, Qbit86, Вы писали:
N>>Я просто тоже из Свифта не помнил. Но это скорее детское восприятие — тема войны за разбитие яйца неинтересна.
Q>Она тем и интересна, что неинтересна. В этом её смысл. Символ бессмысленного противостояния. Как противостояние чётников и нечётников на Лепре.
Это интересно взрослому, факт. И то — философски настроенное
А ребёнку — скорее никак.
Здравствуйте, netch80, Вы писали:
N>Да, "спроецировать" очень хорошо подходит (хотя длиннее )
Да в том-то и дело, что только литературно неплохо подходит, а на самом деле может запутать, потому что не применяется повсеместно в таком качестве. Еще "отображение", даже лучше. N>И ещё и потому я думаю, что "нисходящий" и "восходящий" удобны тем, что понятны сразу без таких связей.
Вот так можно, согласен.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
N>>Да, "спроецировать" очень хорошо подходит (хотя длиннее ) Ops>Да в том-то и дело, что только литературно неплохо подходит, а на самом деле может запутать, потому что не применяется повсеместно в таком качестве. Еще "отображение", даже лучше.
Сопоставить?
N>>И ещё и потому я думаю, что "нисходящий" и "восходящий" удобны тем, что понятны сразу без таких связей. Ops>Вот так можно, согласен.
И тут можно поспорить. Зависит от того, как вы представляете себе расположение адресов по вертикали Сначала я полагал, что они, как на математических чертежах, должны увеличиваться вверх, тогда BE — нисходящее (значимость байтов увеличивается вниз). Потом стал воспринимать их соответственно тому, как пикселы в них располагаются на экране (трудное детство, большие мониторы), и BE стало восходящим. Теперь мне скорее без разницы, и восходящий-нисходящий воспринимаются как корявость речи для облегчения понимания непонятно кем и непонятно зачем.
Ops>А Свифта большинство читало в переводе, вне связи с порядком байт.
Так он скорее всего и писал вне всякой связи с байтами или их порядком
Ops>Я вот вообще до этой темы не знал, что BE/LE из него, хотя книжку слушал, емнип, еще с пластинки, не умея читать.
Вот заодно и узнали!
Ops>Вероятно, большинство точно так же не видит этой отсылки
Таки да, видят её не все, но время от времени некоторые прибегают с этим открытием и радуются
Конечно, этот перевод может быть злостным спойлером, лишить многих возможности самим это заметить, но всё же узнавание классических вещей через книги скорее позитивно, чем негативно.
Здравствуйте, cures, Вы писали:
N>>>И ещё и потому я думаю, что "нисходящий" и "восходящий" удобны тем, что понятны сразу без таких связей. Ops>>Вот так можно, согласен. C>И тут можно поспорить. Зависит от того, как вы представляете себе расположение адресов по вертикали
При чём тут вертикальное расположение адресов??
Если что-то тут представлять, то высоту (как показатель веса) значения в каждом байте, а не расположение самих байтов (оно остаётся горизонтальным, слева меньшие адреса, справа большие).
Здравствуйте, netch80, Вы писали:
N>При чём тут вертикальное расположение адресов?? N>Если что-то тут представлять, то высоту значения в каждом байте, а не расположение самих байтов (оно остаётся горизонтальным, слева меньшие адреса, справа большие).
N>Это был нисходящий == big-endian. Очень наскоро, но должно быть понятно.
Ничего не понял, почему 0 такой здоровый, а единичка такая маленькая? Они же каждый по байту?
Или Вы в качестве высоты используете сдвиг байта внутри слова? Тогда, опять же, почему его откладываете вверх, а не вниз?
Здравствуйте, Erop, Вы писали:
E>>>Например, как ты переведёшь русский IT-термин "магазин"?
N>>Если ты про "стек", то слово "магазин" в этой роли, кажется, давно вымерло.
E>Это в "це Европе" вымерло, а там, где свой армейский хайтек жив, всё живо...
В .ru я не наблюдал такого использования лет 25. С "почтовыми ящиками" дела не имел, да, но что на гражданке — в курсе — "магазин" можно было найти только в очень старых книгах (не позже 60-х).
E>Так, тем не менее, как так литературно перевести "stack" как "магазин" (или обратно)?
Здравствуйте, cures, Вы писали:
C>Да и книжка эта скорее литературный продукт нежели технический, в ней главное — "cool story" ака увлекательность и заманчивость, как в пиратах. Тот, кто оптимизирует программы, просмотрит её по диагонали на предмет, не прошло ли мимо какое-то новшество. А кто никогда этого не делает — прочитает как про пиратов, повосхищается и помечтает.
"cool story" не переводчик должен сочинять, а автор. Возьми, например, "конкретную математику" Кнута. А у переводчиков куда чаще получается "ученый изнасиловал журналиста", с большой вероятностью этот тупоконечный просто очень плохо знает предметную область, но при этом читал художественную литературу в оригинале.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>"cool story" не переводчик должен сочинять, а автор.
Я про автора и написал, что по моим ощущения он написал вполне художественную книжку, которую нелитературным языком переводить смысла вообще нет, не купит никто.
Ops>Возьми, например, "конкретную математику" Кнута.
Мне не понравилась. Искусство программирования гораздо лучше шло, а в "Конкретной Математике" во второй половине пошёл странный треш, который, наверное, даже верен, но никто и не пытается объяснить, почему.
Ops>А у переводчиков куда чаще получается "ученый изнасиловал журналиста", с большой вероятностью этот тупоконечный просто очень плохо знает предметную область, но при этом читал художественную литературу в оригинале.
У меня нет оснований такое предполагать. Знание классической художественной литературы не обязательно означает непонимание предмета. А вот про автора — уже есть сомнения, судя по маркетологическому введению и оглавлению оригинала.
LVV>>Вышел перевод книжки по оптимизации программ на С++. U>Книга меня разочаровала. Читал в оригинале. Книга на уровне "делай это, того не делай". Ну и вода, куда-ж без неё. С практической точки зрения информации там мало. U>Вообще, в последнее время ничего путнего по С++ не пишут. Скучно стало как-то.
Да как-то уже понаписано дофига.
А по поводу оптимизации...
Иногда самые простые вещи неожиданно приносят потрясающий результат.
Я вот на своем ноуте проверил умножение матриц. Относительно небольшие 1000 на 1000
Циклы вложены в порядке ijk (стандартный порядок), и замеряется время.
А потом порядок циклов просто меняем местами: JKI, KJI и т.п.
И в некоторых вариантах время уменьшается до 10 раз.
Без всякой оптимизации и распараллеливания.
Вот так кэш влияет...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Интересный доклад, посвященный оптимизации, был на C++ Russia'17 (на страничке есть презенташка с доклада).
Здравствуйте, uncommon, Вы писали:
SVZ>>Интересный доклад, посвященный оптимизации, был на C++ Russia'17 (на страничке есть презенташка с доклада).
U>видео есть?
У меня нету
А вообще организаторы вели видеосъемку на всех докладах. Но когда опубликуют —
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, LaptevVV, Вы писали:
LVV>Я вот на своем ноуте проверил умножение матриц. Относительно небольшие 1000 на 1000 LVV>Циклы вложены в порядке ijk (стандартный порядок), и замеряется время. LVV>А потом порядок циклов просто меняем местами: JKI, KJI и т.п. LVV>И в некоторых вариантах время уменьшается до 10 раз. LVV>Без всякой оптимизации и распараллеливания. LVV>Вот так кэш влияет...
Это как раз не удивительно, с этого обычно начинаются книжки по вычислительной линейке.
А если по науке сделать, блоками 32*32, во сколько раз ускорится?
Здравствуйте, uncommon, Вы писали:
U>Книга меня разочаровала. Читал в оригинале. Книга на уровне "делай это, того не делай". Ну и вода, куда-ж без неё. С практической точки зрения информации там мало.
Угу, в комментах на амазоне народ ругается, что результаты не воспроизводятся.
Основная беда — товарищ ниасилил выложить полный набор тестов на гитхаб. Приводить основной тестируемый код — дело, конечно, обязательное, но хорошим тоном было бы выкладывать тестирующие программы целиком, вместе с наборами входных данных (либо их генераторами) и параметрами запуска.
А так теперь угадывай, то ли мелкософтовский компилер такой убогий, то ли товарищ измерял фиг знает что.
Наверное, виндусятники не умеют в гитхаб.
Кроме воды ещё забавен подход, когда я потыкал вот так и вот так, вот так лучше, но почему — хз, наверное "этот алгоритм получил доступ к содержимому в обход того АПИ". Это открытая STL, ну разберись ты, откуда взялось ускорение в несколько раз, ты же книжку пишешь, блин. А на другой реализации будет всё по-другому, надо ускоряться — вообще забиваем на неведомую фигню и пишем руками.
U>Вообще, в последнее время ничего путнего по С++ не пишут. Скучно стало как-то.
"Чтоб ты жил в эпоху перемен!" Идёт спокойное развитие, по 14 и 17 стандарту идёт лёгкое бурление, иногда по смежным вопросам типа кути.
LVV>>Без всякой оптимизации и распараллеливания. LVV>>Вот так кэш влияет... C>Это как раз не удивительно, с этого обычно начинаются книжки по вычислительной линейке. C>А если по науке сделать, блоками 32*32, во сколько раз ускорится?
Зависит, вообще говоря, от компьютера.
Сам не пробовал.
Но есть такая книжка: http://www.ozon.ru/context/detail/id/7374161/ — Практикум по методам параллельных вычислений.
Там схемы умножения матриц с табличками расписаны.
По табличкам видно, что блочное умножение матриц 2000х2000 даже без паралллельности дает ускорение в 10 раз на компе авторов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Qbit86, Вы писали:
Q>Не транслит, а калька. Она позволяет адаптировать заимствованные слова к хост-языку, порождать разные словоформы. В частности, падежи.
ИМХО, единственная от нее польза — примерно передает как произносится.
Здравствуйте, andyp, Вы писали:
Q>>Не транслит, а калька. Она позволяет адаптировать заимствованные слова к хост-языку, порождать разные словоформы. В частности, падежи.
A>ИМХО, единственная от нее польза — примерно передает как произносится.
Польза от падежей только в том, что передаёт, как произносится? Это новое слово в лингвистике.
LVV>>Устоявшегося термина нет. Предложите, как будет лучше. A>future и promise. Надеюсь, в типографии латинские буквы не кончились. A>Читатель сразу начнет понимать как обсуждаемые сущности соотносятся с классами стандартной библиотеки. Впрочем, первый раз используя термин, можно пояснить на русском как он переводится.
Вот с этим согласен.
Однако донести бы это до переводчиков.
В блоге Штонды написать?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>>Предложите, как будет лучше. U>промисы и фьючеры
Ну, не знаю. Промисы на русском совсем непривычно.
Фьючеры — фьючерсы хотя бы из экономики привычны.
Тут в соседней ветке предложили оставлять английские термины.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
A>>Можно. Слезно попросить, чтоб хотя бы tuple пощадил — а то появится в русском какой-нибудь тапл или тупл. SVZ>Кортеж. Этот термин уже устоялся в СУБД.
Да. В Джосатисе — такой термин.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>>>Устоявшегося термина нет. Предложите, как будет лучше. A>>future и promise. Надеюсь, в типографии латинские буквы не кончились. A>>Читатель сразу начнет понимать как обсуждаемые сущности соотносятся с классами стандартной библиотеки. Впрочем, первый раз используя термин, можно пояснить на русском как он переводится. LVV>Вот с этим согласен.
Это будет уже не перевод книги. Ничего плохого не вижу в переводе некоторых терминов, особенно если для них еще нет устоявшейся терминологии в русском языке: ни заимствованной ни русской. Вы просто привыкли читать про них в англоязычной документации, но это не значит что в русскоязычной их нужно писать по-английски.
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, uzhas, Вы писали:
U>>это не перевод. это отсутствие перевода
U>с одной стороны книга на русском. с другой, примеры кода — на языке оригинала — на английском (мы не про 1С)
Здравствуйте, netch80, Вы писали:
N>Да, "спроецировать" очень хорошо подходит (хотя длиннее )
Мне больше нравится "отобразить"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
LVV>>Я вот на своем ноуте проверил умножение матриц. Относительно небольшие 1000 на 1000 LVV>>Циклы вложены в порядке ijk (стандартный порядок), и замеряется время. LVV>>А потом порядок циклов просто меняем местами: JKI, KJI и т.п. LVV>>И в некоторых вариантах время уменьшается до 10 раз. C>Это как раз не удивительно, с этого обычно начинаются книжки по вычислительной линейке. C>А если по науке сделать, блоками 32*32, во сколько раз ускорится?
Ещё можно попробовать псевдослучайный доступ, в духе A[(i*2017)&1023]. Для параллельных вычислений можно интерлейсить данные: thread0_a0_0, thread1_a0_0. Или воткнуть как бы ненужные синхронизации потоков. Шаманство, никогда не угадаешь, что же именно сработает
Здравствуйте, andyp, Вы писали:
A>Можно. Слезно попросить, чтоб хотя бы tuple пощадил — а то появится в русском какой-нибудь тапл или тупл.
Чем плох "кортеж"?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, disputANT, Вы писали:
ANT>Как только вы переведете и издадите пару книг, в которых будут ВАШИ термины, ваше мнение станет существенно весомее
Я не знаю, как на других форумах, но тут этот человек тут авторитет заработал, в отличие от тебя. И я не про оценки и рейтинг, а про содержание постов.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Erop, Вы писали:
A>>Можно. Слезно попросить, чтоб хотя бы tuple пощадил — а то появится в русском какой-нибудь тапл или тупл.
E>Чем плох "кортеж"?
Кортеж в области БД хорош, он там давно прижился. А в ЯП как-то тупля привычнее. Ну, или "структура". Имхо, конечно
Здравствуйте, netch80, Вы писали:
N>С картинкой, как я уточнял для cures@, годится? Тут всё равно сложно что-то адекватное подобрать. Калька ("тупоконечный"/etc.) — не решение, а капитуляция.
Понятно, что капитуляция. Лучше уж английские термины.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Erop, Вы писали:
M>>Кортеж в области БД хорош, он там давно прижился. А в ЯП как-то тупля привычнее. Ну, или "структура". Имхо, конечно
E>Вроде как в русскоязычной лит-ре "тупля" уже лет 50 называется кортежем...
Ну, по моим ощущениям ситуация такая: области ИТ, под которые давно подводили научное обоснование — типа теории баз данных, переводились примерно в те же времена, и термины тогда тоже переводились, а не транслитерировались. Отсюда по моей теории "кортеж" в применении к базам данных довольно органичен. А тупля — она поновее, из времен уже хотя бы C/C++, уже терминологию не всегда переводили.
ЗЫ Я вот вообще тока и узнал, что тупля — это и есть кортеж. Не сегодня от тебя, но вчера в гугл-транслейте глянул ради интереса
Здравствуйте, Marty, Вы писали:
M>Ну, по моим ощущениям ситуация такая: области ИТ, под которые давно подводили научное обоснование — типа теории баз данных, переводились примерно в те же времена, и термины тогда тоже переводились, а не транслитерировались. Отсюда по моей теории "кортеж" в применении к базам данных довольно органичен. А тупля — она поновее, из времен уже хотя бы C/C++, уже терминологию не всегда переводили.
В типах данных н етак много нового с тех времён появилось. Кортежи изобрели давно
M>ЗЫ Я вот вообще тока и узнал, что тупля — это и есть кортеж. Не сегодня от тебя, но вчера в гугл-транслейте глянул ради интереса
А что стек -- это магазин?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Чем плох "кортеж"?
Да ничем. Мне в соседней ветке на него указали как на устоявшийся перевод. Но, как писал уже:
1. Есть класс tuple стандартной библиотеки, так что читателю не нужно будет соображать , что он и есть воплощение того самого кортежа, про который он раньше читал.
2. Начинающему читателю все равно придется столкнуться с английским — это язык техники и науки сейчас, так что лучше уж привыкать к английским терминам сразу. Так легче будет расширять горизонты и понимать коллег из других стран.
Здравствуйте, andyp, Вы писали:
A>1. Есть класс tuple стандартной библиотеки, так что читателю не нужно будет соображать , что он и есть воплощение того самого кортежа, про который он раньше читал.
Ну если код базируется на английском, то там слово "кортеж" не нужно. А если на русском, то можно typedef сделать или ещё что.
A>2. Начинающему читателю все равно придется столкнуться с английским — это язык техники и науки сейчас, так что лучше уж привыкать к английским терминам сразу. Так легче будет расширять горизонты и понимать коллег из других стран.
Ну с терминами read write ты же как-то миришься?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, andyp, Вы писали:
E>Ну если код базируется на английском, то там слово "кортеж" не нужно. А если на русском, то можно typedef сделать или ещё что.
Можно, но я так не делаю.
E> Ну с терминами read write ты же как-то миришься?
Ты имеешь в виду, что я мирюсь с тем, что эти слова переводят на русский в переводных книжках? Ну да, мирюсь. Книжка станет менее понятной, если эти слова без перевода оставить. С tuple, как по мне, книжка будет более понятной и полезной без перевода этого слова (ну кроме того места, где это понятие вводится).
Здравствуйте, Erop, Вы писали:
M>>Ну, по моим ощущениям ситуация такая: области ИТ, под которые давно подводили научное обоснование — типа теории баз данных, переводились примерно в те же времена, и термины тогда тоже переводились, а не транслитерировались. Отсюда по моей теории "кортеж" в применении к базам данных довольно органичен. А тупля — она поновее, из времен уже хотя бы C/C++, уже терминологию не всегда переводили.
E>В типах данных н етак много нового с тех времён появилось. Кортежи изобрели давно
Ну, своё видение этого терминологического вопроса я описал. Кортежи изобрели давно. Тупли — позже. Еще вопросы?
M>>ЗЫ Я вот вообще тока и узнал, что тупля — это и есть кортеж. Не сегодня от тебя, но вчера в гугл-транслейте глянул ради интереса
E>А что стек -- это магазин?..
Стек я изучал на Z80 по англоязычным описаниям и мутным переводам. А про "магазины" и автоматы с "магазинной памятью" рассказывали уже в институте. Магазин — неудачное слово, имеющее слишком много смыслов: магазин (булочная, молочный), магазин патронов (для ППШ тоже вроде магазин — но там точно стек?)
Здравствуйте, Marty, Вы писали:
M>Ну, своё видение этого терминологического вопроса я описал. Кортежи изобрели давно. Тупли — позже. Еще вопросы?
"Тупли" тут про авторов или про структуру?
Если про структуру, то чем "тупля" (или "тупль?) от кортежей отличаются? Индексируемая коллекция данных разных типов жеж?
Просто в С++ раньше такое тока раком впихивалось, но языков-то было и есть много разных. Скажем LISP состоит из кортежей чуть менее, чем полностью уже 59 лет (в 2018 60 лет старичку будет, ЕМНИП), Linda тупо на такой модели памяти весть построен и т. д...
E>>А что стек -- это магазин?..
M>Стек я изучал на Z80 по англоязычным описаниям и мутным переводам. А про "магазины" и автоматы с "магазинной памятью" рассказывали уже в институте. Магазин — неудачное слово, имеющее слишком много смыслов:
Stack -- тоже слово многозначное. Основное значение -- что-то среднее между стогом сена и поленницей дров.
Да и русское "стек" может означать палку, которой лошадь лупят.
M>магазин патронов (для ППШ тоже вроде магазин — но там точно стек?)
Ну у ППШ точно, просто в бараний рог загнутый
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Marty, Вы писали:
M>>>Ну, по моим ощущениям ситуация такая: области ИТ, под которые давно подводили научное обоснование — типа теории баз данных, переводились примерно в те же времена, и термины тогда тоже переводились, а не транслитерировались. Отсюда по моей теории "кортеж" в применении к базам данных довольно органичен. А тупля — она поновее, из времен уже хотя бы C/C++, уже терминологию не всегда переводили.
E>>В типах данных н етак много нового с тех времён появилось. Кортежи изобрели давно
M>Ну, своё видение этого терминологического вопроса я описал. Кортежи изобрели давно. Тупли — позже. Еще вопросы?
Да. В чём ты видишь настолько принципиальную разницу, чтобы разделять термины?
Здравствуйте, Erop, Вы писали:
E>Просто в С++ раньше такое тока раком впихивалось, но языков-то было и есть много разных. Скажем LISP состоит из кортежей чуть менее, чем полностью уже 59 лет (в 2018 60 лет старичку будет, ЕМНИП), Linda тупо на такой модели памяти весть построен и т. д...
В LISP — списки, а не кортежи. И чисто формально, и практически (кортеж неограничиваемой длины это что-то мифическое, а вот для списков это родное свойство).
В других языках (как в Python, Erlang) аналогичное разделение (хотя есть явная конверсия между ними).
Здравствуйте, netch80, Вы писали:
N>В LISP — списки, а не кортежи. И чисто формально, и практически (кортеж неограничиваемой длины это что-то мифическое, а вот для списков это родное свойство).
В лиспе от рождения была библиотека со списками ограниченной длины — он же кортежи.
N>В других языках (как в Python, Erlang) аналогичное разделение (хотя есть явная конверсия между ними).
Это всё относительно новое. Кортежи в структурах данных уже лет 50 уверено живут.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ты пишешь код с русскими идентификаторами?
Нет, только с русскими комментариями, когда для русских заказчиков. Да и то часто зачем-то на английский съезжаю. Видно, раскладку лень переключать. Но это уж мой недостаток, наверное.
E>Вот есть функция WriteTupleToDst E>Почему в описании её работы слово write переводить на русский надо, а слово tuple нет?
Да я как-то не про код, а про текст в книжках говорил. В коде, который в книжке, вполне можно перевести/добавить комментариев, чтобы читателю было удобнее читать. Переводить идентификаторы смысла нет — достаточно пояснить, что они значат в комментарии рядом.
M>>>>Ну, по моим ощущениям ситуация такая: области ИТ, под которые давно подводили научное обоснование — типа теории баз данных, переводились примерно в те же времена, и термины тогда тоже переводились, а не транслитерировались. Отсюда по моей теории "кортеж" в применении к базам данных довольно органичен. А тупля — она поновее, из времен уже хотя бы C/C++, уже терминологию не всегда переводили.
E>>>В типах данных н етак много нового с тех времён появилось. Кортежи изобрели давно
M>>Ну, своё видение этого терминологического вопроса я описал. Кортежи изобрели давно. Тупли — позже. Еще вопросы?
N>Да. В чём ты видишь настолько принципиальную разницу, чтобы разделять термины?
Принципиальной разницы нет, сугубо мое ощущение. Я писал же, не?
Здравствуйте, andyp, Вы писали:
E>>Вот есть функция WriteTupleToDst
A>Переводить идентификаторы смысла нет — достаточно пояснить, что они значат в комментарии рядом.
Насколько я тебя понял, ты считаешь, что в комментарии рядом или в книжке, в рассказе про функцию WriteTupleToDst надо написать
// Записать туплю в...
а не
// Записать кортеж в...
Если я понял верно, то можешь объяснить почему ты так считаешь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, andyp, Вы писали:
A>Я считаю, что в тексте, где первый раз встретится tuple нужно написать, что это такое. A>В комментарии же писать A>
// Записать tuple в...
Почему не
// write tuple в...
?
Ну а первый раз, где встретишь write — перевести в сноске?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
? E>Ну а первый раз, где встретишь write — перевести в сноске?
Ну это ж все-таки не учебник по английскому. Не стоит все слова пытаться переводить, а вот познакомить начинающего читателя с англоязычными терминами из предметной области — стоящая задача имхо. Разумеется, у этого подхода при переводе, как и у любого другого, есть свои недостатки. Тут уж чувство меры и талант переводчика только помочь могут.
? E>>Ну а первый раз, где встретишь write — перевести в сноске?
A>Ну это ж все-таки не учебник по английскому. Не стоит все слова пытаться переводить, а вот познакомить начинающего читателя с англоязычными терминами из предметной области — стоящая задача имхо.
Я так и не понял, как ты собираешься решать, какие слова надо переводить, а какие нет.
Я уже не говорю, что использовать английские слова в русской речи неудобно.
"Эти два кортежа в этом алгоритме самые важные" как надо писать в твоей стиллистике?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
— а то появится в русском какой-нибудь тапл или тупл.
