Тут речь о том, что когда внутри цикла много i и j, они имеют тенденцию визуально сливаться и перепутать можно достаточно легко, а чтобы найти ошибку потребуется "читать по слогам".
Не нравится n - пусть будет k. Главное, чтобы начертание отличалось от i.
Есть много же тестов, когда длинная фраза и в ней одно слово с опечаткой. Так вот большинство людей опечатку не замечает, а чтобы найти ее требуется усилие. Так устроено восприятие - знакомые слова воспринимаются на уровне готовых образов, причем, не по точному совпадению, а в некоторой степени подобия.
Так и в коде - когда использующиеся совместно переменные визуально сильно отличаются друг от друга, код читается легче чем когда они все друг на друга визуально похожи.
Тут еще надо учитывать особенности восприятия слов человеческим мозгом. Часто встречаю имена переменных типа
dsYPS01LFk - структура ключевых полей индекса YPS01LF
dsYPS01LFi - структура записи индекса YPS01LF используемая для чтения
dsYPS01LFo - структура записи индекса YPS01LF используемая для записи
И вот когда все это активно используется и на станице штук 10 этих переменных, то при беглом просмотре в глазах рябит и сложно видеть различия в длинных именах когда вся разница в одной последней букве.
Т.е. переменные должны чисто визуально хорошо отличаться.
Даже во вложенных циклах
for (i = 0; i < 10; i++) {
for (j = i; j < 10; j++) {
...
}
}
читается хуже чем
for (i = 0; i < 10; i++) {
for (n = i; n < 10; n++) {
...
}
}
потому что визуально i и j схожи, а i и n отличаются по начертанию.
Есть ситуации, когда условий много, и всех их надо соблюсти. Тут подойдёт любой вариант, который будет либо читаем, либо задокументирован правильно. А лесенкой или не лесенкой, это уже на выбор автора.
Да, и при этом еще может быть много ветвлений - Если соблюдены условия A, B, C - одна ветка, если A, B, D - другая, если A, C, D - третья... И так далее.
Множественные выходы тоже хорошо и красиво только в синтетических примерах. А в реальной практике отсутствие единой точки выхода может привнести немало проблем (как минимум, неудобств).
Хорошо, если язык поддерживает блоки on-exit куда обязательно попадаешь при любом (в т.ч. и аварийном) выходе. А если нет?
Правда, там (тут) ситуация специфическая - стек на центральных серверах очень необычный, готовых разработчиков почти не найти. Поэтому берут любых (желательно с опытом разработки на чем-нибудь) и первые три месяца интенсивно обучают. Вот это был очень тяжелый период как помню.
На самом дел, последние 8 лет работаю в ОС где "все есть объект". У объекта есть имя, тип, атрибут (подтип), описание и еще ряд свойств.
Система позволяет делать с объектом только то, что позволено для данного типа. Например, открыть программу в HEX редакторе и поправить пару байтиков вы не сможете - операция изменения для объекта типа *PGM не определена. А поменять тип существующего объекта невозможно.
На низком уровне можно получить "системный указатель на объект" и потом уже с ним работать (в частности, получить всю информацию об объекте - "материализация системного указателя" - имя, тип и т.п.).
По моему, тут нельзя говорить о "Российских ОС". Это не более чем "Российские дистрибутивы Linux". Сильно сомневаюсь, что там есть какие-то модификации собственно ядра.
В составе ОС уже есть PostgreSQL 16 и nginx 1.26
Оно просто включено в состав дистрибутива, или реально является частью ОС (как, например, DB2 for i является частью ОС IBM i)?
Ну там еще были распечатки досовских прерываний, как помню... Хотя не всех. Описания прерывания RTC (номер не помню, оно 1024 раза в секунду "тикало") я так нигде и не нашел тогда. Пришлось методом тыка доходить до того, что оно однократное - флаг разрешения прерывания там сбрасывался автоматически и нужно было его каждый раз в обработчике выставлять заново если хочешь чтобы оно в очередной раз "тикнуло".
Ну если смотреть исторически, то английский содержит много латинских корней. Там некая смесь кельтских языков и латыни (последствия присутствия римской империи на британских островах).
Так что это не совсем германский язык, а некая смесь.
Смотря какой формат. Если деловые переговоры на серьезном уровне где речь о больших деньгах, то нанимают даже зная язык. Причем, там еще каждый своего - свой переводчик переводит на язык своего заказчика.
Ну жена за заказами уже не гонится, занимается этим больше для удовольствия, а не ради денег (это не основная ее деятельность). Так что ту эмоции только оттого, что приносят "мы тут ИИ перевели, статью не приняли, поправь пожалуйста". И эмоции не положительные т.к. править там нечего, нужно все делать заново (то, что она переводит проходит без проблем в любые рейтинговые журналы).
И речь не о том, что описывается новое - это слишком узкий подход. Речь о том, способен человек понять вообще о чем речь или нет. И правильно передать смысл (а не просто переписать английскими буквами русскую статью) с учетом принятой терминологии. А иногда еще и "с автором работать" приходится на тему - "что вот тут имелось ввиду".
Вот вы говорите что переводите статьи по спектрометрии. И, видимо, в этой спектрометрии что-то понимаете. Терминологию, принципы как это работает.
А теперь представьте что вам дали статью в области, где не понимаете вообще ничего. Ну, скажем, какая-нибудь палеонтология. Или медицина какая-то специфическая. Или фармакология... Вряд ли вы сможете ее качественно перевести без подготовки. Невозможно качественно перевести текст, не понимая его смысла.
А вот в технических статьях, а уж тем более в юридических документах - только руками.
Хорошие технические переводчики получаются из людей с высшим техническим образованием. Способных понять что именно они переводят.
Жена вот берет переводы только по физике или химии (образование соответствующее) или связанные с интеллектуальной собственностью и патентным правом (большой опыт работы не переводчиком в этой области - тут надо понимать особенности нашего и не нашего законодательства в этой области). И никогда не берет математику, биологию, медицину или общую юриспруденцию.
Речь о переводе научной статьи с русского на английский для публикации в англоязычном журнале. А там ее вычитывают редакторы и могут просто завернуть если плохо переведено. Так вот что переведено ИИ обычно заворачивают.
Речь не о переводе "для себя", речь о переводе для публикации в рейтинговых журналах. А там достаточно жесткие правила к качеству перевода.
Ну и английский-испанский относятся к одной группе языков. Там проще немного в плане терминологии и языковых конструкций. Русский и английский очень сильно отличаются структурно (если можно так выразится). Там слово-в-слово не перевести. Совершенно разные строения фразы. Плюс русская терминология в той же оргхимии (оргсинтез), к примеру, может сильно отличаться от западной.
Рассчитывать на то, что в идеальном мире всегда будет хотя бы интернет, в свете недавних событий немного глупо - очебурашится российский интернет, и некоторые вещи даже будет негде спросить.
Не поверите, но когда "вкатывался в IT" в 89-90гг, именно так все и было. Никакого интернета, никакого гугла и ничего такого не было.
Одной из первых задач была написать программу управления настенным табло. Которое купили где-то "срук", без никакой документации, только демо программка к нему.
Цеплялось оно к COM порту. Пришлось заниматься реверс-инжинирингом - гонять демку под QA (Quaid Analyzer) и сопоставлять - что выводим в демке, что она пишет в порт, что появляется на табло и т.п. Благо там протокол примитивный оказался, сильно много времени не заняло.
И в целом такого, что приходилось постигать методом "а если сделать вот так, что будет?" было предостаточно.
Ну, "вайб-переводчики" уже есть. Жена профессионально много лет занимается техническим переводом. И в какой-то момент количество заказов упало - все стали говорить "а мы переведем с помощью ИИ". А в последнее время появились заказы типа "мы перевели с помощью ИИ, статью не приняли в журнал, сказали что какая-то бессмыслица, поправь пожалуйста".
И начинается - попытка поправить что-то локальное приводит к тому, что разваливается вообще все. Статья становится похожей на коллективное письмо из Простоквашино - абсолютно непонятно "кто на ком стоял". Т.е. просто русская статья переписанная английскими буквами.
И надо просто все выкидывать и переводить заново (с кодом, кстати, бывают похожие ситуации - приходит что-то на доработку, смотришь, и понимаешь, что просто доработать тут не получится - нужно все переписывать заново иначе получишь дикое количество костылей).
Переводчик переводит не слова и не фразы. Он переводит смысл. Т.е. надо прочитать и понять о чем речь на исходном языке и сформулировать все это на целевом. А в техническом переводе еще терминологию выдержать, которая на разных языках в разных областях может отличаться.
Уже записанный трек обрабатывать проще т.к. там уже есть все данные от начала и до конца.
Насчет ФК в чипах не сильно уверен что там он достатчоно сильный. Там же принцип фактически тот же самый, что в тривиальном ФНЧ, разница только в том, что коэффициент фильтрации (сглаживания) постоянно корректируется.
Тут речь о том, что когда внутри цикла много i и j, они имеют тенденцию визуально сливаться и перепутать можно достаточно легко, а чтобы найти ошибку потребуется "читать по слогам".
Не нравится n - пусть будет k. Главное, чтобы начертание отличалось от i.
Есть много же тестов, когда длинная фраза и в ней одно слово с опечаткой. Так вот большинство людей опечатку не замечает, а чтобы найти ее требуется усилие. Так устроено восприятие - знакомые слова воспринимаются на уровне готовых образов, причем, не по точному совпадению, а в некоторой степени подобия.
Так и в коде - когда использующиеся совместно переменные визуально сильно отличаются друг от друга, код читается легче чем когда они все друг на друга визуально похожи.
Тут еще надо учитывать особенности восприятия слов человеческим мозгом. Часто встречаю имена переменных типа
dsYPS01LFk - структура ключевых полей индекса YPS01LF
dsYPS01LFi - структура записи индекса YPS01LF используемая для чтения
dsYPS01LFo - структура записи индекса YPS01LF используемая для записи
И вот когда все это активно используется и на станице штук 10 этих переменных, то при беглом просмотре в глазах рябит и сложно видеть различия в длинных именах когда вся разница в одной последней букве.
Т.е. переменные должны чисто визуально хорошо отличаться.
Даже во вложенных циклах
читается хуже чем
потому что визуально i и j схожи, а i и n отличаются по начертанию.
Да, и при этом еще может быть много ветвлений - Если соблюдены условия A, B, C - одна ветка, если A, B, D - другая, если A, C, D - третья... И так далее.
Множественные выходы тоже хорошо и красиво только в синтетических примерах. А в реальной практике отсутствие единой точки выхода может привнести немало проблем (как минимум, неудобств).
Хорошо, если язык поддерживает блоки on-exit куда обязательно попадаешь при любом (в т.ч. и аварийном) выходе. А если нет?
Правда, там (тут) ситуация специфическая - стек на центральных серверах очень необычный, готовых разработчиков почти не найти. Поэтому берут любых (желательно с опытом разработки на чем-нибудь) и первые три месяца интенсивно обучают. Вот это был очень тяжелый период как помню.
Почему?
У меня был опыт более 20-ти лет в области, непосредственно связанной с промавтоматизацией.
Последние 8 лет - банк, АБС на центральных серверах.
Да, поначалу тяжело было (там много чего разом наложилось). Но вывез. И большой опыт в разработке (в широком смысле) весьма пригодился.
И да, на момент перехода мне было 52 годика от роду.
На самом дел, последние 8 лет работаю в ОС где "все есть объект". У объекта есть имя, тип, атрибут (подтип), описание и еще ряд свойств.
Система позволяет делать с объектом только то, что позволено для данного типа. Например, открыть программу в HEX редакторе и поправить пару байтиков вы не сможете - операция изменения для объекта типа *PGM не определена. А поменять тип существующего объекта невозможно.
На низком уровне можно получить "системный указатель на объект" и потом уже с ним работать (в частности, получить всю информацию об объекте - "материализация системного указателя" - имя, тип и т.п.).
По моему, тут нельзя говорить о "Российских ОС". Это не более чем "Российские дистрибутивы Linux". Сильно сомневаюсь, что там есть какие-то модификации собственно ядра.
Оно просто включено в состав дистрибутива, или реально является частью ОС (как, например, DB2 for i является частью ОС IBM i)?
Тоже начинал с него, но перевод не помню уже. Это был 1989-90гг.
Дальше уже, конечно были более серьезные книги, но легко вникнуть в основные понятия и концепции языка помогла именно книга Прата.
Ну там еще были распечатки досовских прерываний, как помню... Хотя не всех. Описания прерывания RTC (номер не помню, оно 1024 раза в секунду "тикало") я так нигде и не нашел тогда. Пришлось методом тыка доходить до того, что оно однократное - флаг разрешения прерывания там сбрасывался автоматически и нужно было его каждый раз в обработчике выставлять заново если хочешь чтобы оно в очередной раз "тикнуло".
Но допер и что-то на нем делал даже...
Ну если смотреть исторически, то английский содержит много латинских корней. Там некая смесь кельтских языков и латыни (последствия присутствия римской империи на британских островах).
Так что это не совсем германский язык, а некая смесь.
Смотря какой формат. Если деловые переговоры на серьезном уровне где речь о больших деньгах, то нанимают даже зная язык. Причем, там еще каждый своего - свой переводчик переводит на язык своего заказчика.
Ну жена за заказами уже не гонится, занимается этим больше для удовольствия, а не ради денег (это не основная ее деятельность). Так что ту эмоции только оттого, что приносят "мы тут ИИ перевели, статью не приняли, поправь пожалуйста". И эмоции не положительные т.к. править там нечего, нужно все делать заново (то, что она переводит проходит без проблем в любые рейтинговые журналы).
И речь не о том, что описывается новое - это слишком узкий подход. Речь о том, способен человек понять вообще о чем речь или нет. И правильно передать смысл (а не просто переписать английскими буквами русскую статью) с учетом принятой терминологии. А иногда еще и "с автором работать" приходится на тему - "что вот тут имелось ввиду".
Вот вы говорите что переводите статьи по спектрометрии. И, видимо, в этой спектрометрии что-то понимаете. Терминологию, принципы как это работает.
А теперь представьте что вам дали статью в области, где не понимаете вообще ничего. Ну, скажем, какая-нибудь палеонтология. Или медицина какая-то специфическая. Или фармакология... Вряд ли вы сможете ее качественно перевести без подготовки. Невозможно качественно перевести текст, не понимая его смысла.
Германо-романские языки – это группа языков, включающая германские и романские языки.
Западногерманские:
Английский, немецкий, нидерландский (голландский), африкаанс, фризский, идиш.
Иберо-романские:
Испанский, португальский, каталанский, галисийский, арагонский, астурийский, сефардский.
Ну чтобы вдумчиво копировать, надо быть в теме глубже, что тот же SO или LLM :-)
Для понимания и гуглоперевода достаточно было.
А вот в технических статьях, а уж тем более в юридических документах - только руками.
Хорошие технические переводчики получаются из людей с высшим техническим образованием. Способных понять что именно они переводят.
Жена вот берет переводы только по физике или химии (образование соответствующее) или связанные с интеллектуальной собственностью и патентным правом (большой опыт работы не переводчиком в этой области - тут надо понимать особенности нашего и не нашего законодательства в этой области). И никогда не берет математику, биологию, медицину или общую юриспруденцию.
Пытались, но там вообще не было шансов.
Речь о переводе научной статьи с русского на английский для публикации в англоязычном журнале. А там ее вычитывают редакторы и могут просто завернуть если плохо переведено. Так вот что переведено ИИ обычно заворачивают.
Речь не о переводе "для себя", речь о переводе для публикации в рейтинговых журналах. А там достаточно жесткие правила к качеству перевода.
Ну и английский-испанский относятся к одной группе языков. Там проще немного в плане терминологии и языковых конструкций. Русский и английский очень сильно отличаются структурно (если можно так выразится). Там слово-в-слово не перевести. Совершенно разные строения фразы. Плюс русская терминология в той же оргхимии (оргсинтез), к примеру, может сильно отличаться от западной.
Не поверите, но когда "вкатывался в IT" в 89-90гг, именно так все и было. Никакого интернета, никакого гугла и ничего такого не было.
Одной из первых задач была написать программу управления настенным табло. Которое купили где-то "срук", без никакой документации, только демо программка к нему.
Цеплялось оно к COM порту. Пришлось заниматься реверс-инжинирингом - гонять демку под QA (Quaid Analyzer) и сопоставлять - что выводим в демке, что она пишет в порт, что появляется на табло и т.п. Благо там протокол примитивный оказался, сильно много времени не заняло.
И в целом такого, что приходилось постигать методом "а если сделать вот так, что будет?" было предостаточно.
Ну, "вайб-переводчики" уже есть. Жена профессионально много лет занимается техническим переводом. И в какой-то момент количество заказов упало - все стали говорить "а мы переведем с помощью ИИ". А в последнее время появились заказы типа "мы перевели с помощью ИИ, статью не приняли в журнал, сказали что какая-то бессмыслица, поправь пожалуйста".
И начинается - попытка поправить что-то локальное приводит к тому, что разваливается вообще все. Статья становится похожей на коллективное письмо из Простоквашино - абсолютно непонятно "кто на ком стоял". Т.е. просто русская статья переписанная английскими буквами.
И надо просто все выкидывать и переводить заново (с кодом, кстати, бывают похожие ситуации - приходит что-то на доработку, смотришь, и понимаешь, что просто доработать тут не получится - нужно все переписывать заново иначе получишь дикое количество костылей).
Переводчик переводит не слова и не фразы. Он переводит смысл. Т.е. надо прочитать и понять о чем речь на исходном языке и сформулировать все это на целевом. А в техническом переводе еще терминологию выдержать, которая на разных языках в разных областях может отличаться.
Уже записанный трек обрабатывать проще т.к. там уже есть все данные от начала и до конца.
Насчет ФК в чипах не сильно уверен что там он достатчоно сильный. Там же принцип фактически тот же самый, что в тривиальном ФНЧ, разница только в том, что коэффициент фильтрации (сглаживания) постоянно корректируется.