Инженерная раскладка клавиатуры (Ручей)

Да, обе раскладки базируются на обычной русской «йцукен».

Отсюда: различия между русской «йцукен» и ручей кириллица минимальные, различия между английской «qwerty» и ручей латиница огромные.

Базовые отличия от «йцукен»:

• одинарная кавычка на цифре 2
• двойная кавычка на цифре 5
• процент вынесен на 3-й уровень
• все основные спецсимволы доступны или через Shift или AltGr

По сути основная раскладка - это ручей кириллица, а ручей латиница сделана для минимизации переключения контекста (спецсимволы в двух раскладках на одних и тех же местах).

различия между английской «qwerty» и ручей латиница огромные.

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

Есть ряд основных проблем:
Многобайтовость;
Неинформативность;
Отсутствие необходимых терминов.

Разработчики 1С с тобой не согласятся.

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

Да, ты прав. Огромные различия это если перечислять, что ушло на 3-й уровень, а так, различия между qwerty только в части спецсимволов, да и то, в целом, они на своих местах.

Из того, что с ходу не найти, это «~» (на цифре 8) и «`» (там, где точка). Кстати хомяка ~/ проще набирать, можно одной рукой.

Термины можно наработать. Многобайтовость — сразу ставим условие, что код программы сохраняется в UTF-16LE.

Проблема, скорее, в многословности — большинство IT-слов (и не только IT) в русском языке длиннее, чем английские аналоги. Человеку, не видевшему традиционных ЯП, зайдёт, видевший будет мучиться, «что ж так длинно-то, а»?

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

Например, в РАЯ академика Ершова пишут нач и кон, и это воспринимается уже не так «влёт», как begin и end в Паскале/Модуле/Обероне для англоговорящего. А уж всякие кнцклсс, которые предлагал den73, это просто хтонический ужас.

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

класс Фигура {
   повернутьВлево(целое градус) : пусто
   {
         ...
   }
}

класс Квадрат : Фигура
{
}

Квадрат квадрат();
квадрат.повернутьВлево(45);

Кто-то не понял результат? Это не красиво, не лаконично?

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

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

Ведь в итоге важна именно продуктивность явления, а не его соответствие трендам.

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

Например, в РАЯ академика Ершова пишут нач и кон, и это воспринимается уже не так «влёт», как begin и end в Паскале/Модуле/Обероне для англоговорящего. А уж всякие кнцклсс, которые предлагал @den73, это просто хтонический ужас.

Ну языки же тоже надо проектировать с умом. Уже давно обозначение блока традиционно делается {...} или отступом (в Python), зачем там «начало» и «конец» - непонятно.

А «конецКласса» - это та же попытка строить открытие-закрытие как в XML одним и тем же тегом. От этого тоже уже отошли даже в языках разметки. Тот же JSON или YAML демонстрируют тот же самый подход - либо {...} либо отступы.

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

И кстати, именно благодаря парным тегам XML читается понятнее, чем JSON. Присутствует не очень нужная для машины, но очень благотворная для человека информационная избыточность.

Бытовой английский знают все программисты, а вот английский из технических областей никто. Да какой там английский, на банальные вещи компетенции не хватает, кричат: «технолога нам технолога».

И кстати, именно благодаря парным тегам XML читается понятнее, чем JSON. Присутствует не очень нужная для машины, но очень благотворная для человека информационная избыточность.

Нонче ведь это решается средствами IDE. Подсветка, быстрые переходы по парным скобкам, всплывающая инфо.

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

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

Разупорись, всё ровно наоборот

часть вынесена на третий уровень и набираются при зажатом правом Alt (AltGr).

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

Мы все в нем, потому что лень двигатель прогресса.

Ну вы все, а я не все.

Кто-то не понял результат? Это не красиво, не лаконично?

Вот компилирующийся пример (на Racket ставится пакет russian-lang):

выбрать-имя-переменной строка =
  позиция1 = найти-в-строке строка "[["
  позиция2 = найти-в-строке подстрока(строка позиция1) "]]"
  если позиция2 тогда
    позиция2* = позиция1 + позиция2
    значения
      подстрока строка 0 позиция1
      подстрока строка $ позиция2* + 2
      подстрока строка (позиция1 + 2) позиция2*
    иначе
    значения ложь ложь ложь

найти-в-строке строка поиск =
  длина-поиска = длина-строки поиск
  количество-позиций = длина-строки строка - длина-поиска + 1
  если количество-позиций < 1 тогда
    ложь
    иначе
    цикл/первый
      для
        сдвиг $ длина-строки строка - длина-поиска + 1
        #:когда $ подстрока строка сдвиг (сдвиг + длина-поиска) == поиск
      сдвиг

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

Дали, например, ТЗ: «написать распределение общехозяйственных затрат на прямые затраты пропорционально выручке без ЕНВД».

В 1С будет просто

Функция РаспределениеОбщехозяйственныхЗатрат(ТаблицаЗатрат)
  ВыручкаБезЕНВД = ОборотЗаПериод(ПланыСчетов.Хозрасчетный.ВыручкаБезЕНВД);
  Результат = ТаблицаПрямыхЗатрат();
  Для каждого Строка Из ТаблицаЗатрат Цикл
     ДополнитьТаблицу(Результат,
         РаспределитьПоСумме(Строка.Сумма, ВыручкаБезЕНВД), Строка);
  КонецЦикла;
  Возврат Результат;
КонецФункции

Как будешь писать на английском?

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

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

Дали, например, ТЗ:

Буду использовать исходные английские названия экономических терминов. Мне эти термины почему-то кажутся переведенными надмозгом.

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

???

Это исходное ТЗ. Названия определяются законом о бухучёте РФ. Или будешь требовать от заказчика (бухгалтера) перевести всё ТЗ на английский язык?

Не по теме, но вдруг стало интересно, в России вообще производятся хоть какие-нибудь клавиатуры для персоналок?

возвращаясь к старой теме, код был такой:

function changeStudent ID Text(student ID){
        const studentNameLabel = getStudentName(studentID);
   }
function functionGetStudentName (studentID){
        const student = api.getStudentID (studentID);
        return student.name;

и вот что смог сказать о нём firkax после того, как я перевёл этот код на финский язык:

Да, понятно - тут две обёрточные функции. Но у них слишком длинные названия и код плохо отформатирован, неудобно

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

Как Вы считаете, смог ли firkax разобраться в смысле этого кода без финско-английского или финско-русского словаря? Или это ответ уровня «напряжометр»?

Без обид, я закостенел в ООП и С++ подобном синтаксисе. Я пишу на Java, С#, JS, иногда на C++ (Qt). Поэтому, да этот вариант мне нравится больше.

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

Спасибо, упустил этот ответ. У шрифтов обычно основная проблема - это авторское право. Плюс моноширинность не украшает шрифт. В ЯОС взят PT Mono со внятной лицензией и с отличиями О от 0. Кроме того, и движок отрисовки не идеален.

Была вообще-то мысль переделать вид текста на фигурные скобки, чтобы был похож на Go. С++ и Java менее чёткие (там порядок слов неправильный). Но в целом-то, если привыкнуть, то слова лучше. Фигурные скобки перегружены смыслами, например, в JS это и блок, и конструктор объекта. Кроме того, словами можно сделать так, чтобы конец if отличался от конца цикла - это способно защитить от неприятных грабель, когда меняешь код и случайно меняется и логика. Обычно это происходит там, где логика сложная и имеет неприятные последствия.

Ещё раз - в твоём коде показаны две обёрточные функции. Как они называются - не важно.

Функция «changeStudent» вызывает функцию «getStudentName» и сохраняет её результат в переменной (видимо локальной, то есть бесполезной но это я не знаю языка на котором код). Функция «functionGetStudentName» вызывает функцию «api.getStudentID» и в возвращённом ей объекте читает переменную «name». На этом всё. Больше они ничего не делают. Нет, они не получают имён студентов и прочее подобное, они только вызывают вложенную функцию. Что делает вложенная функция - неизвестно, пока нет её исходника. Как она называется - не важно.

Плюс моноширинность не украшает шрифт.

Технический (для разработки) шрифт должен быть моноширинным обязательно.

Твоё мнение понятно - ты разобрался. Но хотелось бы независимые мнения. Я бы мог, если бы мне было не лень, дописать рядом финский перевод функции GetStudentAge, и ты бы написал, что это ещё две обёрточные функции. А о чём они и про что - ты бы точно так же не сказал бы. Такой вот мысленный эксперимент. Но можно другой. Вот тебе таблица в базе данных. О чём она?

create table opiskelija 
  (id int not null primary key
  ,ikä varchar(256)
  ,sukupuoli varchar(256)
  ,etunimi varchar(256)
  ,sukunimi varchar(256)
  ,Luokka varchar(256)
  ,stipendi varchar(256))

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

select ikä, sukupuoli, etunimi from opiskelija where id = :id

Т.е. когда ты читаешь любую функцию, ты всегда игнорируешь её название, а смотришь только на то, что она вызывает, и так до атомов? А если это некое API, данное тебе как чёрный ящик, то тебе неважно, как называются функции в этом API? Т.е. что назови их getStudentName, getStudentAge, что назови их setTeacherRoom, setTeacherPhone, или просто function1, function2 - тебе без разницы будет и ты всегда смотришь только в документацию? А что делаешь, если API как чёрный ящик и документации вообще нет? Просто чтобы я понял, насколько ты серьёзно это сейчас пишешь.

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

По-моему ты мог бы и предсказать мой ответ - это таблица с primary key идентификатором и шестью строковыми полями каких-то данных. Запрос выбирает три из них.

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

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

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

Мне вообще не попадались ни student ни teacher ни в каком коде ни разу. А вот такое, что функцию нельзя применять наобум - предостаточно. Вот скажи, есть функция fprintf() которая, кажется, печатает что-то в файл. А как она себя поведёт, если ты её запустишь из мультитред программы параллельно? Выведет сначала одну строку, потому другую? Или перемешает их посимвольно? Или вылетит с ошибкой или крашем? Догадки по названию уже не прокатывают? Либо читай документацию, либо смотри исходник. Причём - именно по той библиотеке, которой ты пользуешься. В старых библиотеках межтредовых блокировок там не было, в новых обычно есть.

Впрочем я не знаю зачем ты вообще начал эту тему.

Нет, не игнорирую. на итог разбора это влиять не должно, только на скорость.

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

это таблица с primary key идентификатором и шестью строковыми полями каких-то данных

Я считаю, что ты не разобрался.

Мне вообще не попадались ни student ни teacher ни в каком коде ни разу.

А что попадалось? Можешь привести 10 сущностей, которые попадались?

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

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

Я считаю, что ты не разобрался.

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

А что попадалось? Можешь привести 10 сущностей, которые попадались?

Из последнего, если не считать собственного кода (вопрос ж не про него), то например так:

proc, thread, vnode, filedescent, componentname, hz, ticks, spinlock, rwlock, clock, mutex

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

void
kern_thread_cputime(struct thread *targettd, struct timespec *ats)
{
	uint64_t runtime, curtime, switchtime;

	if (targettd == NULL) { /* current thread */
		critical_enter();
		switchtime = PCPU_GET(switchtime);
		curtime = cpu_ticks();
		runtime = curthread->td_runtime;
		critical_exit();
		runtime += curtime - switchtime;
	} else {
		PROC_LOCK_ASSERT(targettd->td_proc, MA_OWNED);
		thread_lock(targettd);
		runtime = targettd->td_runtime;
		thread_unlock(targettd);
	}
	cputick2timespec(runtime, ats);
}

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

Обычно названия сущностей, как минимум, намекают на то, что эта сущность обозначает, хотя нюансы возможны. Даже если ты вынужден разбираться, что она делает, ты учишь нюансы и дальше для тебя название сущности является ключом, по которому вспоминаешь, о чём идёт речь. Если мы назовём proc, thread, vnode, filedescent, componentname, hz, ticks, spinlock, rwlock, clock, mutex именами e1,e2,e3,…e10, тебе вряд ли станет удобнее, Что делает твоя функция - я не знаю, т.к. она ссылается на иные неизвестные мне сущности. Видимо, замеряет время, в течение которого тред выполнялся, если тред передан. А что она делает, если передали NULL - я не знаю. Наверное, и в случае этой функции ты один раз разберёшься и запомнишь, что она делает, на это её название всё же как-то намекает. Если бы она называлась #x0754AB34, вряд ли тебе было бы легче запомнить её смысл.

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

Я ничего никуда не возводил, но в информационных системах поля, как правило, называются в соответствии со смыслом содержимого. Иное бывает, но для этого нужна какая-то веская причина. Из этого вовсе не следует, что я не буду смотреть код. Но опять же, это удобнее, чем назвать поля f1 … f6.

намекают

В этом вся суть. Не надо путать намёк и факт.

именами e1,e2,e3,…e10, тебе вряд ли станет удобнее

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

Видимо, замеряет время, в течение которого тред выполнялся, если тред передан.

намекает

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

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

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

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

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

Да они вообще не обязаны ничем, могут быть и цифрами. Вопрос лишь в цене - насколько быстрее ты запомнишь эти функции, если они будут названы словами известного тебе языка, близкими по смыслу к тому, что они обозначают. Уверен, что нет разницы между словами известного тебе языка и произвольными этикетками? Ладно, не 8-значные, но ведь понятий не так много, допустим, 10000. Почему бы не назвать их 4-значными цифрами? Они короткие и все отличаются друг от друга. Произносятся тоже по-разному.

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

Тебе всё равно, когда ты программируешь свои ядра, работать ли с тредами или со спинлоками? Для тебя они на вид так же мало отличаются, как opiskelija и etunami?

Программисту говорят: «нам нужно узнать средний возраст студента». Он знает, что в базе есть студенты и есть в них поле возраст, или дата рождения (это где-то в доке написано). Знает, как посчитать среднее. Но он заходит в базу, а там одни только sukunimi. Как в этом случае он решит свою задачу, игнорируя содержимое?

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

Для тебя они на вид так же мало отличаются

Это алгоритмически разные сущности.

Но он заходит в базу, а там одни только sukunimi. Как в этом случае он решит свою задачу, игнорируя содержимое?

Должна быть документация, что дата рождения хранится в поле birthday (ну или в каком-нить ещё). А без документации это поле может с тем же успехом означать дату создания записи (например в struct stat в юниксах есть поле st_birthtime - очевидно это не время рождения студента, чьи данные хранятся в этом файле, а время «рождения» файла).

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

Да, конечно имеет место тактика «посмотрим на название, предположим что там находится, пишем на этом основании какой-нить черновой код и оставим как есть раз работает»

Ещё есть идеология «чистого кода», где предписывается давать сущностями понятные названия. Даже в твоём kern_thread_time оно частично соблюдается, ведь назвали же не release_spinlock, а могли бы.

Далее. когда ты ищешь, «как бы мне узнать время, которое тред работал или которое провёл в ядре», ты открываешь API и ищешь именно по словам. Ты не полезешь в документацию функции release_spinlock в ожидании того, что она вернёт время работы треда. Хотя опять же, я не видел код, с которым ты работаешь, может у вас там принято всё шифровать. Такое бывает, я вот на работе недавно предлагал называть виды тестирования по номерам задач, но почему-то не прокатило, хотя я и сейчас считаю, что test_45621 - это лучше, чем test_from_sa_to_da_e2e_comparing_statistics, при том, что есть трекер, в котором 45621 расшифровывается во вполне чёткое описание того, что там делается, в то время как e2e и comparing_statistics имеют неоднозначности смысла, которые непонятны, пока не заглянешь внутрь. Пока трекер не продолбали, мой подход будет работать, и можно продублировать комментариями в начале скрипта - тогда будет работать, пока исходник не продолбали.

Естественно, всё это не означает, что по слову можно точно понять содержание функции. Но это и в жизни так. Представь себе, рядом с тобой стоит человек и говорит тебе «слева птичка». Если он стоит к тебе лицом, то неясно, в какую сторону смотреть. Сильно зависит от того, что это за человек. А если это какой-то чужак, то надо смотреть на него и ждать, что он собрался плохого сделать, а может и сразу бить уже пора. Тем не менее, «слева птичка» - это иная информация, чем «птичка сверху летит».

Неполнота передачи информации словами не отменяет их нужности.

По просьбе, автор в раскладку добавил ударение и символы валют €, ¥. Приме́р с ударе́нием XD.

Как-то эта тема прошла мимо меня. Надо будет попробовать.

О результатах напишете?