Какой смысл добавлять поддержку идентификатора Unicode в различные языковые реализации?

14

Я лично нахожу, что чтение кода, полного идентификаторов Unicode, сбивает с толку. По моему мнению, это также препятствует тому, чтобы код был легко поддержан. Не говоря уже о всех усилиях, необходимых авторам различных переводчиков для реализации такой поддержки. Я также постоянно замечаю отсутствие (или наличие) поддержки идентификаторов Unicode в списках (не) преимуществ различных реализаций языка (как это действительно имеет значение). Я не понимаю: почему так много внимания?

unicode Егор Тенсин
источник
1
Вы имеете в виду названия вещей или специальные символы, такие как звезды, лямбды и средние точки?
Фрэнк Шиарар
5
лол ! Знаете ли вы, что мир существует за пределами англоязычных стран? Открытие Amazign, не так ли?
Deadalnix
3
deadalnix: я живу в такой стране, поэтому мы могли бы использовать такие идентификаторы, как größe. Тем не менее, я никогда не делаю этого, и я настоятельно не рекомендую делать это. Поэтому вопрос очень актуален.
user281377
2
deadalnix: я никогда не был в англоязычной стране до сих пор. Почему бы не обратить внимание на реальный вопрос, а не на вопросника?
Егор Тенсин
6
Хотелось бы, чтобы языки сосредоточились на том, чтобы Unicode правильно обрабатывал строки, и исключили причудливые идентификаторы Unicode. Хорошие ресурсы программирования в любом случае есть на английском языке (StackOverflow), поэтому давайте признаем, что программирование должно выполняться на английском языке (что также облегчает совместное использование) и сосредоточено на реализации правильной манипуляции со строками Unicode.
Матье М.

Ответы:

17

Когда вы думаете о юникоде, вы думаете о китайских или русских символах, что заставляет вас думать о некотором исходном коде, написанном на русском языке, который вы видели в Интернете, и который был непригодным (если вы не знаете русский язык).

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

При написании кода для определенного поля с помощью юникода вы можете сократить код и сделать его более читабельным . Вместо того:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

ты можешь написать:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

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

Или, когда вы делаете заявление, связанное с зеркальной фотографией, вместо:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

Вы можете заменить апертуру на символ ƒ, написав ближе к ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

Это может быть неудобно : при наборе общего кода на C # я бы предпочел написать:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

скорее, чем:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

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

Это, как говорится, все еще полезно в некоторых случаях. currentLens.GetMaximumƒ();из моего предыдущего примера можно положиться на IntelliSense, и его можно набирать так же быстро, как GetMaximumApertureболее короткий и более читаемый. Кроме того, для определенных доменов с большим количеством символов сочетания клавиш могут помочь печатать символы быстрее, чем их буквальные эквиваленты. в исходном коде.

То же самое, кстати, относится и к комментариям. Никто не хочет читать код, полный комментариев на китайском (если вы сами не знаете китайский язык). Но в некоторых языках программирования символы Юникода все еще могут быть полезны. Одним из примеров являются сноски¹.

Certainly Мне, конечно, не понравятся сноски в коде C #, где существует строгий набор правил стиля написания комментариев. В PHP, с другой стороны, если есть много вещей, которые нужно объяснить, но эти вещи не очень важны, почему бы не поместить их в конец файла и не создать сноску в PHPDoc метода?

Арсений Мурзенко
источник
ASCII включает в себя 37 символов, которые можно использовать в идентификаторах; Я ожидаю, что в большинстве шрифтов они достаточно визуально различимы, чтобы даже люди, не владеющие латинским алфавитом, могли научиться определять, что две строки символов в разных шрифтах имеют один и тот же идентификатор. Сколько усилий по отладке будет потрачено впустую, когда программист использует «Ф» для угла вместо «Ф»?
суперкат
1
@supercat: хорошая мысль. Но приведенный вами пример показывает плохое использование инструмента, а не то, что сам инструмент плохой. Δxили -∞являются допустимыми (с некоторыми недостатками, которые я объяснил в своем ответе). Ф/ Φс другой стороны, это просто признаки того, что программист не понимает, как правильно именовать переменные.
Арсений Мурзенко
1
Если программист хотел получить греческую букву тета в нижнем регистре (например, для горизонтального угла), знаете ли вы, какой из символов, которые я дал, является правильным? Есть много групп персонажей, которые выглядят очень похожими, если не идентичными. Если исходные файлы должны были содержать директивы, указывающие, какие символы могут сосуществовать в идентификаторах, которые могут помочь, но в противном случае я вижу много потенциального смешения между переменными, названными точно с иностранными символами, по сравнению с именами с похожими символами.
суперкат
1
@supercat: вы имели в виду греческую букву фи? Я хочу сказать, что если программист использует этот символ в приложении, где ожидается термин «накопительная функция распределения», любой человек, знающий терминологию и символы домена, поймет, что означает Φ. cumulativeDistributionFunctionслишком долго CDFменее читабелен, чем Φ. cumDistFuncнекрасиво Это также означает, что если программист использует вместо этого кириллицу EF (Ф) в этом контексте, это просто ошибка. Таким же образом, программист мог использовать неправильный термин или неправильное сокращение.
Арсений Мурзенко
1
Если имя переменной состоит из символов подчеркивания, 0-9, az и AZ, кто-то с копией кода, которая не поддерживает копирование / вставку (например, распечатку), может разумно надеяться воспроизвести ее точно. Кто-то, пытающийся скопировать «without», не зная, что это значит, может очень легко получить «Ф», и даже если программист знает, что это «phi», неясно, является ли «φ» или «ɸ» подходящее. [Одна из них - «Латинская строчная буква Phi», а другая - «Греческая маленькая буква Phi» ​​- они явно различаются в этом шрифте комментария, но не в, например, Lucida Sans Unicode].
суперкат
8

Я бы сказал:

  1. для облегчения непрофессионалов и новичков, которые изучают программирование (например, в школе) и не знают английского языка. Они все равно не пишут производственный код. Я много раз видел такой код:

    double upsos, baros;
cin >> upsos >> baros;

    Просто позволь беднягу написать это на своем языке:

    double ύψος, βάρος;
cin >> ύψος >> βάρος;

  2. Тебе не нравится это?

    class ☎ {
public:
    ☎(const char*);
    void 📞();
    void 🎧(👨);
};

☎ ☏("031415926");
☏.🎧(👨("Bob"));
ofstream f;
f.💾();
ybungalobill
источник
По иронии судьбы, код под заголовком «Не нравится вам» не отображается должным образом, что иллюстрирует причину, по которой вы можете не использовать прикольные символы.
Крис
5

Конечно, каждый современный компилятор должен иметь дело с исходным кодом Unicode сегодня. Например, строковые константы могут содержать символы Unicode. Но как только это будет достигнуто, почему бы не разрешить использование юникод-идентификаторов? Это не страшно, если ваш код компилятора не зависит от символов, являющихся 7-битными кодами.

Но ОП прав в том, что: теперь индус, говорящий на хинди, должен поддерживать код с русскими идентификаторами и арабскими комментариями. Какой кошмар для бедного китайца, который должен проверять качество и не умеет читать ни один из вышеперечисленных алфавитов!

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

Инго
источник
Проблема с разрешением идентификаторов Unicode заключается в том, что он позволяет исходному коду содержать информацию, которая семантически важна, но не печатается. Например, если класс объявляет поле А, его конструктор принимает параметр Α, а оператор в конструкторе говорит var x = A.boz();, будет ли Aуказываться поле, параметр или что-то еще? Как можно сказать?
суперкат
1
Да, но тогда, только несколько символов выглядят одинаково, и тогда, как это часто бывает, это вопрос стиля, правил кодирования и обеспечения качества, которые должны гарантировать, что вы не будете использовать 3 разных символа, которые выглядят как A в одно место. OTOH, будучи любителем свободы, я ненавижу запрещать что-то только потому, что никто не уверен, что кто-то может этим злоупотреблять.
Инго
Я полагаю, что склоняюсь к тому, что программы следует вводить либо в удобочитаемом формате, либо в формате, который не обязательно должен быть единым текстовым файлом (но может включать состояния, связанные со строками, аннотации, прикрепленные к вещам). , и т.д.). Я думаю, что важно знать, что «то, что вы видите, - по крайней мере, семантически, - что есть», и думать, что разные программы должны выглядеть по- разному. Если бы существовали стандарты, которые запрещали использование идентификаторов, которые были близки, но не совсем соответствовали идентификаторам в более близком объеме, это могло бы помочь.
суперкат
4

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

nikie
источник
8
На самом деле, нет. В строковых литералах не-ASCII символы могут рассматриваться как непрозрачные. С помощью идентификаторов вам необходимо принять решение о том, какие символы действительны и нужно ли их нормализовать (например, это так várже, как vár?)
dan04
4

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

Маркетинговые аргументы

Вы знаете этот сумасшедший список функций, которыми гордится большинство языков? В целом, это в значительной степени бесполезно, потому что это так далеко от языка, что он не дает много информации о конкретных, но он позволяет быстро одеть столы с галочками и крестиками и справедливо сделать вывод, что, поскольку X имеет больше тиков, чем Y, он должен будь лучше.

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

И поэтому они могут похвастаться: «Ах, с Y у вас нет поддержки Unicode для ваших идентификаторов! В X мы делаем, так что для студентов это намного проще!»

Ошибка доступности

К сожалению, аргумент о доступности ошибочен.

О, я понимаю, что возможность написать «résultatDuJetDeDé» вместо «diceThrowResult» (да, я француженка) может показаться победой в краткосрочной перспективе ... однако есть недостатки!

Программирование - это общение

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

  • чтение означает, что вы можете визуализировать символы, которые вы использовали, Unicode не так хорошо поддерживается всеми шрифтами
  • понимать это значит полагаться на идентификаторы - если вы не дополняете их длинными комментариями, но это нарушает правило СУХОЙ.

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

Программирование требует понимания

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

  • На каком языке написаны эти библиотеки?
  • На каком языке эти библиотеки документированы?

Если вы ответите на марокканском арабском, я буду удивлен.

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

Английский это...

... язык программирования (и большинство ученых).

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

Некоторые неизбежно выступят против этого и будут справедливо отстаивать свое право говорить на языке по своему выбору (обычно на материнском языке), однако, как показал Бабель, чем больше языков используется, тем труднее становится общение.

Все еще...

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

Так почему же?

Ну, как уже говорилось, дело не в удобстве пользователя, а в маркетинговых заявлениях. Это также очень просто, так как парсер уже знает о Юникоде для строк и комментариев, так что большинство делает скачок.

И это может быть полезным для определенных пользователей.

Но я лично буду иметь дело только с кодом, написанным с английскими идентификаторами. Мне все равно, нужна ли вам моя помощь с вашим фрагментом кода или ваша библиотека просто великолепна, и я мог бы многого добиться от нее: если я не могу понять ее, мне просто придется ее игнорировать.

Матье М.
источник
Таким образом, вы один из тех, кто хочет превратить исторические реалии де-факто в де-юре (простите за отсутствие акцентов, никому, кажется, сейчас все равно)?
Милинд Р
@MilindR: я один из тех, кто считает, что мир стал бы лучше, если бы все говорили на одном языке; и я достаточно прагматичен, чтобы рассматривать роль на английском, несмотря на то, что я французский. Я мог бы быть убежден, что подмножество Unicode могло бы быть полезным вообще (греческие буквы, для математики / физики). Я понимаю, что для преподавания программирования полезен язык программирования, на котором студент может выражать идентификаторы на своем родном языке; однако это не требует, чтобы все языки поддерживали полные идентификаторы Unicode. Это мое личное мнение, делайте из этого то, что вы будете :)
Матье М.
3

Как вы собираетесь вводить идентификаторы ASCII на китайской клавиатуре? Несколько языковых ключевых слов - это одно, а необходимость делать весь код таким образом - совсем другое.

Программисты должны иметь право и возможность называть свои переменные как угодно. Это не ваше дело, на каком языке это.

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

DeadMG
источник
4
Я набираю это сообщение, используя "русскую" клавиатуру. Я гуглил китайскую клавиатуру ( goo.gl/U1q0m ) и не вижу никакой разницы с русской ( goo.gl/af04R ). Заметьте, кстати, что оба они имеют латинское расположение наряду с родным.
Егор Тенсин
2
Допустим, я использую идентификаторы с использованием кириллицы. Но как насчет китайского сопровождения моего кода? Скажем, он знаком с латинскими буквами, но теперь он создан для работы с совершенно другим набором символов! Не говоря уже об арабских декоративных надписях и т. Д.
Егор Тенсин
2
Третий абзац - точная причина использовать только английский, не так ли?
Антон Барковский
9
@Egor: Это причина для команды или менеджера проекта, чтобы сделать правило. Но не повод для языка или реализации для его применения. Команда или компания всегда могут дополнительно ограничить идентификаторы - они не могут расширять доступный набор. Вот почему оригинальный набор должен быть максимально большим.
DeadMG
3
"Как вы собираетесь вводить идентификаторы ASCII на китайской клавиатуре?" - точно так же, как на английской клавиатуре, на самом деле. Вы выбрали плохой пример; Китайский (и японский) обычно вводятся как английские буквы, описывающие произношение, затем отображается список подходящих китайских / японских языков, из которых пользователь может выбрать правильный, если значение по умолчанию неверно (современные системы используют контекстный анализ, чтобы гарантировать, что он обычно есть).
Майкл Боргвардт
2

Согласно PEP 3131 - Поддержка не-ASCII-идентификаторов, датированных в 2007 году, первая часть Обоснования гласит:

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

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

吴 烜 _ 中文 编程
источник
1

Это действительно сделало бы жизнь проще (для некоторых из нас, так или иначе), если бы компилятор не поддерживал Unicode. Идентификаторы справа налево ужасны. Объединенные латинские буквы и идентификаторы Юникод справа налево еще хуже.

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

Юникод справа налево комментарии тоже могут быть забавными. Например, в VS 2010 комментарии XML отображаются (правильно) как RTL в коде ... но когда вы используете Intellisense для поиска идентификатора в другом месте кода, всплывающая подсказка отображает (неправильно) LTR. Может быть, лучше, если бы вообще не было поддержки? Опять не простой вызов.

sq33G
источник