Многоязыковое программированиеПредставим такую ситуацию, что какой-то язык программирования даёт возможность одновременного использования естественных языков. Когда в одной программе вполне могут ужиться английский, русский, вьетнамский и любой другой язык. Тогда возможна такая ситуация, когда некое слово одного языка имеет тот же код, что и слово какого-то другого языка. Но имеет при этом совсем иной смысл.
Язык программирования (или среда программирования) должен содержать команды подключения и отключения языков. Например, «подключить русский» или «отключить английский». Включение языка должно включать в себя подключение ключевых и служебных слов, классов, функций и всего прочего на указанном языке. Это можно сделать статически, когда перечень используемых языков известен к началу компиляции. Можно сделать и динамически, когда подключение и отключение языков делается прямо в тесте программы.
Говоря о многоязыковой поддержке, нельзя не сказать о кодировке символов языков. Бесспорно, что наименьшее количество проблем может обеспечить только Unicode. О восьмибитной ASCII уже не стоит вспоминать, о реликтовых кодировках типа EBCDIC и МТК — тем более. UTF-8 непрактичен из-за того, что символы имеют неодинаковую длину. Подробнее эта тема обсуждена в статье «Выбор кодировки для компилятора». Теперь стоило бы разобраться, что следует понимать под подключением языка. Под этим можно подразумевать загрузку словаря ключевых слов на неком естественном языке. Но при этом можно оставить доступными все алфавиты. Допустим, подключены словари только с английскими ключевыми словами, но можно писать идентификаторы с использованием греческого алфавита. Возможен и второй вариант, когда подключение языков X, Y и Z означает подключение соответствующих словарей ключевых слов и алфавитов этих языков. При этом любые остальные алфавиты остаются под запретом. Опубликовано: 2014.07.15, последняя правка: 2015.01.23 10:17
Отзывы✅ 2014/07/21 03:41, utkin #0 Представим такую ситуацию, что какой-то язык программирования даёт возможность одновременного использования естественных языков. Когда в одной программе вполне могут ужиться английский, русский, вьетнамский и любой другой язык. Я считаю, что это непрактично и усложняет работу в команде. Ведь тогда, каждый программист, сталкивающийся с такими участками должен владеть двумя диалектами. В тоже время хороших профессионалов трудно найти и для одного. Решение проблемы описанной в задаче может заключаться в возможности IDE транслировать представление с одного диалекта на другой. Для имен переменных можно использовать транслитерацию (например в английский), для комментариев — онлайн-переводчики.а UTF непрактичен из-за того, что символы имеют неодинаковую длину. Это надуманная проблема. Работа алгоритма должна заключаться в расчетах в «символах» (и это логично и более понятно), а не в «байтах». Тут наверно психологический барьер, а не практический.Допустим, подключены словари только с английскими ключевыми словами, но можно писать идентификаторы с использованием греческого алфавита. Я категорически против смешения двух языков в одной программе. Ещё раз напомню — команде разработчиков придется знать оба. Вероятность ошибок вырастает в разы.✅ 2016/03/26 17:16, rst256 #1 Никакого совмещения, язык программирования, в отличие от естественного, по определению гарантирует однозначное и верное преобразование текста исходного кода с одного человеческого языка на другой, при наличии соответствующих словарей. Это даже на порядок проще, чем обработка этого же кода компиляцией.Уровень регулярок. Словарики только обеспечите к каждому языку. И для каждого один и тот же текст программы будет на том языке, который он выбрал, а вот с идентификаторами уже не так все просто. Если для компилятора никаких особых проблем с идшниками на разных языках нет (только если вы не будете требовать транслитерации их с языка на язык!), они тупо должны быть уникальны и выделяемы из текста. А вот показать идшник на разных локализациях мы можем, только если к нему приложен перевод, иначе можем показать только в исходном виде, гарантировать отсутствие конфликтов при этом можно уверенно, иных вариантов особенно с неявным преобразованием имен я настоятельно рекомендую избегать. Как видите в техническом плане задача решается, и никаких проблем компилятору не создаст. ✅ 2016/07/02 05:15, rst256 #2 Это можно сделать статически, когда перечень используемых языков известен к началу компиляции. Можно сделать и динамически, когда подключение и отключение языков делается прямо в тесте программы. Еще раз: для чего таки нужна эта функция динамического отключения/подключения языка прямо в тесте программы? Такое многоязыковое программирование "is not useful", в нормальных проектах это функция будет строго запрещена, ну а в ненормальных... Впрочем я не могу представить себе, настолько ненормальные проекты должны быть проекты, чтобы бы такое разрешили!В чем смысл то? Имеем код, который полностью понятен только лишь компилятору, т.к. директива смены языка на китайский традиционный увы не наделяет программиста из, скажем, Франции способностью бегло читать иероглифы! Представим такой диалог: Босс: У вас там баг в коде строка №..., немедленно исправьте! Программист: Это невозможно, сэр. Ту часть кода писал Ли Чен Янг, она на китайском, а он в отпуске. Для работы с той частью кода нужен программист владеющий КИТАЙСКИМ ДИАЛЕКТОМ языка ХХХ... ✅ 2016/07/03 14:28, Автор сайта #3 В случае работы исключительно в IDE возможность переключения языков можно было бы делать через меню IDE. Компилятор же должен иметь и консольный вариант, поэтому директива загрузки языка — более правильный вариант. Французскому программисту сложновато будет понять иероглифы. Но ведь тут речь идёт и о словарях, которые позволят переводить тексты «на лету». Главное — чтобы они были. Чтобы с китайского можно было перевести на французский.✅ 2016/07/20 17:30, Alex #4 Уважаемые! Вы спорите, можно или нет совмещать несколько языков в одном проекте...Я почти каждый день вынужден ковыряться в программах, которые имеют не только комментарии на разных языках, но и в разных кодировках! Одновременно! В соседних строках! Полагаю, что нужны текстовые редакторы, которые могли бы "переварить" такую мешанину, например, используя теги. Внутри текста, ограниченного конкретным тегом, ввод текста должен происходить в заданной кодировке и выбранным языком. В некоторых ОСях есть переменная окружения LANGUAGE. Для дополнения к ней целесообразно сделать одноимённый подкаталог, в котором есть подкаталоги разных языков. А в них — что-то типа БД. Записи с одинаковым индексом имеют равный смысл. В результате при переключении на другой язык, вы сразу получаете новый набор идентификаторов для функций, переменных, классов, которые в IDE будут отображаться. Если в строке программы вы зададите значение переменной LANGUAGE, то получите соответствующий набор слов. Вздумал перейти на русский — пожалуйста! Вся программа — на русском. Захотел японский — нет проблем! А текстовый редактор, умеющий подстраиваться под теги, позволит в одном файле совместить (ну захотел конкретный программист именно такой стиль) англоязычный стандартный набор языка Си и русскоязычные переменные и некоторые функции. Мне бы в такой среде работать понравилось. ✅ 2016/08/14 02:48, rst256 #5 В случае работы исключительно в IDE возможность переключения языков можно было бы делать через меню IDE. Компилятор же должен иметь и консольный вариант, поэтому директива загрузки языка — более правильный вариант. Уважаемый Автор, тут я с вами полностью согласен. Даже более не представляю себе компилятор в ином формате кроме, консольного приложения или библиотеки.Но не в коде же! Аналогом меню в консоли является параметры командной строки, а не исходный код. И компилятор то как раз ни в каких иных языках, кроме собственного не нуждается. Если стоит задача, чтобы эти всевозможные языки "уживались" в одном коде, единственное средство добиться этого только одно. Выкинуть их полностью из кода! 100-200 функциональных лексем языка программирования против тысяч возможных способов их закодировать, не говоря уже про возможные конфликты идентификаторов. Так кого проще вынести из кода: естественный язык или программный? Машине не всё равно, это человеку будет всё равно, каким образом на экране появился именно такой текст, какой он желал бы увидеть без всяких анклавов на другом "языке" и прочих директив. Если я увижу хоть одного человека, который бы в зависимости от конкретной области кода менял бы свои "языковые" предпочтения, я сразу же соглашусь с тем, что горячая замена языка внутри кода необходима. Но тогда я в принципе не вижу возможности как избежать конфликтных ситуаций. А двоичный исходный код обладает такими же преимуществами, как и исполняемый: он быстрее компилируется, не зависит от естественного языка и кодировки, способен хранить в себе множество слоев сопутствующей информации и при этом ни в чем не уступает классическому исходному коду в виде текста и может быть в него преобразован. А использование цифровых идентификаторов позволяет не только избежать конфликтов, но и избавляет от необходимости "манглить" их имена. А если надо, чтобы исходник в вавилонскую башню превратился, тогда да — директивы в коде будут этому способствовать. И, возможно, в подключении конкретного алфавита нет необходимости. Оптимизированный алгоритм, который я вам скидывал, довольно легко справляется с поиском сразу по всем существующим в юникоде алфавитам. Он справляется с любым символом максимум за 10 простых итераций. И необходим только для внесения в древо новых слов. ✅ 2021/03/27 01:40, Виталий Монастырский #6 Технически эта проблема вполне себе решена в языках веб-программирования. В прикладных языках все проблемы наследуются из-за двух вещей:а) непродуманность самих языков программирования; б) необходимость компиляции кода под конкретную архитектуру. Отсюда все проблемы со старыми языками программирования останутся и организация многокомпиляторной поддержки будет встречать огромные трудности. Я лично вижу максимум подключение отдельных библиотек, написанных на Си, с использованием модифицированного компилятора Си, с исправленными и автоматизированными функциями подключения инклудов. Это, я считаю, вполне по силам реализовать. Хотя и в этом случае нужно будет верифицировать каждую используемую библиотеку и только после её успешной компилляции, включать её в список доступных для использования. ✅ 2021/08/07 13:30, Anatoly #7 ASCII — 7-битная кодировка✅ 2022/06/03 11:02, Неслучайный читатель #8 Программировать, переключаясь с языка на язык, заманчиво, конечно. Но реалистично ли? Лично я, если бы мне предстояло написать компилятор, не стал бы связываться с переводом с языка на язык. Уж слишком много подводных камней.Заведём, допустим, для перевода словари множества языков. Кто будет поддерживать их целостность и непротиворечивость? Сам программист? Вряд ли. Если б такой словарь свалился откуда-то с неба, то никто не возражал бы. Но где он? Ещё проблема: перевод с языка А на язык Б и обратно может привести к коллизиям. Делают своё дело синонимы и антонимы. Которые в разных языках — разные. А ещё есть сокращения. В разных языках сокращения тоже делаются по-разному. Как перевести имена функций «strcpy» или «itoa» на русский? Есть какие-то рекомендации от института русского языка? Перевод с русского на грузинский и обратно тоже приведёт к коллизиям: в русском есть заглавные буквы, а в грузинском их нет. И в китайском нет. Так же надо учитывать, что русский и русский компьютерный языки (а именно второй будет употребляться в идентификаторах) имеют даже разные алфавиты. Например, «IP-адрес» или «протокол https» содержит не только кириллицу, но и латиницу. Так что идея с многоязыковостью утопична. Поэксперементировать, конечно, можно. Но чтоб это было сбоку и не мешало проекту. Можно, например, сохранять при компиляции таблицу идентификаторов, чтобы потом отдельной утилитой найти идентификаторы, отсутствующие в словарях. Чтобы потом пополнить словарь или привести идентификаторы программы в соответствие со словарём. Или перевести отдельной утилитой исходник с одного языка на другой. Но чтоб «на лету» переключаться с нижегородского на французский — это сюр. ✅ 2022/06/09 22:54, Автор сайта #9 В принципе, согласен с Вами. Это одна из причин, почему не приступаю к компилятору. Потому что многоязыковость должна работать уже на самом раннем этапе, при лексическом анализе. Лексер должен знать, с каким алфавитом он должен работать, с какими ключевыми словами. А вот приемлемой схемы работы компилятора со словарём нет и нет.В принципе внедрение такой фичи можно отложить на попозже. Просто при проектировании надо иметь в виду, что из-под дома, который строится, в будущем могут вытащить старый фундамент и поставить новый. ✅ 2022/06/19 20:19, Клихальт #10 Насколько помню, компилятор PL/1-KT вполне себе позволяет писать как по русски, так и по не русски. По вашему это ведёт к каким-то жутким, душераздирающим проблемам? Насколько я понимаю, никто не заставляет вас писать сразу на двух языках -- каждый волен писать так, как ему удобно.✅ 2022/06/19 21:56, Автор сайта #11 Просто хотелось бы сделать всё сразу по уму. Вот пример негативного влияния одновременного использования двух языков:int a; // a — латинскаяПоэтому идеальным было бы строгое разделения языков: или — или. Можно наделать ошибок при проектировании, а потом не иметь возможности из-за груза обратной совместимости. В C++ можно было бы исправить массу проектных ошибок. Но как? Уже написаны миллиарды строк кода по правилам, которым не один десяток лет. ✅ 2022/06/20 09:54, kt #12 Замечу, что в PL/1-KT похожая проблема решалась ещё 35 лет назад: совпадающие по написанию русские и латинские буквы считаются одними и теми же. Кстати, большие и маленькие тоже считаются одними и теми же. Многолетняя эксплуатация показали, что это вполне себе работает. Т.е., если это текст не в кавычках — все переводится в большие и латинские, за исключением кириллических значков, которые просто переводятся в большие.✅ 2022/06/20 22:22, Автор сайта #13 В принципе, оригинальная идея, вполне решающая проблемы. Даже не пришло такое в голову. Совмещение одинаковых по начертанию символов латиницы и кириллицы — это наследие кодировки ДКОИ, которая работала на ЕС ЭВМ. Но если текст в кавычках (а текст в кавычках при Вашем подходе не переводится) подаётся функцииeval для интерпретации, то текст переводить всё-таки придётся.Если в программе одинаково выглядящие идентификаторы (при совмещении двух алфавитов), то можно выдавать предупреждения при компиляции. которые просто переводятся в большие А от этого не страдает взаимодействие с внешним миром, например, WinAPI?✅ 2022/06/20 23:27, kt #14 Если в программе одинаково выглядящие идентификаторы (при совмещении двух алфавитов), то можно выдавать предупреждения при компиляции. Зачем? Это же реально одно и то же. Бывает, что даже вперемежку набираешь имя идентификатора. Особенно символ "С", но это никак не мешает. Т.е. я не задумываюсь какое "Е" или "Т" написано. Кстати, и редактор FAR при поиске в тексте делает то же самое ))А от этого не страдает взаимодействие с внешним миром, например, WinAPI? Разумеется страдает. У нас есть два пути перевода имен WinAPI, где не только большие и малые различаются, но и длина более 31 символа бывает: или динамический вызов процедуройЗАГРУЗИТЬ_ИЗ_DLL (именно так двуязычно и называется )), где имя задается строкой в кавычках и тогда нет проблемы. Или "статическая" линковка WinAPI внутри EXE-файла через специально разработанный механизм псевдонимов (на 9600 готовых имен WinAPI из 16 самых используемых DLL-библиотек), тогда, например, CreateWindows становится равным идентификатору CREATEWINDOWS, где C E A T O могут быть и кириллицей, но в тексте программы можно по-прежнему писать CreateWindows для наглядности. В любом случае внутри import-секции EXE-файла будет требуемое CreateWindows.Есть и обратный вариант совместимости: при описании внешней процедуры можно писать СОЗДАТЬ_ОКНО:PROC EXT ('CreateWindows');Это бывает нужно, когда мы на PL/1-KT создаем не EXE, а DLL✅ 2022/06/21 12:12, Автор сайта #15 Это же реально одно и то же. В том то и дело, что не всегда. Вот слова, которые мне удалось придумать буквально за три минуты. ТОР (верх, англ.) — TOP (геометрическая фигура, русск.), POM (помпон, англ.) — РОМ (алкогольный напиток, русск.), BOT (бот, анл.) — ВОТ (частица, служебная часть речи, русск.). Большими буквами, как Вы любите. Я понимаю, что пример носит несколько искусственный характер. Но лучше заранее подумать об этом. Была недавно публикация, что за счёт символов Юникода можно заставить текст выглядеть одинаково. Однако, смысл (синтаксическая конструкция) кардинально меняется! Вроде бы обнаружили это, когда хакеры внедрили в открытый код свою лазейку.через специально разработанный механизм псевдонимов (на 9600 готовых имен WinAPI из 16 самых используемых DLL-библиотек), тогда, например, CreateWindows становится равным идентификатору CREATEWINDOWS Но это опять словари, которых нет и которые надо сделать для всех языков, с которыми захотят работать. Если, конечно, стремиться к мультиязычности. А если не стремиться, то можно остановиться на двух языках и словарь становится попроще.✅ 2022/06/22 00:00, alextretyak #16 Кстати, большие и маленькие тоже считаются одними и теми же. Многолетняя эксплуатация показали, что это вполне себе работает. Работать-то работает, однако далеко не во всех случаях это удобно. К примеру, я использую стандарт кодирования, в котором имена классов/типов начинаются с заглавной буквы, а переменные — со строчной. Это позволяет иметь, скажем, класс/тип `Person` и переменную этого же класса/типа `person`.✅ 2022/07/14 12:20, Бурановский дедушка #17 Сузить стандарты всегда тяжелее, чем расширить. Были когда-то целые числа только со знаком, но потом появились беззнаковые целые и проникли в WinAPI. И теперь отказаться от беззнаковых трудно. На телеграфных аппаратах и первых принтерах были только заглавные буквы. Но потом появились строчные. Они тоже проникли в WinAPI и без них тоже трудно. Раньше для кодирования символов было достаточно одного байта. Но вот потом… Да, история никогда не останавливается.Старые стандарты могут долго держаться и не сдаваться, но это оборонительная тактика, к выигрышу она не ведёт. Юникод — наше всё. ✅ 2022/08/04 23:27, Неслучайный читатель #18 Интересный вопрос автору сайта. Допустим, язык программирования опирается на словарь какого-то языка. Вопрос:
✅ 2023/10/20 21:38, Ильдар #19 Когда-то компания ABBYY пыталась разрабатывать промежуточный язык для машинного перевода естественных языков. По-моему, этот язык планировался только в двоичном представлении, без текстовой формы. Им нужны были инвестиции порядка 10 — 50 млн. $, но они их так и не получили.Но теперь рулят нейросети. Чую, что нас что-то ждёт впереди. ✅ 2023/10/21 16:23, Автор сайта #20 Это логично, что промежуточный язык должен быть машинным, а не человеческим, даже если это Эсперанто или Волапюк.Как будет реагировать компилятор на идентификаторы, которых нет в словаре? Как ни велики ожидания и желание иметь всё хорошо и сразу, но пока что словаря нет. Этот факт, как и то, что мир несовершенен.✅ 2023/10/21 23:56, Неслучайный читатель #21 О промежуточных языках. Языки можно поделить на большие и малые. Большими языками пользуются большие народы. Чем больше людей говорят на каком-то языке, тем быстрее растёт в нём количество слов и словоформ. Например, не очень давно английский преодолел отметку 1 млн. слов в языке.Если взять языки малочисленных народов, то слов в таких языках маловато. При распаде СССР в некоторых республиках хотели сгоряча отказаться от русского языка везде, в том числе в технической документации. Но как перевести эту документацию, если в их языке просто нет тех слов, которые есть в русском? Вот так у казахов не получилось перевести заводскую технологическую документацию. В языке эскимосов есть несколько десятков вариаций слова «снег», потому что они имеют с ним дело почти круглый год. Но всё, что плавает по воде, передаётся единственный словом «лодка». «Большая лодка» (корабль), «лодка с парусами» (это и парусник, и каравелла, и бригантина, и шлюп, и барк, бот и т. д.). Если перевести что-то с большого языка на язык эскимосов, а потом обратно, то неизбежны потери. Это потери смыслов, семантики. Поэтому для описания семантики действительно лучше выбрать искусственный/машинный язык, потому что в любом естественном языке найдутся слабые места и противоречия в виде омонимов и т. д. Столкнулся с рекламой языка томашек, мол он хорош в качестве промежуточного. Ну так он же язык малой народности! Разговаривают на нём лишь полмиллиона человек. Кто-нибудь слышал об этой великой культуре, об их интеллигенции, литературе, искусстве, науке? То-то и оно. Откуда у народа, который занимается мотыжным земледелием и разведением мелкого рогатого скота возьмётся развитый понятийный аппарат? Значит, их язык мал и гарантирует потерю смыслов при переводе. Как язык передачи мыслей он наверняка недостаточен. Сегодня прочитал, что в Фейсбуке заблокировали рекламный аккаунт преподавателя Питона, потому что посчитали, что он продаёт змей. С машинным языком таких казусов не было бы. На эту тему хорошо бы выслушать компьютерных лингвистов. Например, Ашманова. Лучше довериться специалистам, они спасут нашу вселенную. Есть перед глазами пример дилетантов, которые достигнув успехов на одном поприще, начинают считать себя корифеями во всём и поучать, как жить. Пугачёва, Макаревич, Каспаров... ✅ 2023/10/22 00:59, Сорок сороков #22 У языка томашек нет даже раздела в Википедии.Написать автору можно на электронную почту |
Продолжение цикла и выход из него