LINUX.ORG.RU

Сделать так, чтобы было легко отличать русскую «эс» (с) от латинской «ц» (c)

 , , , ,


0

1

Занялся решением вопроса неотличимости с от c. Вопрос решается двумя способами:

  • сделать кнопку, как в Яре, к-рая подчёркивает латиницу.
  • сделать шрифт

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

Соответственно, вопрос - куда добавлять глаза - в латиницу или в кириллицу?

Видеоролик с затравкой обсуждения

Первоисточник

И ещё вопрос - кто может это сделать? Мне нужно переделать все шрифты DejaVu, в общей сложности это до сотни глифов (не считал на самом деле). Или нужен доброволец, или нужен недорогой исполнитель, который за это возьмётся. Или… хотя бы дорогой исполнитель. На примере одной буквы я это сделал, т.е. в принципе, я могу это сделать и сам, но лучше пусть это сделает кто-нибудь другой.

Ряд ссылок на тему шрифтов, к-рые я накачал во время изучения:

Не, ссылок пока не будет, может потом… Куда-то делись.

Итог темы

Сделал режим подчёркивания латиницы, который можно отключить командой главного меню, http://вече.программирование-по-русски.рф/viewtopic.php?f=5&t=91&p=1571#p1571

Шрифт с отличающимся начертанием кириллицы можно попробовать сделтаь как-то так:

http://вече.программирование-по-русски.рф/viewtopic.php?f=2&t=268&sid=023381a8c0b0dacdc8c6735ac37aafe7&start=10#p1570

★★★★★

Ответ на: комментарий от den73

Я тут подумал, что мешанина из двух и более разных гарнитур в одном тексте всё-таки выглядит как-то уродливо.
А зачем вообще твоей чудо-системе различать идентичные глифы разных символов? Не проще ли автоматически переводить латинскую C в кириллическую С, как и всё остальное похожее, раз уж весь исходный код планируется трактовать как кириллицу? Зачем весь этот цирк с сохранением «латинскости»? Гулять так гулять...

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

blexey ★★★★ ()
Ответ на: комментарий от blexey

Конкретно A2 (Яос) может существовать как ОС на железе и как приложение под Lin и Win. Будучи приложением, оно обращается к соответствующим англоязычным API. У меня была идея использовать транслит для латиницы, чтобы creat и fopen записывалось как цреат и фопен. Нечто подобное в истории уже было (КОИ-7). Но тогда в такой системе нельзя будет сделать, скажем, англо-русский словарь.

Смесь гарнитур не всегда выглядит уродливо. Прямо на этом форуме сть

цитаты

и

фрагменты кода

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

И ещё

заголовки

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от den73

Конкретно для creat и fopen вообще не нужно как-то специально выделять их принадлежность к латинице, т.к. в них присутствуют явно видимые, чисто латинские глифы. Да и применяются они у тебя, как ты описал, только в каких-то отдельных местах кода.

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

blexey ★★★★ ()
Ответ на: комментарий от blexey

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

Но не суть, я сделал режим подчёркивания латиницы, который можно включить/выключить командой главного меню. Вот как выглядит подчёркнутый вариант:

http://вече.программирование-по-русски.рф/viewtopic.php?f=5&t=91&p=1571#p1571

Причём для этой рекламной картинки я открыл исходник своего сайта, как пример текста, где кириллица и латиница перемешаны. И оказалось, что у меня в словах «содержание сайта» ошибка - одно эс набрано латиницей.

Собственно на этом тему можно закрывать, но я сейчас добавлю в пост ряд ссылок про шрифты, к-рые я успел накопать. Это подходы к вопросу шрифтов с разных точек зрения. Видимо, чтобы стать шрифтовиком, нужно долго учиться. Может быть, где-то полгода-год на это нужно. Потому что там дофига разных аспектов и тонкостей.

den73 ★★★★★ ()

куда добавлять глаза - в латиницу или в кириллицу?

В кириллицу. Латинская «с» может быть с диакритикой и т.п. что будет перегружать внешний вид. Теоретически может даже конфликтовать с меткой.

no-such-file ★★★★★ ()

переделать все шрифты DejaVu

Все-то зачем? Достаточно только моноширинные, т.к. именно они в основном используются там, где критично отличие.

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

Проще всего получить представление о том, как шёл процесс и куда он пришёл можно здесь - там и картинки есть.

den73 ★★★★★ ()
Ответ на: комментарий от blexey

запретить ещё где-нибудь на уровне лексера сочетания символов из латиницы и кириллицы в одной лексеме, поскольку такая мешанина не даёт никаких преимуществ, а только создаёт проблемы при чтении кода глазами.

Примеры из 1С: ЧтениеXML, ЧтениеJSON, СоединениеHTTP, …

Я не хотел бы вместо этого писать ЧтениеИксЭмЭл, ЧтениеДжейЭсОН, …

И, наоборот, setИНН(), getИНН() в Java (потому что функции доступа к полю).

monk ★★★★★ ()
Ответ на: комментарий от monk

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

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Не очевиден. Потому что в англоязычных языках программирования для таких ситуаций принят транслит: getINN(), printOborotnoSaldovayaVedomost(), …

И в обратную сторону ЯРГТ, ПОЯ (DSL), ЦЧВП (REPL), ИСР (IDE), …

То есть вместо ЧтениеXML, ЧтениеJSON, СоединениеHTTP должны быть ЧтениеРЯР, ЧтениеООД и СоединениеГТТП.

monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Мда, как-то не подумал, что оригинальные названия сущностей обязательно нужно пихать в идентификаторы на другом языке.
Привык, что обычно хватает чего-то вроде Чтение(XML), Чтение(JSON) и т.п.

blexey ★★★★ ()
Ответ на: комментарий от blexey

Кстати, на самом деле можно разрешить многоалфавитные идентификаторы только ограниченного вида. Например, через подчёркивание. Допустимо: чтение_XML, www_адресКорабля_長征, цвет_IDE. Недопустимо: чтениеXML.

Остаётся, правда, проблема с идентификаторами типа язык_1C / язык_1С, PEP / РЕР и однобуквенными.

monk ★★★★★ ()
Ответ на: комментарий от monk

Фрилансеры (лидеры по шрифтам) запросили от 20 тыр. Моя жаба пока одобряет 10.

den73 ★★★★★ ()
Ответ на: комментарий от den73

Ну можешь попробовать разницу собрать на бумстартере каком-нибудь. Пару тысяч могу задонатить лично.

hobbit ★★★★★ ()
Ответ на: комментарий от den73

Я что-то пропустил. Что мешает просто поднять все русские символы на 5% (не только совпадающие или строчные)?

По-идее, можно даже программно при выводе.

monk ★★★★★ ()
Ответ на: комментарий от monk

Что мешает просто поднять все русские символы на 5% (не только совпадающие или строчные)?

Я попробовал опустить всю латиницу на 15%, но нужно приглядываться, чтобы увидеть разницу.

den73 ★★★★★ ()
Ответ на: комментарий от den73

Я попробовал опустить всю латиницу на 15%, но нужно приглядываться, чтобы увидеть разницу.

Попробуй +10%, -10% от базовой линии. Между ними будет 20%.

monk ★★★★★ ()
Ответ на: комментарий от monk

Ты имеешь в виду поднять по высоте или увеличить размер?

den73 ★★★★★ ()
Ответ на: комментарий от den73

По высоте. Оставляем моноширинный шрифт.

<span style="position: relative; top: -0.1em">Просто</span>cat
monk ★★★★★ ()
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от monk

Тогда надо, видимо, слегка понизить все буквы (т.е. уменьшить их высоту), иначе не поместятся. Надо попробовать. Единственное, когда это не сработает - это если будет посреди страницы одинокое «ТО».

den73 ★★★★★ ()
Ответ на: комментарий от monk

запретить ещё где-нибудь на уровне лексера сочетания символов из латиницы и кириллицы в одной лексеме

такая мешанина не даёт никаких преимуществ

Примеры из 1С: ЧтениеXML, ЧтениеJSON, СоединениеHTTP

ну, это же всё время нужно раскладку перелючать, что и приводит к проблемам с неправильной C.

Я не хотел бы вместо этого писать ЧтениеИксЭмЭл, ЧтениеДжейЭсОН

А не хотел бы печатать переключая раскладки, одной латиницы мне достаточно. Но я не ТС. Уверен, ТСу больше по душе ЧтениеРЯР, ЧтениеОНЯС, СоединениеППГТ.

dsxl ()
Ответ на: комментарий от dsxl

Уверен, ТСу больше по душе ЧтениеРЯР, ЧтениеОНЯС, СоединениеППГТ.

Нет, я считаю, что внедрение РЯ должно улучшать программирование, а не ухудшать. Невозможно взять и вытеснить все англоязычные аббревиатуры типа html или DOM. Проблема раскладки решается другим способом. кроме того, в тексте есть не только лексемы ЯП, а ещё и имена файлов и прочие сущности, где невозможно написать какой-то подсказчик, способный всегда понять, что правильно, а что опечатка. Равно как и избежать смешения букв разных языков в рамках «лексемы», если эта лексема - строковый литерал.

В общем, такое решение неортогонально и уже поэтому оно плохо.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

Лучше межстрочный интервал увеличить. Проще и красивее.

Единственное, когда это не сработает - это если будет посреди страницы одинокое «ТО».

А в этом случае есть разница, на каком это языке?

monk ★★★★★ ()
Ответ на: комментарий от den73

Дописываешь к строке одну букву и всё видно. Или можно страницу разлиновать фоном.

monk ★★★★★ ()
Ответ на: комментарий от den73

Невозможно взять и вытеснить все англоязычные аббревиатуры типа html или DOM.

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

Нет, я считаю, что внедрение РЯ должно улучшать программирование, а не ухудшать.

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

dsxl ()
Последнее исправление: dsxl (всего исправлений: 1)
Ответ на: комментарий от dsxl

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

Её придётся переключать крайне редко. И проще переключать раскладку клавиатуры, чем переключать языки мышления в голове и переводить из терминов предметной области (русские) в термины языка программирования (английские). Если же считать нормой транслит, то никто не мешает писать ХТМЛ, ДОМ, ХТТП, ЖСОН, …

monk ★★★★★ ()
Ответ на: комментарий от dsxl

Если делит на ноль, то концепция становится бесконечно большой. Что ж, неплохо.

Про переключение раскладки есть приемлемое решение, https://программирование-по-русски.рф/яролит.яргт/ , я им на практике пользовался. Русскоязычный лисп никогда не планировался, планировалось кастовой общество и более простой язык на базе лиспа. Но это уже давно похоронено. Нужно, конечно, использовать родной язык, но заимствованные понятия никуда не денутся - это показывает практика русификации медицины, морского дела, строительного дела, военного дела, машиностроения. Все эти отрасли изначально были иностранными и на русском о них вообще нельзя было говорить. А сейчас всё это можно. В программировании нужно сделать то же самое, если Россия собирается вообще существовать дальше.

Но не нужно доводить это до маразма.

den73 ★★★★★ ()
Ответ на: комментарий от monk

Её придётся переключать крайне редко.

И ошибки, связанные с С в неправильной раскладке тоже редко, но будут. То есть класс проблем остаётся.

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

Ну, я вот на английском думать уже привык. Можно, конечно, порассуждать на тему того, как оно долно быть для тех, кто осваивает профессию с нуля (то есть для школьников, птушников и студентов). Хотя лично я сомневаюсь, что для них СоединениеHTTP будет чем-то лучше, чем СоединениеППГТ.

Если же считать нормой транслит, то никто не мешает писать ХТМЛ, ДОМ, ХТТП, ЖСОН

Допустим, мнеэто удобнее, чем ГТЯР, ОМД, ППГТ, ОНЯС. Но, опять же, только для тех, кто знает, что такое HTML, DOM, HTTP и JSON. А для этих и ConnectHTTP скорее всего будет удобнее, чем СоединениеХТТП.

dsxl ()
Ответ на: комментарий от dsxl

HTTP - это самый ад. В 1С есть предметная область, все вот эти проводки, сальдо и проч. Я вот по сей день не знаю, как будет проводка по-английски, хотя я их программировал. То же касается и множества других предметных областей - будь то медицина, строительство и проч. Предметная область должна быть по-русски.

Какие вообще есть группы слов по смыслу в программировании?

  • ключевые слова ЯП - их совсем мало
  • общепрограммистское (массивы, треды и проч) - здесь, думаю, большинство понятий двухъязычные и всем пофигу.
  • предметная область разработки - здесь использование английского наиболее бесполезно, и наиболее вредно. Если их начать переводить на английский только ради того, чтобы меньше переключать раскладку, это снизит понимание между участниками процесса разработки, а его и так всегда не хватает.
  • сетевые - вот тут начинаются все вот эти http, которые есть не просто слова, а протоколы, которые нужно буквально вбивать, например, в браузер. Если их попытаться русифицировать, мало назвать в программе http как ГТТП, нужно ещё заставить тот же гугл, чтобы можно было заходить на сайт через этот гттп://www.linux.org.ru - а это уже задача, где успех зависит не только от нашего усердия. Даже допустим, мы сделаем «свой скрепный интернет», всё равно понадобится шлюз в «их радужный интернет», чтобы хотя бы собирать разведданные. Поэтому не стоит надеяться на то, что удастся полностью перейти на одну кириллицу в программировании в сколько-нибудь обозримом будущем.

Частота переключения раскладки зависит от того, сколько каких слов. Худшая ситуация - то 50/50. От этой середину нужно уходить к экстремуму, и сейчас все уходят к 100% английских/0 русских. Если мы русифицируем ключевые слова, общепрограммистсткие термины и предметную область, то остаются все вот эти http и в большинстве применений их останется достаточно мало. Т.е. мы приблизимся к 0% английских/100% русских, но никогда этих 100% не достигнем. Для остатка английских-то и нужен отличающийся шрифт. Как пример - в 1С большинство слов, думаю, всё же на русском, но http тоже встречается и работать с ним надо.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 6)
Ответ на: комментарий от den73

практика русификации медицины, морского дела, строительного дела, военного дела, машиностроения

Ну, в большинстве случаев дело ограничивается использованием заимствованных слов. То есть таких, которые пишутся кириллицей, но читаются примерно как оригинал из другого языка, например, штангенциркуль. Хотя в медицине, например, есть «вставки» на латыни. Но это было придумано в те времена, когда проблема переключения раскладки отсутствовала вместе с самими клавиатурами печатными машинками.

Все эти отрасли изначально были иностранными и на русском о них вообще нельзя было говорить. А сейчас всё это можно. В программировании нужно сделать то же самое

То же самое – это СоединениеППГТ

не нужно доводить это до маразма.

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

А вот шрифты с разными начертаниями – это и есть маразм.

(Это, конечно, при условии, что пытаться программировать на русском это не маразм, но это мы примем как аксиому)

dsxl ()
Ответ на: комментарий от dsxl

Как по мне, так лучше сделать систему, где можно полностью всё делать на русском

Ну я именно такую систему и делаю, но она сейчас-то на английском, и перевести её одномоментно нельзя. Были идеи взять и жёстко все переписать транслитом на уровне кодировки, объявив латинский алфавит подмножеством кириллического, в духе КОИ-7. Но в такой системе тогда понадобится делать отдельный диапазон для латиницы, иначе будут проблемы с приложениями типа англо-русского словаря.

Кроме того, это всё равно является большой технической проблемой, т.к. там уже есть 3 представления юникода - UTF8 для интерфейса с линуксом, UTF16 для интерфейса с офтопиком и UCS2 для внутреннего представления текста. В этом случае одномоментно можно только сломать, и получить на выходе кирпич.

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

Ну и без интерфейсов к тому же вебу система слегка напоминает сферического коня в вакууме.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от den73

понимание между участниками процесса разработки

ну, по-хорошему, кодер всё равно не обязан понимать предметную область (1с это исключение) и нужен человек, который разберётся, что нужно пользователям на языке пользователей, и объяснит задачу программистам на языке программистов. Типа бизнес-аналитик. При чём он будет переводить скорее всего с русского на русский.

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

Переводить должен бизнес-аналитик, а ему и так проф деформации не избежать.

мало назвать в программе http как ГТТП, нужно ещё заставить тот же гугл, чтобы можно было заходить на сайт через этот гттп://www.linux.org.ru

Ну, гугл ты не заставишь, а вот яндекс или майл ру - запросто. А ещё нужен православный русский браузер. И вводить не как ты написал, а «ппгт://ввв.линукс.орг.ру»

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

Потому разведчиков и учат иностранным языкам и засылают на территорию противника. В нашём случае – в бездуховную всемирную паутину.

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

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

Т.е. мы приблизимся к 0% английских/100% русских, но никогда этих 100% не достигнем.

Для остатка английских-то и нужен отличающийся шрифт.

Вот любопытно. Мы оба понимаем, что полностью искоренить английский язык из программирования нереально. Но ты всё равно хочешь притащить русский, переключать раскладку и изобретать костыли для начертания латинских букв. Когда читаешь/слышишь фразу «программирование по-русски,» то думаешь, что там только русский, а не русский со вставками на английском, не так ли?

dsxl ()
Ответ на: комментарий от dsxl

Точно также латынь нельзя полностью исключить из медицины, однако русификацией медицины занялась ещё Екатерина Великая, и где-то к середине XIX века в целом медицина в России уже была на русском языке. То же касается абсолютно всех областей деятельности.

Что такого особенного в программировании, кроме вот этих вот http? Это тоже область деятельности. Остальные виды деятельности все до одной были русифицированы. Т.е. раз за разом, разные правители, принимали именно решение о русификации данной области деятельности.

Значит, это соответствует выгоде нашей страны. То, что нынешнее руководство России для этого делает слишком мало, можно объяснять по-разному, но можно действовать хотя бы в инициативном порядке.

Кроме того, если русский язык вообще нужен и ценен, то его область применения нужно расширять. А сейчас она за счёт компьютеров, наоборот, сужается.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от dsxl

ну, по-хорошему, кодер всё равно не обязан понимать предметную область

Я думаю, что это плохой кодер. Разделение труда, конечно, классно, но любой специалист должен понимать тех, с кем он смежничает.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Что такого особенного в программировании, кроме вот этих вот http? Это тоже область деятельности. Остальные виды деятельности все до одной были русифицированы.

Я-то согласен что ничего. Вопрос как раз в http и прочих англоязычных аббревиатурах. Чем они такие особенные и почему нельзя их перевести на русский язык точно так же, как ты перевёл ключевые слова? ППГТ ничем не хуже твоих кн или суть.

dsxl ()
Ответ на: комментарий от den73

раз за разом, разные правители, принимали именно решение о русификации данной области деятельности.

Значит, это соответствует выгоде нашей страны.

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

Einstok_Fair ★★★ ()
Ответ на: комментарий от dsxl

ну, по-хорошему, кодер всё равно не обязан понимать предметную область (1с это исключение) и нужен человек, который разберётся, что нужно пользователям на языке пользователей, и объяснит задачу программистам на языке программистов. Типа бизнес-аналитик. При чём он будет переводить скорее всего с русского на русский.

Вот сайт, на котором мы находимся. Описание от аналитика: «должно быть изображено поле Заглавие, окно Сообщение, снизу должны быть кнопки с надписями Поместить, Предпросмотр, Отменить, выполняющие действия». Смотрим в код: поле title, окно msg, кнопки submit, preview, cancel. Кто должен решить, что Сообщение — это msg (а не message, не post, не item)? Или Заглавие — это title, а не heading.

И самое неприятное, когда другому программисту надо что-то дописать. Ему же тоже ТЗ дают в стиле «после поля Заглавие добавь текущую дату». И ему приходится искать, как предыдущий программист это Заглавие назвал.

monk ★★★★★ ()
Ответ на: комментарий от monk

Допустим, вся программа написана на русском и задание состоит в том, чтобы переименовать «Заглавие» в «Заголовок». Ну, я бы взял и просто заменил текст подписи вместо того, чтобы рефакторить всю программу и создавать конфликты с изменениями других разработчиков.

После этого для задачи «после поля Заголовок добавь текущую дату» всё равно придётся искать, как предыдущий программист этот заголовок назвал (заглавие).

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

dsxl ()
Ответ на: комментарий от dsxl

А ещё нужен православный русский браузер. И вводить не как ты написал, а «ппгт://ввв.линукс.орг.ру»

ппгт://ппп.линукс.орг.ру

monk ★★★★★ ()
Ответ на: комментарий от dsxl

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

В англоязычном часто встречается в коде heading, а на экране title?

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

monk ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

А глобально для человечества выгоден единый язык.

Куда делась латынь? Почему существует блатная феня?

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от Einstok_Fair

А глобально для человечества выгоден единый язык.

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

Единый язык программирования ещё больше выгоден, но перспектив нет.

monk ★★★★★ ()
Ответ на: комментарий от dsxl

Работа программиста - оперировать с сущностями. Так же, как работа землекопа - кидать лопаты земли. Если у тебя две сущности (heading и заголовок), то тебе нужно за те же деньги кинуть две лопаты земли, а не одну.

den73 ★★★★★ ()
Ответ на: комментарий от monk

В англоязычном часто встречается в коде heading, а на экране title?

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

необходимость держать два контекста в голове

Один - кодерский, другой - бизнес-специфичный, да? Русский язык не решает проблему «перед-нос, зад-корма»

dsxl ()
Ответ на: комментарий от den73

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

dsxl ()
Ответ на: комментарий от dsxl

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

В этом случае у программиста будет стимул при ближайшей переработке программы всё привести в соответствие, а не писать в документации «сахар в банке из-под кофе с надписью соль».

monk ★★★★★ ()
Ответ на: комментарий от monk

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

В общем, это так не работает.

dsxl ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей