Шрифты с отличающейся кириллицей

протоколFtp

Идиотизм. Назвать ftp (ну или как там у вас принято в плане капитализации).

let серверFtp = запустиСетевойСервер(протоколFtp, порт = 21, обработчикЗапросовFtp)

Потому что в одном контексте может встречаться протокол ftp, сервер ftp, запрос ftp. Все их можно назвать ftp, но будет непонятно. Моду на чистый код придумал не я, но мне она нравится - названия должны чётко обозначать обозначаемое и быть однозначными.

Для меня 1С — это какой-то ад сам по себе, и вот не хочется трогать его что-то.

Ну вот ты предлагаешь запретить, а запрещать-то надо в контексте чего-то. Единственный массово применяемый на сегодня ЯП с кириллицей - это 1С, и твоё решение должно туда подходить. А monk сразу привёл контрпример, не знаю уж, намеренно или случайно. Если речь идёт про математику, то там тоже может быть смесь. Представим себе программу для ПВО на частном язычке, к примеру, РуСи от А.Н.Терехова-старшего, там будут ПВО-шные русские сочетания типа ЗПС (других не помню) и всякие там ускорения a в латинице.

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

Для меня существует. И кроме того, почему при копировании русскоязычных URL-ов в буфер обмена они уродуются до нечитаемости? А вот именно по той причине, что заметить подмену google.com на google.соm невозможно. Т.е. за избавление от этой проблемы (не опечаток, а «поприкалываться», т.е. угнать пароли и данные банковской карты) уплачена та цена, что неудобно иметь URL-ы в кириллице.

На самом деле есть нулевое решение: транлитерация. Также как в англоязычных программах пишем Spravka2NDFL, так и по-русски

• Тивишоу (тем более, что шоу — это уже транслитерация)
• протоколФТП
• УровеньПАш
• КоэффициентКей
• ФорумЛинуксОргРу

ЙЕ = эм це ^ 2 

Выглядит слегка пародийно, даже на общем фоне отношения ИТ-шников к русскому языку предлагать так сделать - это значит выставлять себя полными дурачками. Сколько меня не пытались троллить этим, я никогда не предлагал заменить математические обозначения типа sin и cos.

обратисьПоФТП('ftp://localhost')

Решение-то есть, но оно не лучше шрифта, т.к. создаёт проблемы на ровном месте, когда надо будет найти потом в программе все ссылки на понятие фтп в любой форме. Кроме того, есть кодировки, например, дорога E-115 или аэропорт SVO, которые транслитерировать чревато.

А в случае линукс.орг.ру ничто не мешает существовать одновременно linux.org.ru и линукс.орг.ру в одном пространстве имён, т.е. вместо того, чтобы сохранить информацию и сделать её видимой (как в шрифте), ты предлагаешь её потерять. Это уже путь к конкретным техническим проблемам - неуникальности ключа поиска.

Вообще, если это 1С, и там бóльшая часть кода на кириллице, с небольшими вкраплениями латиницы, то разве не лучше будет сделать наоборот?

Да, будет лучше. В моей сегодняшней практике латиницы больше, и кроме того, про кириллицу есть ясная идея, куда её стилизовать - под старину. Стилизовать латиницу куда? Под готику? Будет же совсем кошмарно с т.з. читаемости. Или под руны? Тоже сомнительно.

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

Опять же, пример из кода 1С: они не стали полностью избегать латинских букв.

Что хранится в переменной «протоколFtp»? серверFtp и обработчикЗапросовFtp — хорошие правильне названия (ну, насколько кириллические названия вообще могут таковыми быть), по ним понятно, что они означают. А вот что надо передать сюда первым параметром, я не понимаю. Какие значения принимает этот протоколFtp?

Стилизовать латиницу куда? Под готику?

Под математику. https://habrastorage.org/files/159/33a/59c/15933a59c0b946bb941150fc0cac9750.png

В учебниках математики и физики никогда не было проблемой отличить переменные a, b, c, d, e и x, y, z от русских букв. При этом русский шрифт нормальный.

Если серверFtp и обработчикЗапросовFtp - приемлемые названия, то неважно, что хранить в переменной протоколFtp, т.к. мне нужен был пример названия со смешением кириллицы и латиницы, который ты назовёшь приемлемым. И вот он есть.

В учебниках математики и физики никогда не было проблемой отличить переменные a, b, c, d, e и x, y, z от русских букв

Там они в другом пространстве имён и либо ясно из контекста, либо они набираются другим шрифтом. https://vpr-klass.com/gdz-class.ru/GDZ_matem/7kl_Geom_Pogorelov/img_3/23.jpg

Чтобы кириллицей называли математические сущности - я видел только у С.Камынина (забыл, как по батюшке), но он - фанат Бурбаки. И там были Ч и Щ.

Что хранится в переменной «протоколFtp»?

Например, объект содержащий методы для соединения и получения файлов. И имеющий общий интерфейс ПротоколСкачивания с объектами протоколHttp и протоколSmb.

набираются другим шрифтом

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

Я на это уже отвечал - IDE часто использует курсив для каких-то своих целей, поэтому место, куда надо пихнуть кириллицу/латиницу, может оказаться занято.

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

Но я всё равно считаю, что идея «запретить» гораздо лучше ;)

то неважно, что хранить в переменной протоколFtp

А мне интересно. Потому что я считаю это название крайне неудачным. Причём не из-за кириллицы. protocolFtp или ftpProtocol ничуть не лучше.

Тогда тебе monk уже ответил. Там могут быть метаданные, например, порт, метод конструирования сервера, что-нибудь для файровола и т.п. Или это может быть элемент перечисления, который просто показывает где-то в диспетчере соединений вид соединения. В лиспе принято делать большие пространства имён, к примеру, там будет протоколFtp и серверFtp жить в одном пространстве имён. Ну или в Си так может быть. В других языках будет перечисление «протокол» и в нём элемент протокол.ftp, и тогда действительно не нужно название протоколFtp.

Ну так почему такой объект не назвать ftp, http, smb, собственно? (серверFtp и обработчикЗапросовFtp при этом так же и оставить), ну или если они в этом объекте, то ftp.сервер, smb.обработчикЗапросов, не?

Просто по моему ощущению, в переменной protocol/протокол должно бы храниться что-то вроде названия протокола… А протоколFtp выглядит мало того как масло масляное, так ещё и как коэффициентk — удлиннение ради удлиннения с 0.0 новой информации. Вы там случайно не пишете итераторИспользуемыйВЦиклеДляИтерацииЗначенийОдноЗаДругим и дескрипторСущностиНазываемойФайломИЯвляющейсяИменованнойОбластьюДанныхНаДискеИлиВПамяти?

Но я всё равно считаю, что идея «запретить» гораздо лучше ;)

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

IDE часто использует курсив для каких-то своих целей

Для математики не курсив, а полукурсив. Хотя от курсива, конечно отличатся мало.

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

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

Но это оффтоп и холивар, если честно. Я сюда пришёл уж точно не критиковать «программирование на русском», особенно учитывая, что такова уж объективная реальность, что того же 1С порой никуда не деться. В рамках этой темы я согласен принимать это просто как данность. Есть такая проблема/задача, обсуждаем вариант решения, попутно предлагая альтернативные.

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

Да вообще-то все основные ЯП (от PHP до C++) на сегодня позволяют заводить идентификаторы в юникоде. Не знаю, кого там подавляющее большинство. И при этом нет никакого запрета на смешение алфавитов. Но да, холивар.

Там могут быть метаданные, например, порт

Ну так и назвать тогда портFtp?

метод конструирования сервера

Ну тоже назвать, как там у вас принято методы называть.

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

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

Тогда была бы переменная ИмяПротокола. А протокол — это набор действий. Вот он и хранится.

А просто ftp – как раз неясно что. То ли идентификатор протокола, то ли сам протокол, то ли вообще номер порта. Как в анекдоте «Приборы? 20! Что 20? А что «приборы»?»

итераторИспользуемыйВЦиклеДляИтерацииЗначенийОдноЗаДругим

Пишу ИтераторТаблицыНачислений, например.

1. Не хватает оформления окна под берёзовое бревно

2. Латиницу бы сделать готической как в средневековых письменах

3. Вообще-то – неплохо

Ну так и назвать тогда портFtp?

Так там не только порт, а «порт, метод конструирования сервера, что-нибудь для файровола». Предлагаешь вместо протоколFtp назвать портДоступНастройкиСетевогоФильтраFtp ?

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

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

Да вообще-то все основные ЯП (от PHP до C++) на сегодня позволяют заводить идентификаторы в юникоде.

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

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

Если же имеется в виду, что там некая конфигурация для Ftp, включающая в себя порт и метод и ещё что-то — ну так и назвать конфигурацияFtp, или метаданныеFtp, или как-то ещё, собственно отразив ЧТО именно там, блин, содержится. Не «например», а что должно.

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

Если написано протоколFtp.Скачать(Сервер, Адрес), то понятно, что скачается файл с сервера. А если конфигурацияFtp.Скачать(Сервер, Адрес), то выглядит, словно конфигурация свои данные как-то обновить хочет.

Можно назвать интерфейсFtp, например, если аллергия на слово протокол.

Если это такой объект со свойствами и методами, то я уже выше сказал, как лучше всего его назвать: ftp. Без всяких префиксов.

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

Если язык позволяет, значит, кто-то эту фичу запросил и продавил, чтобы она была сделана. Ты же пробовал отправить патчи в какой-нибудь OSS проект? У тебя всё получилось? А тут мы наблюдаем, что массово во всех ЯП такое было внедрено. Значит, эта фича реально многим нужна и разработчики ЯП считают её нормальной. Не один маргинал, а подавляющее большинство разработчиков. Тут дальше не хочется сползать в холивар, поэтому пора остановиться.

Если язык позволяет, значит, кто-то эту фичу запросил и продавил, чтобы она была сделана.

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

Значит, эта фича реально многим нужна

Да вовсе не значит. Никак это не следует из просто наличия какой-то возможности или отсутствия какого-то запрета.

и разработчики ЯП считают её нормальной

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

Во всяком случае, позиция разработчиков всех ЯП кардинально отличается от позиции «запретить смешение» и тем более, «запретить кириллицу».

PT Mono - с засечками, поэтому нет.

Какой следующий шрифт взять на раздербан? Хочу опробовать новые идеи. Droid Sans Mono?

Хочу опробовать новые идеи.

Вообще было бы очень круто прикрутить кириллицу к Monaspace. Классный шрифт с крутыми фичами уникальными, но не имеет кириллицы. Но вряд ли один осилишь…

Красивый шрифт, и, что интересно, вариант Ne понравился больше, чем Cr, несмотря на теорию о том, что засечки не нужны. Странно. Да, один вряд ли осилю. А ты используешь его в жизни?

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

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

> Готика нечитаема

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

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

1. Фрактура, которой они печатали, читаемее текстуры, которую обычно имеют в виду, когда говорят готика без уточнений.
2. Печатали они аналогово и на бумаге. На экране в 100 PPI читать код готическим шрифтом реально будет больно.
3. От неё таки отказались в пользу более читаемого шрифта. Как отказались и русские от устава и полуустава. И дело здесь не только в заморочках Гитлера, но и в том, что современные, более простые шрифты объективно читаемее.

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

А то что раньше кто-то печатал и ничего — не очень аргумент. Раньше и без пробелов печатали. Давайте откажемся от них — норм же было, читали.

CamelCase менее читаем в сравнении со snake_case.

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

Триграфы (англ. trigraph) в семейство языков C внедрены давно и плотно. Часто ты видел их использование в реальной жизни?

победитель конкурса шг

Софистика.

В Си не видел вообще,а в Паскале аналогичные по смыслу конструкции для замены {} на (* *) видел лет 35 назад на компьютерах Robotron 1715

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

А всем любителям русификации языков программирования желаю наткнуться на исходник с именами функций и идентификаторами на японском,иероглифами. Как ни странно- gcc это компилирует. Но даже видя строчку из десятка иероглифов в одном месте - совершенно невозможно на глаз идентифицировать ее в другом месте исходника. Я однажды так влетел,причем не особо давно,лет 5-7 назад. Софт был хоббийный и сам по себе написанный весьма неряшливо так как писал не профессиональный программист. Еще и иероглифы.

И еще замечание по поводу допустимости юникодных символов в исходниках. Видел где-то в недрах микрософтовской документации перечисление диапазонов «кодовых точек» юникода которые их компилятор допускает к использованию в именах функций. Там всё весьма сложно. Без изучения этой документации не получится сказать что компилятор пропустит,что нет,а на чем и взглючить может(«неочевидное поведение» случиться может).

А то,что компиляторы технически позволяют писать предельно неудобный для прочтения код - совсем не значит что надо так делать. Разве что для конкурса http://www.ioccc.org

Там всё весьма сложно. Без изучения этой документации не получится сказать что компилятор пропустит,что нет,а на чем и взглючить может(«неочевидное поведение» случиться может).

Без изучения документации вообще чревато что-либо делать со сложными объектами. Т.е. в чём мессидж замечания? «Я не осилил это, поэтому остальным надо это запретить»?

Кто это доказал? В процессе разработки шрифта накидали ссылок про понятие читаемости, пришлось проглядеть, чтобы не быть полным ламером в том, чем занялся. Человека можно приучить читать ДАЖЕ ТЕКСТ, НАБИТЫЙ КАПСЛОКОМ, и после определённой тренировки он будет читать такой текст так же быстро, как обычный человек читает текст, набранный прописными буквами. Дело в навыке. CamelCase компактнее, в случае русского языка это важно, поскольку слова длиннее. Если учесть время дополнительной прокрутки из-за удлиннения текста, то совершенно не очевидно, что окажется на круг более читаемым. Твои личные субъективные ощущения, основанные на твоих навыках - тоже не доказательство.

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

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

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

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