Действительно многоязычные языки программирования?

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

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

Это кажется хорошим местом для начала: Неанглийские языки программирования.

там есть несколько интересных, как Python в переводе на китайский.

вы можете использовать препроцессор C/C++ для переопределения всех ключевых слов - и некоторые люди сделали это. Я столкнулся с этим, когда работал тренером/наставником в норвежской компании. Какая-то яркая искра внедрила aheader, который перевел все ключевые слова C на норвежский язык и заставил его использовать. Норвежский персонал, все из которых отлично говорили по-английски (иначе я не смог бы заработать свою корочку с ними), все ненавидели его, и он умер смертью.

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

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

такие локализованные DSL могут оказаться полезными для программистов, если они имеют дело с большим количеством непереводимых терминов. Один довольно успешный система, с которой я столкнулся, использовалась для расчета заработной платы персонала израильских вооруженных сил. Он использовал синтаксис на иврите вместе с сотнями терминов, которые могут быть правильно выражены только на иврите. В этом конкретном случае стандартные логические ключевые слова if, then, else, etc. были переведены на иврит и весь редактор кода был справа налево. Очень большая часть бизнес-логики поддерживается таким образом по сей день и, ИМХО, справедливо.

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

например, в Java, вы можете создать

public class HoweverYouSayExampleObjectInYourLanguage extends ExampleObjectName {
  }

а затем создайте функции-оболочки / методы с именами на вашем целевом языке, но которые в основном вызывают существующие стандартные методы

private void HoweverYouSayExampleMethodInYourLanguage(parameters) {
      this.ExampleMethod(parameters);
      // Some error handling code
}

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

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

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

вы можете запрограммировать Perl в лат.

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

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

позже (когда я изучаю английский ) я думал.. Эй, это смешно, в английском тоже есть слово" switch", так же, как C. (doh! )

:)

независимо от того, насколько хорош или плох ваш английский, вы не можете сказать java

импорт java.утиль.* в мой CD-ROM;

потому что это недопустимый синтаксис.

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

отсортированный!

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

какие полезные? Это лучший вопрос.

в значительной степени вы можете программировать в prolog в любом сценарии unicode (потому что это символический язык). Во всех компиляторах prolog, с которыми вы, вероятно, столкнетесь, есть (крошечные, маленькие) переменные catch, обозначенные начальной заглавной буквой, и вам придется переопределить встроенные модули (но prolog делает это относительно легко*).

Я думаю, что пример проиллюстрирует, что я имею в виду лучшие:

% алгоритм поиска дат Пасхи, заданного года (как первый аргумент)

復活節( V1, V2, V3) :-
   A 是 (V1 mod 19),
   B 是 V1// 100,
   C 是 V1 mod 100,
   D 是 B // 4,
   E 是 B mod  4,
   F 是 (B + 8) // 25,
   G 是 (B - F + 1) // 3,
   H 是 (19*A + B - D - G + 15 )mod 30,
   I 是 C // 4,
   J 是 C mod  4,
   K 是 (32 + 2*E + 2*I - H - J) mod  7 ,
   L 是 (A + 11*H + 22*K) // 451,
   M 是 (H + K - 7*L + 114) // 31,
   N 是 (H + K - 7*L + 114)mod  31,
   V2 是 M,
   V3 是 N + 1.

/*

пример:

?- 復活節 (2013, V2 , V3). V2 = 3 , V3 = 31

т. е. Пасха в этом году будет 31 марта

*/

• это то, что я использовал для переопределения сборки в операторе " is " (Не стреляйте в меня, если он несовершенен):

  : - op(500, xfy,).

  (X,Y):-is(X,Y).