Чому не існує більше багатомовних мов програмування?

Чи існують мови програмування, які доступні та розширюються більш ніж однією природною мовою?

Наприклад, англійська версія з do..whileциклом, іспанська версія з hacer..mientasциклом, французька версія з faire..pendantі голландська версія з doe..terwijl.

Єдиною «мовою програмування», яку я можу придумати для подібного роду програм, це Microsoft VBA.

Питання про бонус: Чому так мало мов програмування є кількома мовами?

Назви функцій у формулах Excel локалізовані, де ви можете використовувати або англійське формулювання, або локальний еквівалент.

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

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

У попередньому столітті, особливо в 1960-1970-х, вони були деякими мовами програмування, що не засновані на англійській мові. У Франції у нас були слова PAF & LSE з ключовими словами французького вигляду. WW2 Німеччина була Plankalküll по K.Zuze. У Радянському Союзі А. Ершов розробив деякі мови (наприклад, Рапіра ) з російськими ключовими словами. IIRC PAF (розроблений та впроваджений моїм покійним батьком, коли я був дитиною - на початку 1960-х років), також можна було продати за допомогою ключових слів англійського вигляду (або російського вигляду, або німецького вигляду). А деякі мови, наприклад APL , взагалі не мали ключових слів. Інші мови ( PL / I ) не резервувалиключові слова. І ви можете переосмислити ключові слова за допомогою методів препроцесора (наприклад, сьогодні на мові C, #define si if& #define sinon elseдля французьких студентів ....; подібні трюки на основі макросу можливі в PL / I або навіть у звичайному Lisp).

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

Крім того, англійська мова має багато коротких ключових слів (порівняйте sinonфранцузькою з elseанглійською або mettreфранцузькою мовами для putанглійської), тому в використанні ключових слів англійською мовою є невелика перевага.

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

PS. Домінування англійської мови не характерне лише для ІТ. Навіть якщо Великобританія вийде з Європейського Союзу - сценарій Brexit - , фактично офіційною мовою ЄС залишатиметься англійська (яка тоді не буде мовою жодної країни-члена ЄС), а проекти ІКТ H2020 пишуться англійською мовою.

Є дуже вагомі причини, що професійні мови програмування не перекладаються.

1) Зусилля: було б величезним завданням перекласти сучасну мову. Візьміть Java - це було б невеликим завданням перекласти 50 або більше ключових слів, але вам також знадобиться перекласти повну стандартну бібліотеку, яка складається з тисяч класів та методів та відповідної документації.

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

3) Програмістам все одно потрібно знати англійську. Багато стандартів, таких як HTTP, CSS, HTML, так чи інакше використовують англійську мову для ідентифікаторів. Вони не можуть бути перекладені, оскільки слова викладені у стандарт.

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

Однак, для мов, призначених для випадкових програмістів, на відміну від професійних програмістів, може бути доцільним створення перекладених версій. Це стосується VBA, і я вважаю, що AppleScript також існував у перекладених версіях.

Я не знаю жодної іншої мови, за винятком, можливо, справді старої езотеричної версії BASIC, яка, як правило, викликає багато дивних прихильності, тому я буду дотримуватися бонусного питання: чому так мало перекладених мов програмування:

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

• Ви обмежите аудиторію свого коду, якщо не будете дотримуватися "універсальної" мови. Звичайно, не всі знають англійську, але те саме стосується кожної мови.
• Ключові слова з одним словом не обов'язково є одним словом у всіх мовах, що ускладнює розбір. Я ніколи не перевіряв, але можу уявити, що існує досить багато спеціального корпусу для роботи з єдиним багатослівним типом c ++ типу "long long".
• Якщо ви почнете перекладати ключові слова, чи будете ви також враховувати локалі та як форматувати номери? Наприклад, кома проти періоду у вигляді десяткового роздільника. Або вимагати, щоб німецькі іменники були написані з великої літери?
• Переважна більшість тексту в даній програмі - це змінні, методи та назви класів, не кажучи вже про коментарі. Хоча, безумовно, є бібліотеки, написані іншими мовами, необхідність підтримувати переклади вихідних кодів усіх бібліотек для обслуговування всіх користувачів було б великим тягарем для більшості розробників, не кажучи вже про додаткову складність дискусій навколо такого коду.
• Укладачі повинні розуміти всі реалізовані мови. Можливо, навіть кілька мов в одному файлі. Невеликий подвиг для комп'ютера напевно, але додаткова робота все-таки. Можливо, вам доведеться мати справу з одним і тим же ключовим словом, що означає різні речі на різних мовах, або терміни просто занадто неоднозначні, щоб добре читати.
• (нормально, впевнено) Напевно більшість людей, яким довелося мати справу з документами MS Office, запрограмованими та відформатованими на різних мовах, відкинуть цю ідею як не вартую клопоту.

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

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

Уявіть мову, де у вас є if, while... do, switchта всі інші ключові слова, визначені (якось) у стандарті, ви можете надсилати системні бібліотеки у "токенізованому форматі", з місцевим кодом, записаним у некетонізованій формі. Тоді власне компілятор працює на токенізованому шарі і, можливо, все буде добре.

Однак це не вся історія. Ви все ще опинитесь у ситуаціях, коли у вас є бібліотеки звідкись, що не є "стандартною бібліотекою", пов'язаною з іменами функцій. І вони не мали б канонічного відображення між мовами і вимагали б перекладу на місцеву мову, щоб бути зручним у використанні, або ви в кінцевому підсумку з мішмаш мов у своєму вихідному коді.

Усі наведені відповіді - чудові відповіді, але я все одно дам свої два центи.

На початку обчислення технічного, культурного та економічного домінування США та Великобританії стало логічно лише те, які найбільш вдалі мови були створені за допомогою англійських слів.

Пізніше, коли програмне забезпечення стало галуззю , воно також стало глобальним завданням. Не секрет, що програмістів менше, ніж потрібно, тому програмні компанії та спеціально визначаючі галузі, такі як IBM, почали наймати програмістів з усіх куточків світу: Росії, Пакистану, Індії, Франції, Німеччини, Ізраїлю тощо. здебільшого програмувати на вже існуючих глобально успішних мовах, які вже базувалися на англійській мові, а також створювали нові мови, і для цього розрізненого джерела програмістів вже існуюча загальна мова була кращою, ніж будь-яка інша мова.

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

Якою мовою користувалася б людина з Ізраїлю для співпраці з людиною з Шрі-Ланки? Найімовірніше, вони не розмовляють і навіть не читають рідну мову один одного. Тож на допомогу приходить англійська мова.

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

Перефразовуючи Джея Уокера :

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

Дивіться відео "Англійська манія" .

Нижня лінія:

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

Англійська мова також є мовою "без акцентів", також у вас немає дивного символу, якому потрібно кодування, відмінне від ASCII. Я італійський і іноді стикаюся з помилками кодування, якщо використовую італійську розкладку клавіатури або наголошені символи, такі як àèéìòù. Більше того, "else" перекладається на "altrimenti", "in" - "dentro" ... це було б неприємно.