Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Новости и прочее

Шестнадцатиричные и двоичные константы

Язык C установил де-факто стандарт записи шестнадцатеричных чисел. Новые языки, опирающиеся на синтаксис C, копируют этот способ записи. Он привычен, но является ли он естественным?
Шестнадцатеричные и двоичные константы
Попробуем пристально рассмотреть запись вида 0x0123456789abcdef. Вопросов к такой записи немного:

1) Удобно ли писать «abcdef» в языках, где латиница не является основным алфавитом?
2) Является ли префикс «0x» удобным указанием того, что после него последуют шестнадцатеричные цифры?

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

        Что можно поставить в соответствие «abcdef»? Предлагалась такая замена: «abcdef» -> «цодтчп», где
«ц» — цать (т.е. десять)
«о» — одиннадцать,
«д» — двенадцать,
«т» — тринадцать,
«ч» — четырнадцать,
«п» — пятнадцать.

        Не лучший вариант. Во-первых, надо запоминать сокращения — в них есть некая неестественность, потому что эти буквы не идут в алфавите подряд. Во-вторых, буква "О" очень похожа на "0" (ноль) — этому источнику недоразумений уже полсотни лет.

        Самый разумный вариант: «abcdef» -> «абцдеф». Полная калька исходной записи в кириллическом варианте. Транслит наоборот. Не лишено недостатков, ведь в записи «abcdef» — алфавитный порядок букв, а в «абцдеф» — нет. Но остальные варианты хуже.

        Рассмотрим их кратко.
1) «abcdef» -> «абвгде». Русская «В» и «Е» имеют схожие по начертанию латинские «B» и «E», но имеют разный код. Звучащие одинаково на слух «Д» и «D» тоже имеют разный код. Это потенциальный источник путаницы, этого нельзя допустить.
2) «abcdef» -> «ъыьэюя». Вариант экзотический, хотя и в алфавитном порядке. Фрагмент «ъыь» трудноват для запоминания.
3) Замена «abcdef» на символы, один таких способов: «abcdef» -> «. , - : ; =». Не очень удобный вариант для лексического анализатора. Да и любой другой тоже. И какого порядка символов надо будет придерживаться?
4) Замена символов «abcdef» на двухсимвольные последовательности. Примеры:

«abcdef» -> «!0!1!2!3!4!5»
«abcdef» -> «:0:1:2:3:4:5»
«abcdef» -> «^0^1^2^3^4^5»
        Все перечисленные варианты уступают по простоте и внятности «абцдеф». Хотя, возможно, у кого-то найдутся идеи покрасивее.

        А теперь вернёмся к префиксу «0x». Странно вообще, почему эта форма записи так прочно прижилась. Почему «x»? Потому что «hexadecimal»? Но почему выбрана третья буква этого слова, а не первая или седьмая? А зачем нужен «0»? Наверно потому, что запись «x0123456789abcdef» будет принята за идентификатор.

        В языке Euphoria шестнадцатеричные числа записываются так: «#0123456789abcdef». Очень лаконично. В русской раскладке символ «#» отсутствует, но его вполне можно заменить на «№», который находится на той же кнопке.

        Можно попробовать другой способ записи, он выглядит длиннее, но нагляднее. Предлагаются префиксы «16'» и «16"». В таком варианте шестнадцатеричные числа будут выглядеть так:
16' 01 23 45 67 89 аб цд еф
16" 01 23 45 67   89 аб цд еф"
        В первом случае шестнадцатеричные числа допускают употребление одиночных пробелов — сплошной текст труднее воспринимается. Концом константы считается двойной пробел и символы, которые не могут быть употреблены внутри шестнадцатеричного числа.

        Во втором случае концом константы считается второй «"». Цифры внутри апострофов могут разделяться любым количеством пробелов.

        Удивительно, но факт: компьютеры имеют двоичную природу, но в большинстве языков программирования нет возможности записать двоичное число! По аналогии с шестнадцатеричными числами можно ввести двоичные:
2' 0110 1100 0100 1101
2" 0110 1100   0100 1101"
        Элегантная запись, которая понравится новичкам в программировании. Да и профессионалам пригодится при работе с отдельными битами.

        Но было бы неправильным не рассмотреть ещё один (весьма компактный) способ записи, который встречается, к примеру, в HTML или Euphoria.
0xabcdef        традиционный для C-подобных языков способ записи
#abcdef         так записывают в HTML
        У этого способа есть небольшой минус: он «расходует» целый символ из алфавита языка. А как быть с записью двоичных констант? Для этого алфавит нужно уменьшить ещё на один символ? Допустим, вот так:
%01101110       символ «%» обозначает двоичную константу
##11001110      ещё один способ: удваиваем «#»
        Честно говоря, не нравится, потому что, в отличие варианта 16'.... и 2'...., нельзя делать пробелы внутри константы. Эти пробелы облегчают восприятие. Надо сказать, что пробелы — не единственный способ сделать это. В языке Rust облегчают чтение с помощью «_»:
0x9876_abcd
0b0110_0111_1010_1001
Шестнадцатеричные и двоичные константы
        Строка «0b0110_0111_1010_1001» описывает двоичную константу, для этого используется префикс «0b». Автор языка Rust тоже понял, что постоянно проводить в уме преобразования «двоичный код <-> шестнадцатеричный код» — не самое продуктивное занятие.

        Непонятно упорство многих авторов языков предварять шестнадцатеричные константы префиксом «0x». Понятно, откуда она взялась эта традиция. На заре компьютерной эры была распространена восьмеричная система счисления. В C для записи таких чисел использовалась запись с лидирующим нулём. По аналогии использовался лидирующий ноль и в шестнадцатеричных числах, только с добавлением «x». Но восьмеричную систему счисления можно теперь встретить только на маргинальных системах. Поэтому нет необходимости поддерживать единообразие в обозначениях; префикс «0x» сморится нелогично. А вот наш вариант с «16'» и «16"» интуитивно понятен.

Опубликовано: 2012.09.25, последняя правка: 2014.12.23    13:39

ОценитеОценки посетителей
   ▌ 0
   ████████████████████████ 4 (57.1%)
   ▌ 0
   ██████████████████ 3 (42.8%)

Отзывы

     2013/08/01 09:29, Е.В.Геній          # 

А по моему если ужъ программистъ рѣшилъ использовать шестнадцатеричныя константы то ему какъ разъ на переключеніе раскладки плевать. Для чего они вообще въ языкѣ? Свой курсорчикъ нарисовать, или экзотическій сѵмволъ... Въ остальныхъ случаяхъ вполнѣ достаточно десятичнаго представленія... А для компактной записи данныхъ къ примѣру иконокъ или рисунковъ сѵмволами въ текстѣ — есть болѣе прогрессивныя способы кодированія данныхъ въ текстъ, къ примѣру въ форматѣ Base64.

     2013/09/02 23:35, Автор сайта          # 

Евгений, программистам 1С шестнадцатиричные числа точно не нужны :) А вот попробуйте без них написать компилятор… Если хотим язык программирования сделать универсальным, в нём должны быть средства для работы битами. Символы тут ни при чём.

     2014/01/16 11:48, Pensulo          # 

В некоторых реализация Форт используются следующие одиночные префиксы для представления констант со специфической базой исчисления:

% для двоичных, например, %10101010
@ для восьмеричных, например, @177
$ для шестнадцатеричных, например, $FE00
# для собственно десятеричных, например, #-13579

     2014/01/16 12:22, Автор сайта          # 

Это не очень наглядно. Если записать 2”101010”, 8”5874”, 16”FD0A”, 10”1954”, то это будет чуть длиннее, но понятно с первого взгляда.

     2014/01/26 12:34, Pensulo          # 

Предлагаю упростить формат представления чисел с различной базой отсчёта до следующего вида:
база$число
, где база — число в десятеричном виде обозначающее основание исчисления в диапазоне от 2 до 36
число — собственно число представляемое цифрами и буквами латинского алфавита без различия регистра
$ — одиночный символ подобранный так чтобы не конфликтовать с прочими синтаксическими правилами проектируемого языка
Например, 16'12AF представляет собой шестнадцатеричное число 12af

     2014/01/26 17:59, Автор сайта          # 

в диапазоне от 2 до 36

Честно говоря, востребованы только две системы счисления: 2 и 16. Иногда ещё 10, но в особых случаях. Восьмеричная система счисления фактически мертва в языках программирования.

Насчёт одиночного символа. Есть два применение этим константам:
  • для обычной записи чисел
  • для записи кодов символов внутри текстовых литералов
Пример для первого случая:
а = 16"fa09"
b = 2"1111 1010 0000 1001"
и для второго
a = "string 16'30' 2'0011 0001' 10'50'" // что равносильно
a = "string 0 1 2"
Во втором случае эти константы лучше чем-то завершать для ясности. Ибо будет неясно, где заканчивается код символа и где начинается обычный текст. И ещё важно, чтобы способы записи были одинаковы для обоих случаев. В тексте статьи (выше) упомянут вариант с одним символом ', но теперь думается, что это ошибочный путь. А статью собираюсь подправить.

     2014/04/25 03:20, Utkin          # 

Честно говоря, востребованы только две системы счисления: 2 и 16.

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

     2015/03/19 22:47, rst256          # 

Ответом на первый вопрос будет «нет», т.к. употребление «abcdef» требует переключения на латинскую раскладку клавиатуры.

Эм, а для чего вообще может понадобиться 16-ричные числа в кириллице? Завязывайте вы с Лыськовщиной, кириллице не место в коде!

«16'» и «16"» — это значит "16 угловых минут" и "16 угловых секунд", как нет?
А говорили что очень интуитивно.
Вообще явная запись системы счисления это просто детский сад.
/255.255.255.0 и /24 — не напоминает?

     2015/03/20 11:39, Автор сайта          # 

Кириллица в коде — вполне востребованная вещь. Об этом говорят и итоги голосования. Вы голосуйте, Ваш голос очень важен для нас. Но если Вы не хотите программировать на русском, используйте английский. Языки программирования должны предоставлять свободу выбора. Такая свобода сейчас чаще всего отсутствует.

Для физиков это может означать угловые минуты и секунды. Но у программистов всё по-другому. В языке Ада запись string'length означает вычисление длины строки. Такой способ записи констант обсуждался (в статье есть ссылка), в целом мнение положительное.

     2016/07/21 11:23, Андрей          # 

Надуманная проблема. Сишный вариант представления чисел — один из самых удобных и наглядных и даже перекочевал в некоторые современные языки ассемблера, где, казалось бы, есть давно сформировавшаяся система записи любых чисел. Причина проста как две копейки: такую запись не спутаешь с идентификатором и сразу видна база числа. А маленькая буква 'x', 'o' или 'b' прекрасно выделяют само число от первого нуля и самого префикса. В отличии от кавычек, которые прочно ассоциируются со строкой или символом. Символы '$' и '#' неудобны тем, что сливаются с числом и читаются несколько хуже.

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

     2019/04/02 09:55, Pana          # 

Предлагаю использоать скобки:
 16( 0123 4567 89ab cd ef ) = 0x0123456789abcdef
2( 0110 0001 ) = 0b01100001

     2019/04/02 12:28, Автор сайта          # 

А что, вполне себе вариант. Вот только на скобки и так навешено много смыслов. Lisp как раз за это критикуют: бесконечные скобки.

     2019/08/12 00:00, alextretyak          # 

Идеи занятные (и с кавычками и со скобками)...

В свою очередь, предлагаю посмотреть на http://11l-lang.org/doc/ru/integer-literals (способ записи шестнадцатеричных чисел/констант в языке программирования 11l).

А не думал ли кто-нибудь об обратной операции? Речь о конвертировании/преобразовании значения числовой переменной в произвольную систему счисления. Согласен, что она требуется гораздо реже и специальный синтаксис в языке для неё выделять — это излишество, но вот функцию добавить в стандартную библиотеку языка — почему бы и нет? На данный момент из популярных языков программирования, такая функция есть лишь в Си (itoa), но она нестандартна.

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

Иногда ещё 10, но в особых случаях.

Эм... не совсем понял данное предложение\sentence. Насколько я вижу по реальным проектам, десятичная система счисления является самой востребованной в проектах любого рода. Затем идёт шестнадцатеричная. Двоичная и восьмеричная же практически не используются. Или тут речь о явном указании на десятичную систему? Т.е. о записи 10'123 вместо просто 123? Такое, конечно, не востребовано, но имхо это просто какая-то глупость. Это всё равно что добавить в язык префикс `0d` и писать 0d123 вместо 123.

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

P.S. Хочу попросить автора об исправлении небольшого недостатка движка сайта: нажатие кнопки ‘Предварительный просмотр’ не должно проверять контрольное число и писать красными буквами ‘Введено неправильное контрольное число.’ Эта надпись несколько сбивает с толку, так как предпросмотр генерируется в любом случае, независимо от правильности ввода контрольного числа.

P.P.S. А также об исправлении по возможности такого недочёта как съедание символов новой строки перед цитатами: хочется чтобы запись
...текст1...

(" "...цитата..." ")
...текст2...
формировала ровно одну пустую строку перед цитатой и после "...текст1...".

P.P.P.S. И ещё одно замечание: после нажатия кнопки ‘Предварительный просмотр’ в текстовом поле для сообщения добавляется в конец сообщения пустая строка, состоящая из 20 пробелов (это из-за «красивого», соответствующего по уровню отступа открывающему тегу расположения закрывающего тега </textarea>). Считаю, что этот тег нужно располагать сразу после текста сообщения. Это также устранит и связанный с этим недочёт: после нажатия кнопки ‘Добавить свой отзыв’ текстовое поле для сообщения должно быть пустым, а не состоящим из 20 пробелов.

P.P.P.P.S. И последнее :)(: наличие тега </textarea> в тексте сообщения ломает предварительный просмотр (часть сообщения после этого тега оказывается за пределами текстового поля для ввода сообщения) и обрезает текст сообщения. Чтобы это исправить, символ ‘<’ следует заменять на ‘&lt;’, а перед этим ещё заменять ‘&’ на ‘&amp;’.

     2019/08/14 01:37, Автор сайта          # 

Не понятно, что у Вас является признаком шестнадцатеричного числа. Апостроф? Нет, иначе бы 255\\\'000 не было бы десятичным числом.

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

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

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

Вот вам пример лаконичного и красивого синтаксиса. Допустим, в нижеприведённом коде переменной «текущая координата» присвоено значение функции, читающей положение курсора мыши:
текущие координаты = читать координаты курсора ()
А если мы хотим установить новые координаты? Обычно это делается так
записать координаты курсора (новые координаты)
Если язык поддерживает перезагрузку имён функций, то это может выглядеть короче:
текущие координаты = координаты курсора ()	// чтение
координаты курсора (новые координаты) // запись
Выше две разных функции с одинаковым именем имеют разную семантику. Моя идея заключается в том, что эти одноимённые функции могут менять семантику в зависимости от местоположения:
текущие координаты = координаты курсора ()	// чтение
координаты курсора () = новые координаты // запись

Хочу попросить автора об исправлении небольшого недостатка движка сайта

Как раз работаю над новой версией. Поэтому вносить правки в старый код не хочется. Но Ваши замечания надо не забыть.

     2019/08/15 00:00, alextretyak          # 

Непонятно, что у Вас является признаком шестнадцатеричного числа. Апостроф? Нет, иначе бы 255'000 не было бы десятичным числом.

3 обратных слэша тут лишние, верно? А признак очень простой — количество цифр, разделённых апострофом. Если 1, 2 или 4, тогда число шестнадцатеричное. Если 3, либо если нет разделителей, то число десятичное. Если оканчивается на «b» или русскую «д», тогда двоичное. Если оканчивается на «o», тогда восьмеричное.

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

Читал я Вашу дискуссию с читателями статьи «Каркас нового языка программирования»...

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

Предлагаю познакомиться с новой статьёй, черновик которой я отправил Вам на почту. Можете высказать свои соображения по этой статье здесь же (если это будет уместно), или же на форуме http://forum.11l-lang.org/threads/Разработка-когнитивно-эргономического-синтаксиса-для-аппаратно-ориентированного-языка-программирования.8/ Можете написать и эл. письмо, но предупреждаю заранее, что я оставляю за собой право разместить его текст (или его часть) на форуме.

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

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

Моя идея заключается в том, что эти одноимённые функции могут менять семантику в зависимости от местоположения

Так ведь это уже есть в C++. Оператор [] в std::vector<bool> (который на самом деле не массив из bool, а битовый массив) возвращает прокси-объект, который можно читать (за счёт перегрузки operator bool), и в который можно писать (за счёт перегрузки оператора «равно»). Чтобы понять, как устроен std::vector<bool> изнутри, можно по шагам пройти в отладчике такой код:
std::vector<bool> v(1);
v[0] = true;
bool b = v[0];
И хочу ещё высказаться по поводу возможности разделения идентификаторов пробелом. Лично мне, как и автору, тоже не нравится, что символы подчёркивания бросаются в глаза в именах. Но я вижу другое решение этой проблемы — в IDE/среде разработки отображать символы подчёркивания в идентификаторах немного по-другому, в таком виде, который не так бросается в глаза:
https://habrastorage.org/webt/gw/kz/es/gwkzes4_vqnxphhxqspvgzitw-i.png

А если разрешить пробелы в идентификаторах, то, боюсь, будет конфликт с ключевыми словами. Например, у меня в парсере есть переменная «type_name». Но «type name» написать уже не получится, так как это корректное объявление нового типа. Впрочем, об этом автор уже писал, только там приводился пример с «int».

И, к тому же, слышал ли автор что-нибудь про «poetry mode» в Ruby? Там можно написать такое:
puts value
# или даже так:
puts Integer value
что является сокращённой записью такого кода:
puts(value)
puts(Integer(value))
P.S. Кстати, синтаксис форматирования сообщений/отзывов, разработанный автором, очень даже неплох. Единственное, для текста программ я бы выбрал (##символы решётки##) или (``обратные апострофы``), а не знаки равенства (равенство больше подходит для обозначения двойного зачёркивания).

P.P.S. И ещё маленькое замечание. Такая запись
(==
код
==)
не должна генерировать пустую строку вначале.

     2019/08/15 05:58, MihalNik          # 

познакомиться с новой статьёй

А почему только автору сайта? Мы, читатели форума compiler.su, добрые и не очень, тоже хотим её вкусить, а возможно и впрыснуть своего яду. Тем более, когда речь идет о явно измеримых вещах вроде i[nt]<(8!16!32!64)!(1!2!4!8)!(0!1!2!3)>, а не о блудливых контрацепциях.

     2019/08/16 19:32, Автор сайта          # 

MihalNik А почему только автору сайта? Мы, читатели...

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

alextretyak А признак очень простой — количество цифр

Так признак, на мой взгляд, не так уж и прост. Но всё относительно. Вы субъективны в своих оценках, а я в своих. «Каждый пишет, как он слышит. Каждый слышит, как он дышит».

По поводу статьи я выскажусь чуть позже. Просто пока что зреют мысли.

число новых/нереализованных значимых/существенных концепций, по-моему, «уже близко к абсолютному нулю»

Не хотите ли Вы сказать, что уже ничто не ново, всё Вам настолько знакомо, что в каждом новом языке Вы видите отголоски старых?

Так ведь это уже есть в C++.

Ну так приведите пример. Как я должен определить функцию func, чтобы я мог записать:
func() = 123;
Спрятать символ подчёркивания, чтобы он не так бросался в глаза... Зачем? Лучше, если программист увидит «честный» текст. Но пробелы внутри идентификаторов — это вызов, это головоломка для лексического/синтаксического анализа. И тут у каждого простого решения есть свои минусы.

я бы выбрал (##символы решётки##)

Я думал ещё и об эргономике. Хотелось, чтобы символы форматирования были на обеих раскладках клавиатуры на одинаковых клавишах. Остался только «!», но это НЗ на тот случай, когда ещё что-то захочется.

     2019/08/17 06:48, MihalNik          # 

Написал Вам на почту через remdev, чтобы не было сомнений, продублировав там же в ЛС на случай проблемы с доставкой.

     2019/08/17 18:34, MihalNik          # 

Посмотрел, спасибо. В целом, документация 11l полнее и пояснения того или иного решения в свертках выглядит удобнее.

     2019/08/18 00:00, alextretyak          # 

Не хотите ли Вы сказать, что уже ничто не ново

Ну... я бы немного по-другому сказал. Всё новое — довольно спорно. Взять тот же Rust с его lifetimes/borrowing (я, кстати, до сих пор не могу найти пример хорошего кода на Rust, где эти lifetimes оправданны, все приводимые примеры в статьях по Rust либо надуманны, либо их можно легко переписать на C++ безо всяких lifetimes).

всё Вам настолько знакомо, что в каждом новом языке Вы видите отголоски старых?

Отчасти и это тоже. Но если посмотреть на эволюцию естественных языков, то можно заметить, например, что русский язык существенно не менялся уже более ста лет с реформы 1918 года, и практически/фактически не менялся с 1956 года. А с наступлением цифровой эпохи ни русский, ни английский, никакие другие естественные языки, скорее всего, меняться уже не будут. И я боюсь, что языки программирования постигнет та же участь — они «заморозятся» и их эволюция завершится, также как когда-то завершилась эволюция чисел. Ведь, никто не будет спорить с тем, что числа больше не будут эволюционировать? И не только/просто числа, а язык математики, скорее всего, тоже не будет больше эволюционировать!

Ну так приведите пример. Как я должен определить функцию func, чтобы я мог записать: func() = 123;

#include <iostream>

void func(int i) { std::cout << i; }

class Proxy
{
public:
void operator=(int i) { func(i); }
operator int() {
int r;
std::cin >> r;
return r;
}
};

Proxy func() { return Proxy(); }

int main()
{
func() = 123; // заменяется на func(123)
int i = func(); // возвращает число из cin
}

Хотелось, чтобы символы форматирования были на обеих раскладках клавиатуры на одинаковых клавишах.

А я использую AutoHotkey и у меня в обеих раскладках одинаковое поведение при наборе символов (например, Shift+2 — это всегда @, Alt+2 — это всегда кавычка ", Shift+3 — это всегда решётка #, а Alt+3 — это всегда № и т.д.).
Соответствующий скрипт можно посмотреть тут: http://pqmarkup.org/ru/ → «"Советы по набору’/‘способы набора’ символов одиночных парных кавычек ‘ и ’...» → «В этот же файл-скрипт можно дополнительно ещё добавить:».

И, если честно, я считаю проблему переключения раскладок несколько надуманной. Также весьма сомнительным считаю чрезмерное стремление повысить скорость набора кода (речь про слепую печать и т.д.). На первом месте должно быть качество кода или текста, а не его количество. Причём я наблюдал такую картину, что чем больше программист пишет кода, тем менее он качественный.
Вот пример из Вашей же статьи:
https://habr.com/ru/post/208474/

Ховик Меликян приводит пример, когда программа из 80000 строк кода на Си++ и 55000 строк кода на VB заменялась 10 строками на шелл-скрипте.

И чтобы получить более качественный текст (комментариев или писем), лично я использую два приёма:
1. Откладываю его отправку примерно на одни сутки.
2. Периодически перечитываю этот текст. Суммарно получается больше 10 раз точно. Ну и к чему мне эта пресловутая скорость набора, если на ревью и обдумывание/придумывание текста я трачу времени гораздо больше?

А что касается кириллицы в программировании, то, как можно видеть, например в языке КуМир (http://bsosh6.shkola.hc.ru/teachers_pashut/tuzov/kumir/manual.pdf) хотя и используются кириллические ключевые слова, но математические функции оставлены на английском (например, sqrt). И я считаю это оправданным.

... который не так бросается в глаза:
https://habrastorage.org/webt/gw/kz/es/gwkzes4_vqnxphhxqspvgzitw-i.png

А почему Вы не хотите заменять ссылку на картинку тегом <img src="ссылка-на-картинку" />? Эта картинка совсем небольшая. А руками копировать ссылку в адресную строку, чтобы посмотреть на картинку, очень неудобно.

P.S. Вы нечаянно сломали мою ссылку :():
http://forum.11l-lang.org/threads/Разработка-когнитивно-эргономического-синтаксиса-для-аппаратно-ориентированного-языка-программирования — неправильно
http://forum.11l-lang.org/threads/Разработка-когнитивно-эргономического-синтаксиса-для-аппаратно-ориентированного-языка-программирования.8/ — правильно.

Я думал ещё и об эргономике. Хотелось, чтобы символы форматирования были на обеих раскладках клавиатуры на одинаковых клавишах.

А как же (^^...^^) и (vv...vv)? Ведь этих символов/букв нет в русской раскладке. И если принять к рассмотрению требование «чтобы символы форматирования были на обеих раскладках клавиатуры на одинаковых клавишах», то под него не подпадают ни (""кавычки""), ни (//слэши//), ни (..точка..).

     2019/08/19 19:19, Автор сайта          # 

Всё новое — довольно спорно

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

примеры в статьях по Rust либо надуманны, либо их можно легко переписать на C++ безо всяких lifetimes

Концепция владения может и неуклюжа, но сама постановка вопроса правильна. Не должны сущности программы, у которых один владелец и несколько, быть неотличимы друг от друга для компилятора. Он тогда не может сделать многих оптимизаций. Да и программист не может написать программу оптимальнее. Что же касается претензий конкретно к Rust, но так и выделение блоков в программе прошло несколько этапов эволюции. Сперва «begin» и «end» в Алголе, потом «{» и «}» в Си, и только потом отступы в Питоне.

если посмотреть на эволюцию естественных языков

А не надо на неё смотреть. Мы ж имеем дело с искусственными языками, а не с естественными. У них разные вектора развития. Разница между Коболом и Хаскеллем куда существеннее, чем, допустим, между современным русским и допушкинским.

языки программирования постигнет та же участь — они «заморозятся» и их эволюция завершится

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

А я использую AutoHotkey

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

сомнительным считаю чрезмерное стремление повысить скорость набора кода

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

А почему Вы не хотите заменять ссылку на картинку тегом

Когда-то мой сайт раздавал ссылки налево и направо. Но потом обнаружил, что поисковые системы оценивают мой сайт как ссылочную помойку. Хотя все ссылки строго по теме. В следующей версии сайта попробую автоматическое добавление ссылок с признаком «nofollow».

А как же (^^...^^) и (vv...vv)?

Они очень «в тему». А вот визуальной разницы между «==» и «##» особо нет. Но эргономическая разница — есть.

(""кавычки""), ни (//слэши//), ни (..точка..)

Ну так требование «чтобы символы форматирования были на обеих раскладках клавиатуры на одинаковых клавишах» очень трудно выполнить. В распоряжении — малая толика символов.

     2021/03/27 12:08, Виталий Монастырский          # 

Предлагаю господам не спорить по поводу востребованности различных систем исчисления — востребованы все, даже восьмеричная, которая до сих пор используется в 8-битных микроконтроллерах. 16 бит постоянно используются во всех видах криптографии, а без неё не обходится ни одна отправка пакета данных в интернете. Системы счисления больше 16 бит используются в сжатии данных аж до base64 включительно. Так что если мы делаем универсальный ЯП, то нужно поддерживать ВСЕ системы счисления, нравится это кому-то или нет.

А вот по поводу отображения этих самых систем счисления я до сих пор думаю — как лучше все это дело организовать. С одной стороны запись дополнительных символов — это избыточность, а с другой позволяет реализовывать утиную типизацию. Казалось бы — какие вопросы — бери да делай... но... на самом деле речь идет ведь не только о том — как будут записывать числа программисты, но и о том, как они будут поступать в программу из различных источников, в которых по умолчанию не согласовано представление различных систем счисления. Где-то 16-ричная система представлена 0x в начале, а где-то h в конце числа. Поди разберись... А так как разбираться всё равно придется, то встает вопрос о смысле этих самых обозначений. Раз реализовать однозначную утиную типизацию не удастся и всё равно придется как-то обозначать для компилятора — с чем мы имеем дело, то этот способ и имеет смысл делать основным. У меня это дополнительный параметр в рамках концепции абсолютной типизации, который применяется для числовых типов, поддерживающих различные системы счисления, в котором явно указывается система счисления, в рамках которой требуется производить обработку данного числа — принимать и выводить. Задается явным образом. Похоже от этого нам никуда не деться. Хотя я, конечно, подумываю о том, чтобы ещё дополнительно сделать именно символьную реализацию определения этого самого параметра... Но как реализовать ещё — не решил.

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Содержание

Каким должен быть язык программирования?

Анализ и критика

●  Устарел ли текст как форма представления программы

●  Русский язык и программирование

●  Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

●  Некоторые «вкусности» Алгол-68

●  «Двухмерный» синтаксис Python

●  Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

●  Должна ли программа быть удобочитаемой?

●  Стиль языка программирования

●  Тексто-графическое представление программы

●●  Разделители

●●  Строки программы

●●  Слева направо или справа налево?

●  Комментарии

●●  Длинные комментарии

●●  Короткие комментарии

●●  Комментарии автоматической генерации документации

●●  Нерабочий код

●●  Помеченные комментарии

●  Нужны ли беззнаковые целые?

●  Шестнадцатиричные и двоичные константы

●  Условные операторы

●  Переключатель

●  Циклы

●●  Продолжение цикла и выход из него

●  Некошерный «goto»

●  Изменение приоритетов операций

●  Операции присвоения и проверки на равенство. Возможно ли одинаковое обозначение?

●  Так ли нужны операции «&&», «||» и «^^»?

●  Постфиксные инкремент и декремент

●  Почему в PHP для конкатенации строк используется «.»?

●  Указатели и ссылки в C++

●●  О неправомерном доступе к памяти через указатели

●  Обработка ошибок

●  Функциональное программирование

●●  Нечистые действия в чистых функциях

●●  О чистоте и нечистоте функций и языков

●●  Макросы — это чистые функции, исполняемые во время компиляции

●●  Хаскелл, детище британских учёных

●●  Измеряем замедление при вызове функций высших порядков

●●  C vs Haskell: сравнение скорости на простом примере

●●  Уникальность имён функций: за и против

●●  Каррирование: для чего и как

●●  О тестах, доказывающих отсутствие ошибок

●  Надёжные программы из ненадёжных компонентов

●●  О многократном резервировании функций

●  Использование памяти

●  Почему динамическое распределение памяти — это плохо

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

●●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●●  Массивы переменной длины в C/C++

●●  Размещение объектов в стеке, традиционный подход

●●  Размещение объектов переменной длины с использованием множества стеков

●●  Размещение объектов переменной длины с использованием двух стеков

●●  Реализация двухстековой модели размещения данных

●●  Двухстековая модель: тесты на скорость

●●  Изменение длины объекта в стеке во время исполнения

●●  Размещение объектов переменной длины с использованием одного стека

●  Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

●  Безопасность и размещение объектов переменной длины в стеке

●  Массивы, структуры, типы, классы переменной длины

●  О хранении данных в стеке, вместо заключения

●  Реализация параметрического полиморфизма

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Новости и прочее




Последние отзывы

2024/03/19 02:19 ••• Ivan
Энтузиасты-разработчики компиляторов и их проекты

2024/03/18 23:25 ••• Автор сайта
Надёжные программы из ненадёжных компонентов

2024/03/18 22:44 ••• Автор сайта
О многократном резервировании функций

2024/03/17 17:18 ••• Городняя Лидия Васильевна
Раскрутка компилятора

2024/03/10 18:33 ••• Бурановский дедушка
Русской операционной системой должна стать ReactOS

2024/03/07 14:16 ••• Неслучайный читатель
«Двухмерный» синтаксис Python

2024/03/03 16:49 ••• Автор сайта
О неправомерном доступе к памяти через указатели

2024/02/28 18:59 ••• Вежливый Лис
Про лебедей, раков и щук

2024/02/24 18:10 ••• Бурановский дедушка
ЕС ЭВМ — это измена, трусость и обман?

2024/02/22 15:57 ••• Автор сайта
Русский язык и программирование

2024/02/19 17:58 ••• Сорок Сороков
О русском языке в программировании

2024/02/16 16:33 ••• Клихальт
Избранные компьютерные анекдоты

2024/02/10 22:40 ••• Автор сайта
Все языки эквивалентны. Но некоторые из них эквивалентнее других