Кодирование на других (разговорных) языках

У меня возникли проблемы с поиском ссылок, но я напомнил о трех историях.

хакер Lisp защищает бессмысленные функции, такие как" cdr "и" car", сравнивая их с программированием на вашем неродном языке: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01171.html

когда Юкихиро Мацумото ("Matz") начал разрабатывать Ruby, он использовал английские ключевые слова хотя он писал всю документацию на японском языке!. В течение нескольких лет у Руби не было английской документации, и очень немногие американцы использовали этот язык. Но сейчас это язык мирового класса, и тот факт, что он родился в Японии, представляет только исторический интерес. Если бы язык использовал ключевые слова в хирагане, ему было бы гораздо труднее завоевать популярность.

Я читал эссе один раз-может быть, кто-то еще может найти его, Google сегодня не помогает - это предположило, что перевод ключевых слов был ошибочным, потому что эти слова на самом деле не английские-это жаргон. Не только сделать (чтобы использовать примеры выше) para и залить не совсем имеют точное значение, что на имеет на английском языке, для не-программистов фраза "for loop" является jibberish. Даже американцы должны научиться новому смыслу. Таким образом, перевод поверхностного значения слов на другой язык больше похож на кросс-языковой каламбур, а не на то, чтобы быть полезным.

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

используя только операторы языка на японском языке с переменными на английском языке:

// In Japanese, it makes more sense to put the keywords/modifiers as
// postfix expressions rather than prefix expressions.
(i < size)か {
     (l[i])は {
     1だ:
         「もしもし。」を書く;
     省略時値:
         「いいえ、いいですよ。」を書く;
     }
} ない {
     「はい、ありがとうございます。」を書く;
}

в языке Java некоторые методы должны быть названы (по крайней мере частично) с использованием английского языка из-за соглашения JavaBeans.

это соглашение требует, чтобы свойство X было установлено с помощью пары методов getX() и setX (). Здесь, во Франции-Канаде, где некоторые разработчики обязаны кодировать на французском языке, это приводит к следующей пародии:

interface Foo {

  Color getCouleur();

  void setCouleur(Color couleur);
}

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

Я помню, что кто-то однажды дал мне короткий фрагмент Actionscript, взятый из какого-то блога. Имена были на немецком языке, и так как я не говорю ни слова об этом язык, вещи могли бы называться var_123, var_562 или func_333, а также (и, вероятно, мне было бы легче запомнить имена или, по крайней мере, иметь возможность правильно их писать без копирования и вставки). Поскольку это был короткий, самодостаточный фрагмент, я использовал онлайн-переводчик, чтобы дать этим vars и функциям значимые имена на моем родном языке (испанский), и после этого все было ясно. Дело в том, что код был на самом деле прост, но я смог только сделать смысл из него без слишком больших (ненужных) дополнительных усилий только тогда, когда я преодолел языковой барьер.

с тех пор я перешел на использование английского языка для именования идентификаторов. Нравится вам это или нет, это" koine " для программирования, инженерных и вообще технических вещей. Большинство API написаны на английском языке, и поэтому большинство документации (и, вероятно, лучшие ресурсы, которые вы можете найти, также находятся на английском языке). Как приятно в стороне, он держит ваш код более согласованным с кодом вы, вероятно, будете взаимодействовать, и я думаю, что он имеет тенденцию быть более компактным и кратким, чем другие языки, такие как испанский (который в противном случае был бы моим естественным выбором).

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

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

Так что да, если все хорошо, вы сможете прочитать код.

однако такие языки, как Java и Perl, позволяют полный набор Unicode для идентификаторов, поэтому, если кто-то пишет имена своих классов в Кандзи, у вас, вероятно, возникнут проблемы.

Обновление: Для Perl там есть модуль шутка что позволяет писать Perl на латыни. Но на самом деле это просто шутка. Никто не использует такие вещи всерьез.

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

на самом деле есть are некоторые Неанглийские языки программирования (Wikipedia)

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

Я британец, и проблема, с которой мы часто сталкиваемся, - это американское/британское орфографическое столкновение. Это часто происходит с терминами, связанными с программированием, такими как Initialise() или Initialize (), Analyse() или Analyze() и т. д. Это может (имеет) привести к проблемам, пытаясь переопределить методы, и иногда трудно обнаружить.

У нас есть смесь национальностей в наших командах разработчиков, и большинство небританских людей склоняются к американскому написанию естественно.

AppleScript когда-то был доступен на французском и японском диалектах. Я не знаю, почему он был снят.

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

после просмотра таких языков, как Brainf* * k и пробел Я думал о создании такого языка: он был бы идентичен C, за исключением того, что вы используете закрывающие фигурные скобки для открытия, открывающие фигурные скобки для закрытия, меняют значения + и -, * И/,; И:, > И

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

int foo)int i, char c( }
    int six = 2 / 3:
    int two = six + 4:
    if )i > 0( }
        printf)"i is negative"(:
    {
{

Я работаю во французской команде, разрабатывающей программную систему на C#. Несмотря на то, что ключевые слова языка программирования якобы являются английскими, я полагаю, что вам будет очень трудно прочитать код, поскольку все имена функций, переменные, комментарии к коду, таблицы и столбцы базы данных, технические характеристики, протоколы и т. д., Все на французском языке, включая эти прекрасные акцентированные символы ç, é, è, ù и т. д. Я даже не уверен, будет ли система работать в другом месте из-за ошибки локализации, такие как использование запятой в качестве десятичного разделителя по умолчанию.

в противном случае, WinDev является популярной платформой программирования во Франции, и его язык программирования WLanguage имеет ключевые слова на французском или английском языках, см. и пример здесь : текст ссылки

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

PD: мне кажется, что испанский язык намного лучше английского; но переводить неправильно

Ну, как указывали другие, ключевые слова и системные вызовы, скорее всего, останутся на английском языке.

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

Edit: Я просто вспомнил свою молодость, когда я пошел в таблицы отображения моего TRS-80 встроенного BASIC, чтобы переключить ключевые слова на французский язык. Я мог бы измениться все ключевые слова, но я не смог сделать ни одного из них больше. Сделано для смешных программ.

Не смейся над этим. Несколько лет назад Microsoft анонсировала G# (немецкий Sharp) - C# с немецкими ключевыми словами и API. Конечно, это была первоапрельская шутка, но весь сайт об этом выглядел так реально и профессионально (и был на microsoft.com). страшно.

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

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

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

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

только язык Я видел локализованный Excel с его макросами. Если вы пытаетесь суммировать столбец, используя итальянскую версию Office, вы должны написать SOMMA(A1:A10) и не суммировать. Какая жалость.

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

se (i < size){
    commuta
        caso 1:
            stampa "hi there"
        normalmente:
            stampa "no, thank you"
} altrimenti {
    stampa "yes, thank you"
}

есть некоторые языки, которые перевели ключевые слова. Формулы Excel, например. Если вы пишете некоторые вычисления в электронной таблице, это будет на вашем языке.

к счастью, это не общая практика, и даже неанглоязычные, как я, слава Богу, что есть стандартный язык для ключевых слов:

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

а где остановиться ? Можете ли вы представить себе C в древнегреческом языке ?

ключевые слова должны оставаться на одном языке, и это началось с английским, пусть так и останется. Это могло быть хуже всего (Азиатский язык ?). И поэтому мы должны писать методы и комментарии на английском языке. Хорошо, еще работайте на нас, но, по крайней мере, международная кодовая база остается конгруэнтной.

кстати, это будет ваш код с французскими ключевыми словами:

Si (i < taille) {
    cas par cas :
        cas 1:
            afficher "salut"
        défaut:
            afficher "non merci"
} sinon {
    afficher "oui, merci"
}

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

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

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

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

когда я был ребенком, мы ездили во Францию, и в музее, куда мы ходили, я помню, что нашел дисплей, который показал вам, как писать компьютерные программы. Язык был каким-то базовым вариантом, и я отчетливо помню, что он использовал POUR вместо FOR и так далее. Мне было 7 лет, и я только что выучил базовый, и мне казалось совершенно естественным, что у французов будет свой собственный диалект!!

Я думаю, это могло быть LSE что я увидел?

по версии FileMaker языком сценариев является локализованной. Скрипты (и данные!) хранятся в ужасном "сорт каноническом" виде.

Итак, если вы пишете скрипт в американской версии, а затем открываете его во французской версии, все ключевые слова и встроенные имена функций будут на французском языке. Но почему он не работает?! Ага! Французская версия использует ", " в качестве десятичной точки, и поэтому, чтобы избежать двусмысленности использует ";" для разделения аргументов функции-где американская версия использует "." и "," соответственно. Это преобразование вы должны сделать сами.

таким образом, вы работаете через невероятно плохой интерфейс редактирования сценариев (вы не можете писать сценарии в виде текстовых файлов), чтобы исправить все эти вещи. Он бежит! Отлично! Результаты все неверны! О нет! Ага! Дата Jan-7-2004, которую вы ввели в американскую версию, интерпретируется как июль-1-2004 - по-видимому, даты не только отображаются, но и хранящиеся в порядке, зависящем от локали. Я тебя разыгрываю? Нет.

[Примечание: Filemaker 8 и 9 может быть вменяемым -- я только когда - либо работал с 3-7.]

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

конечно, Perl и Perlers отказываются играть по общепринятым правилам. Безумный ученый Дэмиан Конвей написал Lingua::Romana:: Perligata модуль, который использует черную магию исходных фильтров, чтобы позволить вам писать Perl на латыни!

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

было бы бессмысленно, ИМХО, i18n язык синтаксис. Это просто убьет любую переносимость.

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

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

в Италии

se (i < dimensione){
    scegli
        caso 1:
            stampa "ciao"
        mancante:
            stampa "no, grazie"
} altrimenti {
    stampa "sì, grazie"
}

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

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

Я думаю, что WordBasic был локализован. WordBasic использовался для записи макросов в Word до использования VBA.

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