Многоязыковое программированиеПредставим такую ситуацию, что какой-то язык программирования даёт возможность одновременного использования естественных языков. Когда в одной программе вполне могут ужиться английский, русский, вьетнамский и любой другой язык. Тогда возможна такая ситуация, когда некое слово одного языка имеет тот же код, что и слово какого-то другого языка. Но имеет при этом совсем иной смысл.
Язык программирования (или среда программирования) должен содержать команды подключения и отключения языков. Например, «подключить русский» или «отключить английский». Включение языка должно включать в себя подключение ключевых и служебных слов, классов, функций и всего прочего на указанном языке. Это можно сделать статически, когда перечень используемых языков известен к началу компиляции. Можно сделать и динамически, когда подключение и отключение языков делается прямо в тесте программы.
Говоря о многоязыковой поддержке, нельзя не сказать о кодировке символов языков. Бесспорно, что наименьшее количество проблем может обеспечить только Unicode. О восьмибитной ASCII уже не стоит вспоминать, о реликтовых кодировках типа EBCDIC и МТК — тем более. UTF-8 непрактичен из-за того, что символы имеют неодинаковую длину. Подробнее эта тема обсуждена в статье «Выбор кодировки для компилятора». Теперь стоило бы разобраться, что следует понимать под подключением языка. Под этим можно подразумевать загрузку словаря ключевых слов на неком естественном языке. Но при этом можно оставить доступными все алфавиты. Допустим, подключены словари только с английскими ключевыми словами, но можно писать идентификаторы с использованием греческого алфавита. Возможен и второй вариант, когда подключение языков X, Y и Z означает подключение соответствующих словарей ключевых слов и алфавитов этих языков. При этом любые остальные алфавиты остаются под запретом. Опубликовано: 2014.07.15, последняя правка: 2015.01.23 10:17
Отзывы
Представим такую ситуацию, что какой-то язык программирования даёт возможность одновременного использования естественных языков. Когда в одной программе вполне могут ужиться английский, русский, вьетнамский и любой другой язык. Я считаю, что это непрактично и усложняет работу в команде. Ведь тогда, каждый программист, сталкивающийся с такими участками должен владеть двумя диалектами. В тоже время хороших профессионалов трудно найти и для одного. Решение проблемы описанной в задаче может заключаться в возможности IDE транслировать представление с одного диалекта на другой. Для имен переменных можно использовать транслитерацию (например в английский), для комментариев — онлайн-переводчики.а UTF непрактичен из-за того, что символы имеют неодинаковую длину. Это надуманная проблема. Работа алгоритма должна заключаться в расчетах в «символах» (и это логично и более понятно), а не в «байтах». Тут наверно психологический барьер, а не практический.Допустим, подключены словари только с английскими ключевыми словами, но можно писать идентификаторы с использованием греческого алфавита. Я категорически против смешения двух языков в одной программе. Ещё раз напомню — команде разработчиков придется знать оба. Вероятность ошибок вырастает в разы.
Уровень регулярок. Словарики только обеспечите к каждому языку. И для каждого один и тот же текст программы будет на том языке, который он выбрал, а вот с идентификаторами уже не так все просто. Если для компилятора никаких особых проблем с идшниками на разных языках нет (только если вы не будете требовать транслитерации их с языка на язык!), они тупо должны быть уникальны и выделяемы из текста. А вот показать идшник на разных локализациях мы можем, только если к нему приложен перевод, иначе можем показать только в исходном виде, гарантировать отсутствие конфликтов при этом можно уверенно, иных вариантов особенно с неявным преобразованием имен я настоятельно рекомендую избегать. Как видите в техническом плане задача решается, и никаких проблем компилятору не создаст.
Это можно сделать статически, когда перечень используемых языков известен к началу компиляции. Можно сделать и динамически, когда подключение и отключение языков делается прямо в тесте программы. Еще раз: для чего таки нужна эта функция динамического отключения/подключения языка прямо в тесте программы? Такое многоязыковое программирование "is not useful", в нормальных проектах это функция будет строго запрещена, ну а в ненормальных... Впрочем я не могу представить себе, настолько ненормальные проекты должны быть проекты, чтобы бы такое разрешили!В чем смысл то? Имеем код, который полностью понятен только лишь компилятору, т.к. директива смены языка на китайский традиционный увы не наделяет программиста из, скажем, Франции способностью бегло читать иероглифы! Представим такой диалог: Босс: У вас там баг в коде строка №..., немедленно исправьте! Программист: Это невозможно, сэр. Ту часть кода писал Ли Чен Янг, она на китайском, а он в отпуске. Для работы с той частью кода нужен программист владеющий КИТАЙСКИМ ДИАЛЕКТОМ языка ХХХ...
Я почти каждый день вынужден ковыряться в программах, которые имеют не только комментарии на разных языках, но и в разных кодировках! Одновременно! В соседних строках! Полагаю, что нужны текстовые редакторы, которые могли бы "переварить" такую мешанину, например, используя теги. Внутри текста, ограниченного конкретным тегом, ввод текста должен происходить в заданной кодировке и выбранным языком. В некоторых ОСях есть переменная окружения LANGUAGE. Для дополнения к ней целесообразно сделать одноимённый подкаталог, в котором есть подкаталоги разных языков. А в них — что-то типа БД. Записи с одинаковым индексом имеют равный смысл. В результате при переключении на другой язык, вы сразу получаете новый набор идентификаторов для функций, переменных, классов, которые в IDE будут отображаться. Если в строке программы вы зададите значение переменной LANGUAGE, то получите соответствующий набор слов. Вздумал перейти на русский — пожалуйста! Вся программа — на русском. Захотел японский — нет проблем! А текстовый редактор, умеющий подстраиваться под теги, позволит в одном файле совместить (ну захотел конкретный программист именно такой стиль) англоязычный стандартный набор языка Си и русскоязычные переменные и некоторые функции. Мне бы в такой среде работать понравилось.
В случае работы исключительно в IDE возможность переключения языков можно было бы делать через меню IDE. Компилятор же должен иметь и консольный вариант, поэтому директива загрузки языка — более правильный вариант. Уважаемый Автор, тут я с вами полностью согласен. Даже более не представляю себе компилятор в ином формате кроме, консольного приложения или библиотеки.Но не в коде же! Аналогом меню в консоли является параметры командной строки, а не исходный код. И компилятор то как раз ни в каких иных языках, кроме собственного не нуждается. Если стоит задача, чтобы эти всевозможные языки "уживались" в одном коде, единственное средство добиться этого только одно. Выкинуть их полностью из кода! 100-200 функциональных лексем языка программирования против тысяч возможных способов их закодировать, не говоря уже про возможные конфликты идентификаторов. Так кого проще вынести из кода: естественный язык или программный? Машине не всё равно, это человеку будет всё равно, каким образом на экране появился именно такой текст, какой он желал бы увидеть без всяких анклавов на другом "языке" и прочих директив. Если я увижу хоть одного человека, который бы в зависимости от конкретной области кода менял бы свои "языковые" предпочтения, я сразу же соглашусь с тем, что горячая замена языка внутри кода необходима. Но тогда я в принципе не вижу возможности как избежать конфликтных ситуаций. А двоичный исходный код обладает такими же преимуществами, как и исполняемый: он быстрее компилируется, не зависит от естественного языка и кодировки, способен хранить в себе множество слоев сопутствующей информации и при этом ни в чем не уступает классическому исходному коду в виде текста и может быть в него преобразован. А использование цифровых идентификаторов позволяет не только избежать конфликтов, но и избавляет от необходимости "манглить" их имена. А если надо, чтобы исходник в вавилонскую башню превратился, тогда да — директивы в коде будут этому способствовать. И, возможно, в подключении конкретного алфавита нет необходимости. Оптимизированный алгоритм, который я вам скидывал, довольно легко справляется с поиском сразу по всем существующим в юникоде алфавитам. Он справляется с любым символом максимум за 10 простых итераций. И необходим только для внесения в древо новых слов.
а) непродуманность самих языков программирования; б) необходимость компиляции кода под конкретную архитектуру. Отсюда все проблемы со старыми языками программирования останутся и организация многокомпиляторной поддержки будет встречать огромные трудности. Я лично вижу максимум подключение отдельных библиотек, написанных на Си, с использованием модифицированного компилятора Си, с исправленными и автоматизированными функциями подключения инклудов. Это, я считаю, вполне по силам реализовать. Хотя и в этом случае нужно будет верифицировать каждую используемую библиотеку и только после её успешной компилляции, включать её в список доступных для использования.
Заведём, допустим, для перевода словари множества языков. Кто будет поддерживать их целостность и непротиворечивость? Сам программист? Вряд ли. Если б такой словарь свалился откуда-то с неба, то никто не возражал бы. Но где он? Ещё проблема: перевод с языка А на язык Б и обратно может привести к коллизиям. Делают своё дело синонимы и антонимы. Которые в разных языках — разные. А ещё есть сокращения. В разных языках сокращения тоже делаются по-разному. Как перевести имена функций «strcpy» или «itoa» на русский? Есть какие-то рекомендации от института русского языка? Перевод с русского на грузинский и обратно тоже приведёт к коллизиям: в русском есть заглавные буквы, а в грузинском их нет. И в китайском нет. Так же надо учитывать, что русский и русский компьютерный языки (а именно второй будет употребляться в идентификаторах) имеют даже разные алфавиты. Например, «IP-адрес» или «протокол https» содержит не только кириллицу, но и латиницу. Так что идея с многоязыковостью утопична. Поэксперементировать, конечно, можно. Но чтоб это было сбоку и не мешало проекту. Можно, например, сохранять при компиляции таблицу идентификаторов, чтобы потом отдельной утилитой найти идентификаторы, отсутствующие в словарях. Чтобы потом пополнить словарь или привести идентификаторы программы в соответствие со словарём. Или перевести отдельной утилитой исходник с одного языка на другой. Но чтоб «на лету» переключаться с нижегородского на французский — это сюр.
В принципе внедрение такой фичи можно отложить на попозже. Просто при проектировании надо иметь в виду, что из-под дома, который строится, в будущем могут вытащить старый фундамент и поставить новый.
int a; // a — латинскаяПоэтому идеальным было бы строгое разделения языков: или — или. Можно наделать ошибок при проектировании, а потом не иметь возможности из-за груза обратной совместимости. В C++ можно было бы исправить массу проектных ошибок. Но как? Уже написаны миллиарды строк кода по правилам, которым не один десяток лет.
eval для интерпретации, то текст переводить всё-таки придётся.Если в программе одинаково выглядящие идентификаторы (при совмещении двух алфавитов), то можно выдавать предупреждения при компиляции. которые просто переводятся в большие А от этого не страдает взаимодействие с внешним миром, например, WinAPI?
Если в программе одинаково выглядящие идентификаторы (при совмещении двух алфавитов), то можно выдавать предупреждения при компиляции. Зачем? Это же реально одно и то же. Бывает, что даже вперемежку набираешь имя идентификатора. Особенно символ "С", но это никак не мешает. Т.е. я не задумываюсь какое "Е" или "Т" написано. Кстати, и редактор 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
Это же реально одно и то же. В том то и дело, что не всегда. Вот слова, которые мне удалось придумать буквально за три минуты. ТОР (верх, англ.) — TOP (геометрическая фигура, русск.), POM (помпон, англ.) — РОМ (алкогольный напиток, русск.), BOT (бот, анл.) — ВОТ (частица, служебная часть речи, русск.). Большими буквами, как Вы любите. Я понимаю, что пример носит несколько искусственный характер. Но лучше заранее подумать об этом. Была недавно публикация, что за счёт символов Юникода можно заставить текст выглядеть одинаково. Однако, смысл (синтаксическая конструкция) кардинально меняется! Вроде бы обнаружили это, когда хакеры внедрили в открытый код свою лазейку.через специально разработанный механизм псевдонимов (на 9600 готовых имен WinAPI из 16 самых используемых DLL-библиотек), тогда, например, CreateWindows становится равным идентификатору CREATEWINDOWS Но это опять словари, которых нет и которые надо сделать для всех языков, с которыми захотят работать. Если, конечно, стремиться к мультиязычности. А если не стремиться, то можно остановиться на двух языках и словарь становится попроще.
Кстати, большие и маленькие тоже считаются одними и теми же. Многолетняя эксплуатация показали, что это вполне себе работает. Работать-то работает, однако далеко не во всех случаях это удобно. К примеру, я использую стандарт кодирования, в котором имена классов/типов начинаются с заглавной буквы, а переменные — со строчной. Это позволяет иметь, скажем, класс/тип `Person` и переменную этого же класса/типа `person`.
Старые стандарты могут долго держаться и не сдаваться, но это оборонительная тактика, к выигрышу она не ведёт. Юникод — наше всё.
Но теперь рулят нейросети. Чую, что нас что-то ждёт впереди.
Как будет реагировать компилятор на идентификаторы, которых нет в словаре? Как ни велики ожидания и желание иметь всё хорошо и сразу, но пока что словаря нет. Этот факт, как и то, что мир несовершенен.
Если взять языки малочисленных народов, то слов в таких языках маловато. При распаде СССР в некоторых республиках хотели сгоряча отказаться от русского языка везде, в том числе в технической документации. Но как перевести эту документацию, если в их языке просто нет тех слов, которые есть в русском? Вот так у казахов не получилось перевести заводскую технологическую документацию. В языке эскимосов есть несколько десятков вариаций слова «снег», потому что они имеют с ним дело почти круглый год. Но всё, что плавает по воде, передаётся единственный словом «лодка». «Большая лодка» (корабль), «лодка с парусами» (это и парусник, и каравелла, и бригантина, и шлюп, и барк, бот и т. д.). Если перевести что-то с большого языка на язык эскимосов, а потом обратно, то неизбежны потери. Это потери смыслов, семантики. Поэтому для описания семантики действительно лучше выбрать искусственный/машинный язык, потому что в любом естественном языке найдутся слабые места и противоречия в виде омонимов и т. д. Столкнулся с рекламой языка томашек, мол он хорош в качестве промежуточного. Ну так он же язык малой народности! Разговаривают на нём лишь полмиллиона человек. Кто-нибудь слышал об этой великой культуре, об их интеллигенции, литературе, искусстве, науке? То-то и оно. Откуда у народа, который занимается мотыжным земледелием и разведением мелкого рогатого скота возьмётся развитый понятийный аппарат? Значит, их язык мал и гарантирует потерю смыслов при переводе. Как язык передачи мыслей он наверняка недостаточен. Сегодня прочитал, что в Фейсбуке заблокировали рекламный аккаунт преподавателя Питона, потому что посчитали, что он продаёт змей. С машинным языком таких казусов не было бы. На эту тему хорошо бы выслушать компьютерных лингвистов. Например, Ашманова. Лучше довериться специалистам, они спасут нашу вселенную. Есть перед глазами пример дилетантов, которые достигнув успехов на одном поприще, начинают считать себя корифеями во всём и поучать, как жить. Пугачёва, Макаревич, Каспаров...
Написать автору можно на электронную почту |
2014/07/21 03:41, utkin