Кодування іншими (розмовними) мовами

Мені це завжди було цікаво, і я не можу знайти жодної згадки про нього в Інтернеті. Коли магазин із, скажімо, Японії, пише код, чи зможу я його прочитати англійською? Або такі мови, як C, PHP, що-небудь, мають японські переклади, які вони пишуть?

Я думаю, що я запитую, чи знає кожен кодер у світі достатньо англійської мови, щоб використовувати ці ж зарезервовані слова, які я роблю?

Чи буде цей код:

If (i < size){
    switch
        case 1:
            print "hi there"
        default:
            print "no, thank you"
} else {
    print "yes, thank you"
}

відобразити так само, як я зараз бачу це англійською мовою, чи хтось інший, хто не говорить англомовним, побачив слова "якщо", "перемикач", "регістр", "за замовчуванням", "друк" та " ще "рідною мовою?

EDIT - так, це серйозно. Я не знав, чи різні локалізації мови мають різні ключові слова. або якщо взагалі існують навіть різні локалізації.

Якщо я добре зрозумів, питання насправді таке: "чи знає кожен кодер у світі достатньо англійської мови, щоб використовувати такі самі зарезервовані слова, як і я?"

Ну .. Англійська мова тут не є предметом, але мова програмування зарезервована словами. Я маю на увазі, коли я почав близько 10 років тому, я не мав жодної гадки про англійську мову, і все-таки я міг програмувати прості речі, вивчаючи мову програмування, навіть коли я не знав, що вони означають (англійською). Власне, це допомогло мені вивчити англійську мову.

Наприклад. Я знаю, щоб зробити "ітерацію" (ітерація, звичайно), мені довелося написати:

 for( i = 0 ; i < 100 ; i++ ) {}

Для мене "за", ";" і "++", де прості іноземні слова чи символи. Пізніше я дізнаюся, що "для" означало "пара" і "в той час" означало "мієнтри" і т. Д., Але тим часом мені не потрібно було знати англійську мову, але в моєму випадку мені потрібно було знати "С".

Звичайно, коли мені потрібно було вивчити більше речей, мені довелося вивчити англійську мову, бо документація написана цією мовою.

Тож відповідь така: Ні, я не бачу, якщо, хоча, і т. Д. Рідною мовою. Я бачу їх англійською мовою, але вони не означали для мене жодної іншої речі, яку вони по черзі мали на увазі для мови програмування.

Це як оператор переключення в bash: case .. esac. Що таке "esac" ... для мене кінець оператора переключення в bash.

Я думаю, що це ми називаємо "абстракцією"

У мові Java деякі методи повинні бути названі (принаймні частково) з використанням англійської мови через конвенцію JavaBeans.

Ця умова вимагає, щоб властивість X була встановлена ​​за допомогою методів getX () та setX (). Тут, у Франції та Канаді, де деякі розробники зобов’язані кодувати французькою мовою, це призводить до наступної травестії:

interface Foo {

  Color getCouleur();

  void setCouleur(Color couleur);
}

У мене виникають проблеми з пошуком посилань, але мені нагадують три історії.

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

Коли Юкіхіро Мацумото ("Мац") почав розробляти Рубі, він використовував англійські ключові слова, хоча він писав всю документацію японською мовою! . Кілька років англійської документації для Рубі не було, і дуже мало американців використовували цю мову. Але зараз це мова світового класу, і той факт, що він народився в Японії, представляє лише історичний інтерес. Якби мова використовувала ключові слова в хірагані, це мало б набагато складніше придбати популярність.

Я прочитав есе одного разу - можливо, хтось ще може його знайти, Google сьогодні не допомагає - це припустило, що переклад ключових слів був помилковим, оскільки слова насправді не є англійською мовою - це жаргон. Мало того, що (використовувати приклади вище) пункт і налити мало мати точне значення , що для має на англійській мові, щоб непрограмістів фрази «цикл» є jibberish. Навіть американцям доводиться вивчати нове значення. Тож перекладати поверхневе значення слів на іншу мову - це скоріше, як зробити переклади на багатомовну мову, а не бути корисною.

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

Використання лише мовних тверджень японською мовою зі змінними англійською мовою:

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

Як вже зазначалося багатьом людям, у більшості мов програмування ви просто повинні вивчити кілька ключових слів, тому це не має великого значення, якщо вони англійською мовою (або іншою мовою, крім вашої). Це просто символ, який ви асоціюєте з якоюсь конструкцією. Наприклад, у VB у вас є "THEN", який у багатьох мовах стилю C був би "{", і це не має великої різниці в читанні (ну, принаймні, так я бачу, будучи неанглійським носій рідної мови).

Але там, де іноді речі можуть бути волохатими, і де вибір (природної) мови має значення в іменуванні ідентифікаторів. Якщо назви змінних, функцій, класів тощо не мають для вас значущого імені через мовний бар'єр, дотримання навіть найпростішого коду може бути досить складним.

Я пам'ятаю, колись хтось дав мені короткий фрагмент Actioncript, узятий із якогось блогу. Назви були німецькою мовою, і оскільки я не розмовляю ні слова цієї мови, речі можна було б назвати також var_123, var_562 або func_333 (і, напевно, мені було б простіше запам'ятати імена або принаймні мати шанс їх правильного написання без копіювання та вставлення). Оскільки це був короткий, автономний фрагмент, я використовував онлайн-перекладач, щоб дати цим варіантам і функціям значущі назви рідною мовою (іспанською), і після цього все було зрозуміло. Справа в тому, що код насправді був простим, але я зміг зрозуміти його без зайвих (зайвих) зайвих зусиль, тільки коли я подолав мовний бар'єр.

З того часу я перейшов на використання англійської мови для іменування ідентифікаторів. Вам подобається чи ні, це "койн" для програмування, інженерії та загалом технічних речей. Більшість API написані англійською мовою, а також більшість документації (і, мабуть, найкращі ресурси, які ви можете знайти, є і англійською мовою). З іншого боку, він зберігає ваш код більш узгодженим з кодом, з яким ви, швидше за все, взаємодієте, і я думаю, що він, як правило, більш компактний і лаконічний, ніж інші мови, такі як іспанська (що інакше було б моїм природним вибором).

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

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

Так що так, якщо все добре, ви зможете прочитати код.

Однак такі мови, як Java та Perl, дозволяють отримати повний набір Unicode для ідентифікаторів, тож якщо хтось записує свої імена класу на канджі, ви, швидше за все, матимете проблеми.

Оновлення: Для Perl є жарт-модуль який дозволяє писати Perl латинською мовою. Але це насправді просто так, жарт. Такі речі ніхто не використовує серйозно.

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

Насправді є декілька мов програмування, що не засновані на англійській мові (Вікіпедія)

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

Я - британець, і проблема, з якою ми часто стикаємося, - це американський / британський правопис зіткнення. Це часто трапляється з термінами, пов'язаними з програмуванням, такими як Initialise () або Initialize (), Analyse () або Analyze () тощо. Це може (призведе) до проблем, що намагаються переосмислити методи, а іноді їх важко помітити.

Оскільки рамки (в нашому випадку C #) були розроблені американцями, ми виявили, що найкраще бути послідовним і використовувати американські написання. Ми навіть приймаємо Color.

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

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

Перейшовши на наступний рівень, що робити з можливістю заміни символів?

Побачивши такі мови, як Brainf ** k та Whitespace, я подумав зробити мову такою: вона буде ідентичною 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 має ключові слова на французькій чи англійській мовах, див. Приклад тут: текст посилання

Єдина мова, яку я бачив локалізованою, - це Excel з його макросами. Якщо ви намагаєтеся підсумувати стовпець за допомогою італійської версії Office, ви повинні написати, SOMMA(A1:A10)а не SUM. Це ганьба.

До речі, саме тому, що це цікаво, ось як повинен виглядати ваш код з італійськими ключовими словами:

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

Я бачив, як VBA перекладається на іспанські команди. це одна з найгірших речей, яку коли-небудь бачили. Мені було б соромно мати щось подібне на своєму комп’ютері.

ПД: мені здається, я вважаю, що іспанська мова є набагато приємнішою мовою, ніж англійська; але переклад - НЕПРАВНИЙ

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

Однак розуміння ключових слів мови - лише незначна частина в розумінні коду. Імена змінних, назви функцій та коментарі - це ризик бути рідною мовою автора.

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

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

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

Ні, англійські ключові слова та ідентифікатори - це добре. Хоча дехто може заперечити, чи має бути колір чи колір :)

У декількох проектах VBA, над якими я працював (так, дуже рано в кар’єрі), нам довелося виявити версію офісу, яка була встановлена ​​на машині користувача, і відповідно змінити формули, використані в таблицях.

Оскільки я програму на португальській мові "SUM" повинен був би бути перекладений на "SOMA" і так далі і так далі. Я просто не можу уявити необхідну роботу, щоб це сталося на кількох мовах. Хтось ще страждав з цією проблемою?

Є кілька мов, які переклали ключові слова. Наприклад, формули Excel. Якщо ви будете писати деякі розрахунки в електронну таблицю, це буде вашою мовою.

На щастя, це не є загальною практикою, і навіть мовники, які не володіють англійською мовою, як я, дякують Богу, що існує стандартна мова для ключових слів:

• легше ділитися вашою роботою.
• це заважає документації стати більшим кошмаром, який вона є.
• Англійські слова та речення зазвичай короткі та синтаксично прагматичні. У літературі латинські мови набагато красивіші, але для технічних речей - англійські скелі.

І де зупинитися? Чи можете ви уявити C на давньогрецькій мові?

Ключові слова повинні залишатися однією мовою, і добре, що це почалося з англійської, нехай так і залишиться. Це могло бути найгірше (азіатська мова?). І тому нам доводиться писати методи та коментарі англійською мовою. Гаразд, для нас більше роботи, але принаймні міжнародна база коду залишається узгодженою.

Однак є один випадок, коли використання назв та коментарів рідної мови може бути хорошою практикою: у країні третього світу. Я збираюся в Сенегал через кілька місяців, щоб керувати проектом Джанго. Сенегал має величезний рівень анальфабетизації, і тому вже чудово, що вони витрачають енергію на вдосконалення знань з програмування. Французька мова тут є рідною мовою, тому було б неефективно змусити їх одночасно навчатися обчислюванню І новій мові.

BTW, це ваш код із французькими ключовими словами:

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

Не те, що переклад ключових слів не має нічого спільного з перекладом рядків. Звичайно, у нас перекладено "привіт, там" нашою мовою. Європейські кодери навіть, як правило, використовують I18N набагато більше, ніж американські соти, їх послуга може охопити широку аудиторію.

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

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

Єдиною моєю мовою, яку я насправді переклав, був старий добрий Логотип (як і раніше дивовижний)

Коли я був дитиною, ми їздили до Франції, і в музеї, до якого ми ходили, я пам’ятаю, що знайшов дисплей, який показав, як писати комп’ютерні програми. Мова була якимось базовим варіантом, і я чітко пам'ятаю її, використовуючи POUR замість FOR тощо. Мені було 7 років і я тільки що вивчив ОСНОВНЕ, і мені здавалося абсолютно природним, що французи матимуть свій власний діалект, як це !!

Я здогадуюсь, можливо , я бачив LSE ?

Мова сценаріїв виробника файлів локалізована. Сценарії (і дані!) Зберігаються у жахливому "сорто-канонічному" вигляді.

Отже, якщо ви пишете сценарій в американській версії, то відкриєте його у французькій версії, усі ключові слова та вбудовані назви функцій будуть на французькій мові. Але чому він не запуститься ?! Ага! Французька версія використовує "," в якості десяткової крапки, а тому для уникнення неоднозначності використовує ";" розділити аргументи функції - там, де використовується американська версія ". і "," відповідно. Це перетворення ви повинні зробити самостійно.

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

[Примітка. Виробник файлів 8 і 9 може бути здоровим - я працював лише з 3 - 7.]

Ваше запитання цікаве щодо Perl, оскільки його синтаксис призначений для слідування (англійській) природній мові. Цікаво, чи це ускладнює немовців, які не говорять англійською ...

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

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

Безглуздо, IMHO, застосовувати мовний синтаксис . Це просто вбило б будь-яку портативність.

Єдиним винятком є ​​освітні мови, наприклад LOGO. Вони були розроблені для полегшення навчання, тому портативність не є проблемою.

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

італійською мовою

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

Щоб підтвердити занепокоєння в попередньому плакаті, я бачив код Fortran з макросом, щоб перевести всі ключові слова з англійської на французьку. Дозвольте мені не продовжувати це.

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

Я думаю, що WordBasic був локалізований. WordBasic використовувався для написання макросів для в Word, перш ніж VBA.

Якщо я правильно його пам’ятаю, лише всі WordBasic, написані в англійській версії, виконують усі локалізовані версії. Якби ви написали голландську версію, ви могли б виконати її лише на голландському слові.