Изначально мне просто ради спортивного интереса захотелось построить похожую на ASCII 7-битную таблицу символов, включающую весь русский алфавит, 10 цифр и все знаки пунктуации из переносимого набора символов стандарта POSIX. В процессе все больше всё больше выяснялось, что такая таблица гораздо удобнее ASCII из-за чёткого определения её подразделов. Я знаю, что есть Юникод, но здесь рассматривается именно возможность однобайтового кодирования. В процессе создания находились дополнительные преимущества, таблица много раз полностью переписывалась, появились управляющие символы, далее представлен один из получившихся конечных результатов.
В чём же преимущества? Разберём по частям.
1. Очевидно, литеры в полном составе занимают всю вторую половину таблицы. Не хватило места только для буквы Ё, не критично, все давно привыкли к её особому статусу «дальнего родственника», хотя лично я вынес бы из списка твёрдый знак Ъ, непонятно зачем оставленный лингвистами вместо более нужной Ё. Но такое решение будет совсем бунтарским, поэтому, как в ISO 8859-5 и Win-1251, ей отведено место отдельно от алфавита, заглавный и строчный вариант в соседних ячейках. Без этой хорошей буквы русский алфавит состоит из 32 букв, добавив второй регистр, получаем 64 символов, или 2^6. Таким образом, один бит может определять, является ли символ буквой и применим ли к нему средний регистр (о котором позже). Как положено настоящему буквенному ряду, он идёт в алфавитном порядке, при этом сначала все строчные, затем все заглавные. Почему не наоборот, скажу после, сейчас главное, — что благодаря степени двойки границы обоих алфавитов совпадают с границами строк шестнадцатеричной таблицы, а это просто замечательно. Двоичный индекс каждой буквы в массиве равен числу последних 5 битов на кодовой странице, регистр определяется шестым, а сама буквенная природа символа — седьмым.
2. В первой половине множество не-букв так же поделено надвое, причём дважды: здесь действует та же адресация, и добавлен дополнительный регистр, я назвал его «средним». Верхнюю строку занимают управляющие символы, здесь они прописаны на русском, потому что что наличие латиницы в православной русской картинке вопреки всем правилам выглядело топорно. Их назначение не важно, я не мастер ассемблера и тем более машинных команд. С момента создания ASCII технологический прогресс ушёл далеко вперёд, и большинство управляющих символов 70-х более не актуальны. С такой кодировкой не смогут работать телетайпы и многие коммутаторы, но для использования компьютера с современной архитектурой 16 команд вполне достаточно, если нужно ещё, в конце специально отведена специальная команда «УПР», при получении которой устройство иначе воспримет следующий байт.
Если кратко: ПУС — \0, БИП — \a, НАЗ — \b, ТАБ — \t, НОВ — \n, АБЗ — \v, ПОД — \f, ВОЗ — \r, РАЗ — пробел, КОН — сигнал об окончании, СТО — команда остановки, ВЕР — верхний регистр, shift, ФИК — фиксировать регистр, caps lock, АЛЬ — средний регистр, альтернативное назначение литер, alt, ОТМ — отмена, esc, УПР — управление, начало команды, ctrl. Команды отобраны не самые лучшие, в частности, нет нужной команды ДЕЛ — delete, запроса отклика процесса, но УПР решает вопрос. К тому же, в данной статье не рассматриваются тонкости работы процессора. Важно, что набор управляющих символов целиком расположен в первой строке и соответствует стандарту POSIX. Для управляющих команд не действуют регистры, первые 4 нулевых бита в начале отключают любые переключения остальных.
3. На вторую строку действуют два регистра. Первый, верхний, меняет значение третьего бита слева с 0 на 1 и переводит чтение на четвертую строку. Второй, средний, меняет третий и четвертый биты и переводит на третью. Можно поменять вторую строку с четвертой, тогда «средний» регистр назовётся скорее «нижним», а переключение будет осуществляться одной подменой. Но я расставил строки так как расставил для лучшей читаемости. Для неё же, кстати, левую половину 3 и 4 строк занимают арифметические знаки, а правую — пунктуация. Если кто-то решил с особой тщательностью рассмотреть таблицу, уже заметил отсутствующие в ASCII полезные символы ¬ (логическое НЕ, весьма нужная вещь) и ¤ (знак валюты, для финансовой документации), а ещё родная буква Ё, скрытая без определенной клавиши и два резервных знакоместа.
Порядок символов в строке также имеет значение: один столбец — одна клавиша. То есть, кодирование клавиш клавиатуры полностью соотносится с таблицей. Да, механическая раскладка клавиатуры здесь обычная, но функциональная тоже своя, дело в том, что стандарт QWERTY был разработан для максимального замедления печати. В 1870-х ещё не существовало метода слепой печати, а пишущая машинка Ремингтон 1 уже успели приобрести коммерческий успех. На её предшественниках не было единой раскладки, и при работе на них часто происходило сцепление рычагов друг с другом. Кристофер Шоулз постоянно экспериментировал, стараясь как можно больше нагрузить мизинцы и замедлить скорость печати текста, тем самым предотвратив сцепление. Часто используемые буквы и знаки препинания оказались труднодоступны. С тех пор реалии изменились, современные клавиатуры не страдают механическими болезнями, а стандарт остался, ведь переучиваться печатать на новой раскладке — все равно что поставить клавиши фортепиано в обратном порядке. Впрочем, альтернативы всё же существуют, например, раскладка Дворака. Русская раскладка изначально проектировалась, основываясь на десятипальцевом методе, нам повезло больше. Но знаки препинания всё равно частично унаследовали QWERTY, а запятая и вовсе оказалась в верхнем регистре. В клавиатуре представленной в статье кодировки цифровые клавиши, а потому и знаки арифметики и пунктуации, идут слева направо, При этом учитывается частота их использования.
Возвращаясь к открытым вопросам, вот почему заглавные буквы следуют после прописных, — команда ВЕР опускает нас на две строки ниже для всех строк, кроме первой. Поскольку адресация знаков 3 и 4 строк происходит через регистры второй строки, для них повторное применение регистра обычными методами невозможно (клавиша shift или alt либо нажата, либо нет, увеличение давления пальцев сверху бесполезно). Большую роль играет и восприятие правила: если третий бит слева равен 0, — значит регистра нет, 1 — включен верхний регистр, маленькие буквы сменяются большими.
Благодаря этим правилам, таблицу можно восстановить по памяти буквально после первого прочтения, а свойства попадающего в поток нового символа определяются уже при считывании первых битов, что можно использовать для значительного увеличения производительности. Вряд ли эта кодовая страница найдёт какое-либо применение, программисты всего мира давно привыкли к английскому, а для обычных пользователей существует Юникод, над фундаментальным программированием и архитектурой ПК — работают американские корпорации. Данная статья носит чисто неформальный характер, хотя шустрый интерпретатор ЯП высокого уровня (да и низкого тоже) на русском всё же можно создать. А для ещё большей производительности, в ущерб удобочитаемости, представляю второй вариант таблицы, где средний регистр определяется одним четвёртым слева битом, и оба регистра включаются нулём, а не единицами.
Комментарии (95)
2che Автор
20.02.2018 18:35Спасибо за критику. Да, числовых показателей нет по причине школьного уровня, сейчас изучаю архитектуры ПК. А принцип, по которому планируется увеличить быстродействие — определение свойств получаемого в поток символа одновременно с чтением первых 4 бит (благо букв 32) + простая переадресация, в большинстве случаев по одним и тем же правилам. Например, за командой о верхнем регистре одинаково последует переключение 3 бита. В любом случае, будут точные данные и интересный поворот темы, — отпишусь.
aamonster
20.02.2018 19:25+2Ускорение интерпретации/компиляции программы? Неактуально. Лексический разбор (или как его там) — "дешевле" даже чтения программы с диска.
А если уж вернуться в 1980-е — то надо не регистрами играть, а слова укорачивать (вспомните старые бейсики: там оператор — один символ, на спектруме даже вводился одной клавишей).
4eyes
20.02.2018 19:25+1Если вы под производительность имеете в виду скорость работы программ — то наилучшая производительность будет у кода, который не на русском или английском, а переведен в инструкции процессора. Этот процесс называется компиляцией. Компилирующие языки программирования делают это после написания программы перед исполнением, 1 раз, конечно. Интерпретирующие могут делать это по надобности для тех участков кода, которые сильно «нагружены».
В любом случае, ни русского, ни английского языка в инструкциях, выполняемых процессором (для коммерческих языков программирования) нет.
Что касатеся системы команд процессора, которая представляет собой что-то вроде языка, описывающего, к примеру, какие биты должны быть выставляены в команде для того, чтобы она считалась операцией сложения, а какие биты отвечают за указание оператндов — вот там скорее всего использутся похожие оптимизации.
У Intel, к примеру, есть manual на 10 томов по 2000+ страниц по этой теме: software.intel.com/en-us/articles/intel-sdm
У AMD, ARM и прочих, несомненно, тоже должны быть.
Varim
20.02.2018 18:35+1Программирование на кириллице может повысить производительность
Может повысить производительность чего?
TimsTims
20.02.2018 18:38Производительность производительности :)
Если серьезно, то т.к. в статье очень много внимания уделяется регистрам и их переключению, то очевидно имелось ввиду прозводительность процессора. Точнее говоря, насколько я понял — компилятора программ, который будет быстрее считывать поступающие символы...
Перечитал еще раз статью, вообще ничего не понял, что имел ввиду автор.
upd попытка №3: автор сделал свою кодировку, по типу 1251, где вся кириллица будет представлена 1-байтово + автор проанализировал самые частоиспользуемые символы, и вывел их из 2х байтовости — тоже сюда в свою раскладку. Типа «здесь всё что нужно для русского языка в однобайтовой таблице»TimsTims
20.02.2018 18:46И вот в чем производительность:
свойства попадающего в поток нового символа определяются уже при считывании первых битов, что можно использовать для значительного увеличения производительности
Varim
20.02.2018 18:52+2Ага, но по прежнему непонятно для увеличения производительности чего. Да еще и значительно, как будто CPU считывает биты последовательно.
ToshiruWang
21.02.2018 10:59А представьте что это передача — очень затратна через что-нибудь очень сложное (
квантовую запутанность) и вот уже после первых двух бит мы можем стоять на низком старте "да, хозяин" (но всё ещё не понимать зачем), а враги всё равно не догадаются, ибо кириллица.Zenitchik
21.02.2018 16:00Где-нибудь в микроконтроллерах?
ToshiruWang
21.02.2018 17:08Не особо уверен в существовании современных микроконтроллеров, в которых это даст выигрыш. Это был скорее сарказм (или что похуже).
4eyes
20.02.2018 19:02+1Интерпретатора бейсик-подобного языка, наверное. Я серьёзно.
Теперь для того, чтобы привести символ в верхний регистр достаточно одной операции:верхняя_буква = буква И бит_верхнего_регистра
В отличие от существующих для ASCII решений здесь нет ветвлений, что положительно скажется на предсказании переходов процессором, код отлично параллелится (можно даже на GPU приводить к верхнему регистру, в отличие от ASCII, т.к. GPU не любит ветвления) и не засоряется кэш процессора таблицейсимвол нижний_в_верхний[256]
У автора впереди много интересных открытий, вроде индейского ритуала определения того, является ли данное занятие выражением грубинных стремлений сердца его, а так же: компиляторов, машинного кода и прочего, но по-моему, это забавно и как минимум — неплохая разминка для мозга.2che Автор
20.02.2018 19:22-2Регистр — не ключевая фигура. Важнее четко определенные свойства каждой строки таблицы, как вы сказали, нет лишнего ветвления. Если символ в бинарном коде начался с единицы, компилятор/интерпретатор уже знает, что рассматривать его следует только как литеру, а не как арифметический или управляющий знак. Спасибо за мотивацию, будем учиться и изобретать.
4eyes
20.02.2018 19:42+1Справедливости ради, это было что-то вроде иронии. Скоростной парсинг текста на GPU скорее всего не нужен, или нужен в крайне редких задачах. Я таких придумать не могу.
К примеру, у меня дома дохлый CPU (рекомендованная цена $80 в рознице, с учетом коробки, транспортировки и зарплаты всего персонала магазина), использщуемый в HD-плеерах, может перемножить со сложением (скалярное произведение, если что) 1 килобайт вещественных чисел на 4.5 гигабайта таких же чисел за 1 секунду.
С какой скоростью он будет обрабатывать текст в какой бы то ни было кодировке? С такой же, т.к. скорость ограничена скоростью передачи данных их памяти в кишки процессора.
Чем быстрее он обработает текст (в моем случае — числа) тем… Тем больше он будет ждать поступления из памяти новой порции данных.
Т.е. в целом, вы идете по тому пути, который когда-то давным-давно прошли инженеры при проектировании процессоров. Должно быть интересно и забавно, как игра и головоломка. Но на всякий случай, не зацикливайтесь сверх меры и не расстраивайтесь слишком сильно, когда окажется, что эта проблема уже давно решена командами ученых, и за десятилетия исследований найдено гораздо лучшее решение.
Это просто игра, причем, не худшая из игр. Советую так к этому и отнестись.
tyomitch
20.02.2018 20:52Теперь для того, чтобы привести символ в верхний регистр достаточно одной операции:
Ё против такого к себе обращения.4eyes
20.02.2018 21:01Если будет сильно возражать, заменим её на ? и ±, соответственно. Нет буквы — нет проблемы. Тем более, в контексте новых интерфейсов первый символ будет вполне востребован.
ToshiruWang
21.02.2018 11:04Верхняя_буква = буква + смещение. Но в некоторых кириллических кодировках проблемы — разбиты на части.
4eyes
21.02.2018 14:30А если буква уже верхняя? В том-то и прикол, что проставить бит на GPU — быстро, а if-ы выливаются в холостые циклы. else-ы, естественно, тоже.
EDIT: ну, т.е. снять бит, но не суть.ToshiruWang
21.02.2018 14:39+1А если это не буква, а цифра? Всё равно надо проверять границы перед установкой бита, тем более букв 33 (менять не только кодировку, но и алфавит — это уже слишком).
4eyes
21.02.2018 15:35Ну как же, вот мы сделали массив:
и дальше в нужном участке интерпретатора проверяем:истинность букваЛиЭто[256]
ведь проще, чем дополнительно проверять большая ли это буква.если букваЛиЭто[символ] то большаяБуква = символ И маска иначе эскалировать проблему "не буква"
Но можно пойти дальше. В GPU загрузить код:
Этот код без никаких ветвлений переведет все буквы в большие, оставив нетронутыми все не-буквы.неизменный целый большаяЛиЭтоБуква[256] = { ... } // ежели большая буква, то 1, иначе 0 для (а=0; а < длиннаТекста / числоКоробокСПотоками; ++а) { индекс = а * номерКоробкиСПотоками; преобразованная = текст[индекс] И маска; текст[индекс] = преобразованная * большаяЛиЭтоБуква[преобразованная] + текст[индекс] * (1 - большаяЛиЭтоБуква[преобразованная]); }
Я не настоящий сварщик, и мог написать неоптимальный с точки зрения коробок с потоками код, но в целом как-то так.Zenitchik
21.02.2018 21:07+1Зачем проверять, большая ли это буква? Просто складывайте её побиово с битом верхнего регистра. 1 ИЛИ 1 = 1.
4eyes
21.02.2018 21:09+1но это может быть цифра. И бит надо не добавлять, а убирать — тут особенная кодировка.
Zenitchik
21.02.2018 22:25Надо проверять «это буква», а большая или маленькая — неважно.
Убрать бит ничуть не труднее, чем прибавить. Вы побитовыми операциями что ли никогда не баловались?4eyes
21.02.2018 22:52Вы не внимательно прочитали код или не поняли его. В этом случае нужно проверять результат, он будет большой буквой если изначальный символ был любой буквой, и не большой буквой, если на входе была не буква.
Можно переписать код так, чтобы проверка выполнялась до преобразования, но мне уже надоело баловаться побитовыми операциями.
4eyes
21.02.2018 21:16хотя, конечно,
можно заменить набольшаяЛиЭтоБуква[преобразованная]
у меня, к сожалению, нет компилятора с русского на ГПУ, чтобы проверить, как быстрее.большаяЛиЭтоБуква = (целый)(преобразованная >= 'A' И преобразованная <= 'Я' )
alltiptop
20.02.2018 18:41Картинки не отображаются — на какой то спам сервис ссылаются. На хабре вроде как только хабрастораж разрешён
aamonster
20.02.2018 18:41-2Зачем всё это? Скорость набора для программиста проблем не создаёт — обычно даже 100 символов в минуту хватит, чтобы успеть за "полётом мысли", доступные без 10-пальцевого метода 200-300 делают программирование комфортным, 10-пальцевый метод — вообще адский оверкилл, делающий любые ускорения набора бессмысленными. "Узкое место" — не скорость набора, а размышление, поиск багов, рысканье по документации.
И что получит человек, переучившийся на кириллический ЯП? Посмотрите на 1с-ников — как-то сложилось, что они — самая презираемая каста программистов. Стоит ради этого уходить с мейнстримных языков?VulvarisMagistralis
20.02.2018 20:26+1Посмотрите на 1с-ников — как-то сложилось, что они — самая презираемая каста программистов.
Вы презираете из-за собственной некомпетентности.
Потому что не знаете, что обновлять конфигурацию 1С способны и сами бухгалтера. И напрасно называете обновляторов программистами.
Те что занимаются программированием в 1С — самые обычные программисты.
И кириллица там или не кириллица — никак не связано с квалификацией.
P.S.:
То есть вы не знаете, что 1С поддерживает и англоязычный и русскоязычный синтаксис еще с прошлого века?aamonster
20.02.2018 20:40-2Я ничего не сказал про собственное отношение (да и про поддержку латиницы я знаю, как и про многое другое).
А стереотип есть, и то, что вы тут разорались и минуснули — показывает, что вы о нём знаете и обиделись на его упоминание.
Так зачем на ровном месте создавать себе проблемы, переходя на язык, за пользование которым к вам будут относиться свысока?
Kroid
20.02.2018 23:20Справедливости ради.
Программисты — они обычно просто программисты, а не что-то вроде «программист на javascript». Ясное дело, что существует специализация. Но в целом большой разницы нет на чем писать.
«Программист 1С» (из тех, кто мне встречались в реальном мире) живет в мире 1С. Когда он начинает взаимодействовать с внешним миром — он начинает страдать.
Например, нужно отправить http post запрос внешней системе. Обычному человеку совершенно пофиг, как это сделать — хоть на js/python, хоть на curl, хоть на go отправит этот запрос. Разве что минут 10 погуглит документацию, если язык совершенно не знаком. 1С-ник будет с этим мучиться сутки. Несколько часов на «что такое post запрос, что такое хедеры», несколько на «я отправляю запрос, это у вас не работает» и еще парочку, чтобы осознать нужность логов, без которых человек сидит как в черном ящике — что-то делает, но не понимает, что происходит.
Или вот, был недавно курьезный случай. Человек узнал об алготрейдинге и пытается написать торгового робота криптовалютами с нуля на 1С. Не потому что ему по фану — как тем, кто на брейнфаке пробует что-то написать. А потому реально что не знает другого способа. Не осознает, что есть, к примеру, питон, в котором его 95% будущих граблей уже давно решены.
Hivemaster
21.02.2018 09:50Те что занимаются программированием в 1С — самые обычные программисты.
Я имею опыт работы программистом на С, Perl и 1С. К сожалению, на 1С существенно больший. В одиночку программировал 1С в компаниях, в которых админил, в одной компании работал в команде 1Сников и работал во франче. Могу сравнивать и могу утверждать, что «программирование» 1С отличается от программирования настоящего больше, чем застольные песни от оперного исполнения.VulvarisMagistralis
21.02.2018 09:56Могу сравнивать и могу утверждать, что «программирование» 1С отличается от программирования настоящего больше, чем застольные песни от оперного исполнения.
Имею опыт программирования с прошлого века и до сих пор: C/C++, C#, assembler Motorola 68 и Intel 86, 1C, Go, JavaScript, Python, Java, Rust.
Согласен с вами. Отличается.
Тем, что в 1С то, что в других системах приходится прикручивать из библиотек в лучшем случае (или писать свое) — уже есть.
И программист 1С сосредоточен на прикладной задаче, за которую собственно заказчик и готов заплатить.
В этом смысле различается. С точки зрения квалификации — никак нет.
Говнокодеры есть везде.
Skyroger2
20.02.2018 18:56+2Программирование на кириллице в середине 1980-х изобретали уже
Кодировка была придумана для телеграфа ещё раньше. Вообще, кодировок и так слишком много.GutenMorg
21.02.2018 09:50Да, и насколько я помню был Автокод Эльбрус. Применялся для советских суперкомпьютеров. Давным давно, бывший работник Гомельского филиала КБСП показал мне книжку по Автокоду, чем привел в немалое изумление.
Sirion
20.02.2018 19:08+2При всей… странности статьи это определённо не худшее, что приходило из песочницы)
arandomic
20.02.2018 19:09+1Большинство компиляторов современных ЯВУ справляются с unicode.
Так что хоть на боярском писать можно habrahabr.ru/post/41561
Хоть на YoptaScript2che Автор
20.02.2018 19:32-3Писал не только на боярском, а на мунспике забавы ради. Но такой подход все равно переводит макросы, выводя чистый си, только снижается скорость компиляции и растет вес кода. Преимущество от такого кодинга лишь развлечение. А теперь представьте тот же боярский без макросов и с однобайтовой кодировкой.
ToshiruWang
21.02.2018 11:10А если посмотреть столько времени занимает разбор символов относительно всей JIT-компиляции (причём по факту от такой таблицы ускорения компиляции можно и не получить, а даже наоборот), то становится видно Эталонное Ненужно (а если не JIT, то переход на язык с ним даст кратное/степенное превосходство в скорости без потерь на преобразование в эту кодировку из другой, в которой работают остальные системы, а если нет обмена, то это какой-то бессмысленный учебный проект).
berez
22.02.2018 14:42Ну вот я представил. Плюсов особых не вижу, минусов же — тьма тьмущая.
Из плюсов:
— на пару микросекунд уменьшается время парсинга исходного кода. Это если повезет, так-то компиляторы очень неплохо справляются с оптимизацией строковых операций, да и процессоры в большинстве случаев оборудованы командами быстрой трансляции из кодировки в кодировку (xlat в x86).
— слегка уменьшается расход памяти.
Из минусов:
— поддержку интернационализации придется городить отдельно, как в старые добрые времена. Многоязычный интерфейс у программ нынче — норма.
— юникод удобен не тем, что он как-то там оптимально устроен, а тем, что не надо переключаться между кодировкаами. Это удобство с лихвой компенсирует его недостатки.
— экономия на спичках (этап парсинга) будет практически незаметна на фоне других ресурсоемких задач компиляции. Да, мы, возможно, сэкономим пару микросекунд на парсинге каждого файла, но если сама компиляция занимает секунды — общий выигрыш будет ничтожен.
— как выводить текст в вашей новой кодировке? Современные шрифты или заточены под одну из известных кодовых страниц, или реализуют некое подмножество юникода. Будем на лету перекодировать в юникод? Это ж лишние такты! :)
VulvarisMagistralis
20.02.2018 19:54Польза есть, если программисту нужно очень глубоко закапываться в предметную область.
Тогда названия переменных, функции и пр. помогут хоть как-то ориентироваться программисту.
L0z4
20.02.2018 21:33Не понятно. В чем повысить? Программирование это не просто ввод символов с помощью клавиатуры.
Работаю с 1с, и могу сказать что это вовсе не так. Да читаемость кода улучшается, значимость переменных яснее, не нужен словарь или хорошее знание английского языка, но сама вариативность русского языка при именовании методов сбивает все на нет — слишком много ходовых синонимов и у каждого разработчика будет своя по своему верная логика именования. Слова "вид", "тип" становятся паразитами в именах. "сформировать", "получить" имеют туже историю. Удлинение имен русскими словами вместо лениво коротких английских так же усложняет жизнь. И это так, просто маленький пример всей той чехорды которая создается русской раскладкой. Да просто введите
"Значение <> неопределено" на русском вместо "value <> nil"4eyes
20.02.2018 22:16слишком много ходовых синонимов
то ли дело — английский. пример, другой пример. Похоже, это фундаментальная проблема, которая не зависит от языка.VulvarisMagistralis
21.02.2018 07:25то ли дело — английский. пример, другой пример. Похоже, это фундаментальная проблема, которая не зависит от языка.
Ну а теперь переведите на английский терминологию из предметной области.
Да так, чтобы и ваши коллеги и вы сами (через три месяца, когда забудете что это) — однозначно поняли о чем там речь.
Например: «сумма вычета на ребенка с налога на доходы физических лиц» на английском, пожалуйста.
QDeathNick
21.02.2018 14:33+1Лично мою производительность программирование на кириллице не раз повышало таким образом — я сам не лез разбираться в предметную область, а показывал бухгалтеру код и она сама разбиралась в математике и логике вычислений налогов.
4eyes
21.02.2018 14:43+1У меня прямо противоволожная проблема — англоязычная терминология. Слово есть, перевод есть, даже не один, а понимания, где именно в поезде «колодец», «шахта лифта», «добро, благо», «кладезь», «скважина», «отстойник» и «благополучие» в одном лице — очень сложно.
Проблема, наверное, не зависит от языка и характерна для всей терминологии.
Zenitchik
20.02.2018 23:09непонятно зачем оставленный лингвистами
Это не от лингвистов зависит, а от массы носителей языка. Будут смягчать согласные, вместо разделения — и знак больше не понадобится (исчезнет, конечно, не сразу — орфография всегда консервативнее, чем фонетика).berez
22.02.2018 15:06Вообще-то в данном случае именно от лингвистов. :)
Реформа орфографии была разработана именно лингвистами. Вот только она оказалась слишком радикальной, чтобы принять ее в царское время, поэтому принята уже большевиками в 1918 году.
Что касается букв Ъ и Ё — то да, от Ъ предлагали отказаться совсем. Но это было бы слишком радикально даже для такой радикальной реформы, как тогдашняя. Все-таки у Ъ нашлось применение для отделения приставок.
Буква Ё с самого своего появления была факультативной (напомню, ее ввел Карамзин). В старой орфографии буква Ё была не очень-то и нужна, т.к. была буква ять — а она всегда читалась как «е» и никогда — как «ё». После упразднения «ятей» возможностей для неправильного чтения стало больше. ЕМНИП, в какой-то период буква ё даже была обязательна к применению, но потом опять переведена в разряд факультативных.Zenitchik
22.02.2018 17:38Принцесс, драконом заточённых, возможность есть ещё спасти,
Но вот заточенных драконом — прости.
Буквы ё не было на некоторых печатных машинках ради экономии клавиш.
Ещё советские типографы очень любили набирать книги без неё, из-за чего я лично многие новые для себя названия прочитал неправильно и неправильно запомнил.
Короче, сугубо ИМХО, за неиспользование буквы ё — нужно бить. Больно.masai
22.02.2018 17:45Не совсем про букву ё. У меня есть книжка по дифференциальной геометрии середины 30-х годов. Так там слово дифференциальный пишется с одной ф. А пишется оно на каждой странице, так как в колонтитулах приводится название текущей главы и книги. Уж очень глаз режет, но ничего не поделаешь. :) Как и итти в старых книжках.
VulvarisMagistralis
22.02.2018 17:53Как и итти в старых книжках.
Если речь о художественной литературе и там это употребляется в смысле «стилизация под устную речь» — то «итти» вполне нормально, подчеркивает или социальный статус говорящего или эпоху.Zenitchik
22.02.2018 19:54«Итти» — не только в художественных старых книгах.
Ещё бывает «эксплоатация».
poznawatel
21.02.2018 05:37Такая кодировка может не столько скорость повысить, сколько требуемый объём/энергоёмкость/износ памяти уменьшить за счёт однобайтного представления, это может быть актуально для какого-нибудь микроконтроллера с русским экраном, аналогично проекту Micropython.
TrllServ
21.02.2018 09:29А я вот подумал что это больше применимо для архивации. Правда при условии, что текст исключительно на кирилице. Такой специфичный и узконаправленный вариант для литературы.
Мне идея понравилась, но для остального нужно серьЁзно дорабатывать.
По оптимизации:
Если глянуть частотность букв, топ-10 в порядке убывания: о е а и н т с р в л. Возможно не заметил или не прогрузилось что-то, но как именно было предложено сделать раскладку учитывая это?
По скорости ввода:
Идея скоростного ввода сейчас в большинстве случаев не заинтересует, потому как не главная в задержках в пересчете набранного текста за трудодень. Даже у секретарей.
С другой стороны все программисты с которыми я имел дело печатают в диапазоне 250-450 знаков в минуту, причем эта скорость больше из-за чатов и каментов, чем от набора кода, который всё же очень специфичен.
masai
22.02.2018 17:32Тут удобнее КОИ-8 использовать. Потому что если экран вдруг окажется нерусским, то легко будет перейти на транслит.
killov
21.02.2018 09:11Возвращаясь к открытым вопросам, вот почему заглавные буквы следуют после прописных...
Действительно, не понятно, зачем такое может понадобиться.
php7
21.02.2018 10:27Русский язык — для общения с людьми.
Английский язык — для общения с роботами.
:)
Sinatr
21.02.2018 11:25Благодаря этим правилам, таблицу можно восстановить по памяти буквально после первого прочтения, а свойства попадающего в поток нового символа определяются уже при считывании первых битов, что можно использовать для значительного увеличения производительности
Зачем восстанавливать по памяти таблицу? Непонятный навык, можно, к примеру, вызубрить ASCII, но я не понимаю зачем? Писать программу в машинных кодах разве что (было дело), но сейчас так не делают.
Какой производительности? Вы о чем вообще? Кто будет считывать какие-то биты? На входе будет байт, а уж как маскировать биты, по вашему, или по «нормальному» (меньше пробела — значит управляющий код) — на производительности особо не скажется.
Буду категоричен — это какой-то непонятный бред. Я считаю большой проблемой возможность «школьников» публиковать свои поделки без некоей «цензуры». Мне было бы ужасно стыдно сейчас, в свои 40, читать мои «сочинения» (я писал рассказики) или слушать «песняки» (я делал в IT tracker музончик и накладывал свой голос с микрофона), выложенные где-нибудь публично. Совет: найдите себе ментора: взрослого (~30 лет), который может оценить ваш материал (быть в теме, к примеру, нет смысла рассказывать о кодовых таблицах непрограммисту) и перед публикацией спрашивайте его мнение. Еще лучше, если он будет находить для вас «темы».tyomitch
21.02.2018 15:07Я считаю большой проблемой возможность «школьников» публиковать свои поделки без некоей «цензуры».
А я считаю это большим благом.
И автора считаю большим молодцом, что он на это решился.
Фидбек, который автор получил здесь — ценнее любых «менторских» увещеваний.
Мне было бы ужасно стыдно сейчас, в свои 40, читать мои «сочинения» (я писал рассказики) или слушать «песняки»
А ещё через 20 лет вам будет стыдно читать то, что вы пишете сейчас. А через 40 лет вам будет стыдно читать то, что вы напишете через 20 лет.
Это нормально. Не только «школьники», а все люди всю жизнь развиваются.
VulvarisMagistralis
21.02.2018 15:20Мне было бы ужасно стыдно сейчас, в свои 40, читать мои «сочинения» (я писал рассказики) или слушать «песняки» (я делал в IT tracker музончик и накладывал свой голос с микрофона), выложенные где-нибудь публично.
Возможно, вы поэтому и не стали признанным писателем или автором/исполнителей песен.
VulvarisMagistralis
21.02.2018 11:43Если вспомнить эпоху ПЕРФОКАРТ — то да, в те времена примерно так и имело смысл делать.
Только эта эпоха закончилась уже лет 50 назад.
Автор статьи просто не знает, что программа, написанная на языке программирования, всегда преобразуется до того, как быть исполненной.
В случае компилируемых языков — вообще ровно один раз за все время существования этой программы (не считая случайных ничего не значащих и ничего не меняющих дублей).
В случае языков интерпретируемых… ну если использовать как базовый компьютер для разработчика компьютер с процессором в 4 бита — толк будет. Только их использовать для разработки перестали еще до рождения автора.Zenitchik
21.02.2018 16:08Только эта эпоха закончилась уже лет 50 назад.
Точно! Вы только что напомнили мне, что есть такая область, как историческая реконструкция.
MrGobus
21.02.2018 11:51Программирование на кириллице сегодня — это бред сивой кобылы. Все очень просто. Переход на кириллицу для последующего программирования потребует внесение в изменение синтаксиса языка, что в сочетании с переобучением на работу с новой раскладкой подарит вам пару лет обучения. Почти весь программный на планете написан на латинице а это значит, что вам с нуля придется написать все возможные библиотеки и утилиты, так как машинное конвертирование не даст вам уверенности в результате. Тут я думаю лет 7 — 10 надо, так как сомневаюсь, что у вас есть нужный для этой цели объем знаний. И вот, гдето через 8-10 лет вы сможете смело заявить, что способны писать код на 0.001 а может даже и больше процента быстрее. К сожалению, результат ваших стараний не примет международное сообщество, так как у них есть свои взгляды на выбор языка. Да и вообще, у профессионала ввод текста влияет на скорость написания кода не больше чем на 0.000000000000000001%
VulvarisMagistralis
21.02.2018 12:33Программирование на кириллице сегодня — это бред сивой кобылы. Все очень просто. Переход на кириллицу для последующего программирования потребует внесение в изменение синтаксиса языка, что в сочетании с переобучением на работу с новой раскладкой подарит вам пару лет обучения.
Переход с скажем JavaScript на Python потребует больше обучения, чем переход
с той же кириллицы 1С на английский в той же 1С (что, вы не знали, что 1С поддерживает одновременно два синтаксиса в языке? )
Основное — это не синтаксис языка, он как раз запросто учится за недельку.
VulvarisMagistralis
21.02.2018 14:38+1Да и вообще, у профессионала ввод текста влияет на скорость написания кода не больше чем на 0.000000000000000001%
Как профессионал, скажу, что вы ошиблись на огромное число порядков.
Собственно написание кода занимает 10-20% рабочего времени. habrahabr.ru/post/102620
Однако куча времени уходит также на поиски и пробы — а для этого тоже неплох быстро писать слова в той же поисковой строке браузера или в командной строке ОС.
В течение рабочего времени программист с клавиатурой взаимодействует постоянно.
Но дело еще и в том, что вы прочитали только заголовок, а не саму статью — и ваше замечание вообще не о том, о чем пишет автор.
andyudol
21.02.2018 15:01Школьник? Есть у меня один знакомый бывший учитель, у которого ученики драйвера писали. Я думал, такого уже не уже не бывает, а оказывается воно оно как — бывает ещё и не такое.
В следующей статье покажите нам, пожалуйста, использование вашей таблицы символов в каком-нибудь проекте.
BOM
21.02.2018 15:35-1Английский язык идеально подходит для декларации разного рода отношений между сущностями, команд, кратких описаний логики и многого другого. RelationResourcesByUserId — попробуй не вырвиглазно продекларируй это на русском.
VulvarisMagistralis
21.02.2018 15:43+1RelationResourcesByUserId — попробуй не вырвиглазно продекларируй это на русском.
Для них звучит также коряво как и для нас.
Дело в том что в английском языке кардинально меняет смысл фразы порядок слов.
Как и в вашем примере — вполне себе вырвиглазно, но по английски.
А еще у них важны фразовые глаголы — не видел, чтобы в коде их корректно с точки зрения языка употребляли, коряво — да, запросто. В том числе и «нэйтивами».
Zenitchik
21.02.2018 17:12Помнится, у нас на информатике было что-то агатоподобное, так у него на клавиатуре были кнопки
«ВР» и «НР» для переключения в верхний и нижний регистр соответствнно (шифта и капса не было), а кнопка возврата каретки называлась в стиле КО — «ВК».tyomitch
21.02.2018 21:17УПР-ДОП-УДЛ!
Zenitchik
21.02.2018 22:43А не напомните, что это за клавиатура? Я в детстве не особо интересовался названиями компов, поэтому сейчас по внешнему виду вспоминаю, что это было…
berez
22.02.2018 15:19Наверное, ДВК.
Впрочем, у большинства советских бытовых и учебных компьютеров управляющие клавиши были подписаны по-русски. У меня была 8-битная «Сура» — там были шедевры типа РГ (регистр — т.е. Shift), УПР (Ctrl), ТАБ (Tab), ПРФ (хе-хе… это — внимание! — Esc).VulvarisMagistralis
22.02.2018 15:53Во всем этом самое смешное — что это не оригинальные термины. А кальки с английского.
wikipro
21.02.2018 18:00Кому любопытно проверить теорию практикой (есть смысл от русского зыка в программировании или нет) оставлю здесь ссылку https://тхаб.рф/wiki/Языки_программирования_с_русским_синтаксисом
Самые профессионально сделанные проекты используют синтаксис 1С. мне больше всех понравились 1Script, Гонец и Яр
OneScript (1C),
Naf2000
22.02.2018 01:00как 1С-ник могу сказать, что код
Данные = Новый ТаблицаЗначений;
смотрится несколько странно для русского человека
VulvarisMagistralis
22.02.2018 06:13Дело не в русском языке.
Технически ничто не мешало бы сделать и второй вариант, чтобы можно было писать и «Новый» и «Новая» и это означало бы одно и то же.
JBMurloc
22.02.2018 08:57А мне нравится статья. Занимательная. Правильно ли я понимаю: упоминание программирования в заголовке намекает на то, что в следующей статье автор собирается выкатить стандарт языка программирования на кирилице? Если же вторая статья уже есть, то прошу дать на неё ссылку. Очень уж хочу почитать.
2che Автор
22.02.2018 10:27Стандарт так быстро не нарисуешь, но кое-что на основе принципа «один бит — одно свойство» представлю в ближайшее время.
masai
22.02.2018 17:42Полезность такой кодировки сомнительна, так как изначальные требования: семибитность и лёгкость запоминания решают проблемы, которые не очень-то актуальны. Я выше упоминал про КОИ-8, вот там достаточно интересное требование было — текст должен оставаться читабельным после обнуления старшего бита. Русские буквы превращаются в транслит. Я думаю, что автор статьи примерно в таком направлении двигался, но ему чуть-чуть не хватило для завершающего шага.
Несмотря на то, что статья так и не ответила на поставленный в заголовке вопрос, я думаю, что всё же автор молодец, что чем-то интересуется и пытается делать. Не то, чтобы я хотел часто такие статьи читать, но я не могу согласиться с теми, кто излишне жёстко критикует автора.
Возможно, стоило бы сделать какой-то раздел или пометку для публикаций новичков. Те, кто поопытнее, смогут дать совет или покритиковать. Получится этакое коллективное менторство. Кому же не интересно — просто не будет читать. Надо как-то поощрять самообразование.
TrllServ
22.02.2018 17:50+1Возможно, стоило бы сделать какой-то раздел или пометку для публикаций новичков. Те, кто поопытнее, смогут дать совет или покритиковать.
А разве пометка «из песочницы» не является пометкой со смыслом «от новичка»?
VaalKIA
23.02.2018 08:01Не хватило места только для буквы Ё, не критично, все давно привыкли к её особому статусу «дальнего родственника»
Все кто занят обработкой данных — не привыкли. Сортировка по алфавиту имеет первостепенное значение. Любая дополнительная операция делающаяся вручную, после авто-сортировки это огнромнейшие накладные расходы, дешевле миллион строк обработать, чем потом ифами и курсором одну. Особенно приятно будет обрабатывать данные переданные от других пользователей в которых надо конвертировать кодировку, я так понимаю, вручную надо будет указывать — здесь тест с русскими буквами, а тут просто raw data, а тут мы проглядели — исправьте и т.п.
4eyes
… а может и не повысить.
Совершенно не понятно, что значит «может», а также в статье на раскрыто:
Цель этой критики в том, чтобы вы не зазнавались, когда школьный учитель упадет в обморок в восторге от увиденного и продолжали самосовершенствоваться. Для хорошей технической статьи в ней нет доказательств и исследований, не понятно, зачем это изобретение и на чем основаны ваши предположения.
В любом случае, для начала, с учетом вашего рода деятельности — хорошо.
Scrooge2
Такого же мнения был наш преподаватель по прологу в университете — рекомендовал хоть одну лабораторную написать на кириллице (производительность программиста).
Ну что же, не знаю как производительность, но в этом была изюминка :)
ToshiruWang
Самый Короткий Язык Программирования был смешней — там автор хотя бы заявлял что главное у программиста — скорость набора кода и если заменять функции одно-двух символьными обозначениями — получается быстрее (правда, основными функциями у него были «Hello, world!» и факториал), а тут вообще не понятно производительность чего имеется в виду (автор рассматривает интерпретатор как if(cur_char >= 'А') {switch('А':… 'Б')}else{switch('а':… 'б':...)}, иначе не понятно к чему эти деления таблиц пополам для ускорения).