Считается, что знаки повышают выразительность языка программирования, поскольку делают текст программы более лаконичным. С этим трудно не согласиться, но есть
и обратная сторона. По сравнению с обычными словами знаки требуют дополнительных умственных усилий при их осмыслении человеком.
Далее подробно рассмотрены факторы, влияющие на трудоёмкость осмысления знаков, а именно:
проговариваемый знак или разделительный;
относительное расположение знака;
нагруженность знака и его расположения;
таблица приоритетов операций, обозначаемых знаками;
очевидность и стандартность знака.
Эти факторы лежат в основе правил для отсеивания неудачных вариантов при выработке системы знаков в языках программирования. Правила сформулированы в конце. Они используются в том числе при разработке семейства языков Артель.
Цена лаконичности знаков
Начать размышления имеет смысл с базовых операций и их обозначений в нескольких языках программирования.
C#/Java Oberon-07 Pascal Артель
= := := = == = = == != # <> != && & and и || OR or или ! ~ not не
5/6 3/6 2/6 2/6
По этой таблице можно заметить, что первый столбец воспринимается сложнее по сравнению с остальными. Сложность коррелирует с дробями, указанными внизу таблицы. Это удельное число знаков, которые не присущи школьной литературе и математике (либо имеют там
совершенно иной смысл).
Чтобы понять трудоёмкость осмысления знаков, стоит кратко коснуться самого процесса осмысления текста человеком. Этот процесс представляет собой внутренний монолог – человек мысленно проговаривает слова для построения смыслов в собственном воображении.
Необходимость мысленно проговаривать слова текста, вероятно, связана с тем, что речь предшествует письменности. Человек сначала учится распознавать окружающую речь и говорить, и лишь затем писать и читать. Соответственно читаемые слова и знаки человек осмысливает через более базовый аппарат – речевой.
В речи человека есть слова, но нет знаков. Для проговаривания увиденного знака мозгу приходится сначала искать соответствующее знаку слово. Если нет слова, то нет понимания. Поэтому даже матёрый профессионал вынужден осмысливать знаки &&, ||, ! через проговаривание их в уме в виде слов и, или, не. Новичку же для начала нужно натренировать свой мозг на проговаривание знаков нужными словами.
а && б а и б а || б а или б !а не а
Попутно новичку приходится ломать все свои представления о том, где обычно пишут восклицательный знак. Ведь и в литературе, и в математике восклицательный знак принято
записывать после чего-то, а не до. Однако не забывать при этом, что всё-таки восклицательный знак может быть записан и после чего-то, придавая уже совсем другой смысл.
!а а! !(а || б) ф!(а || б)
И тут возникает закономерная мысль. А стоит ли эта ломка того, чтобы сокращать слово из двух букв не до одного знака !?.. И зачем нагружать мозг лишней работой по превращению знаков в слова «и», «или», «не», если сами слова и так предельно короткие?.. Ведь жизнь уже поработала над их лаконичностью.
Можно, конечно, рассуждать о том, что по сравнению со словами, знаки позволяют также экономить на пробелах. Но осмысливать длинные непрерывные последовательности букв и знаков человеку крайне тяжело.
!(а.выкл||а.сбой&&а.резервирование)
Поэтому на практике пробелы всё же оставляют. И тогда оказывается, что разница в лаконичности между знаками и словами в логических выражениях практически
отсутствует.
!(а.выкл || а.сбой && а.резервирование) не(а.выкл или а.сбой и а.резервирование)
По сути, более лаконичным по сравнению со словами можно назвать лишь тривиальный случай записи с восклицательным знаком, когда отрицаемое им не содержит пробелов. Но зачем дополнительная лаконичность в тривиальных случаях?
если !вкл тогда ... если не(вкл) тогда ...
Выше затронут фактор пробелов. Они сильнейшим образом влияют на восприятие текста человеком. В античности все слова записывали слитно без пробелов. Читать было тяжело, поэтому слова начали разделять средними точками, а позднее просто пробелами.
PERASPERAADASTRA PER·ASPERA·AD·ASTRA PER ASPERA AD ASTRA
С развитием естественных языков начали появляться и другие разделительные знаки, например, знаки пунктуации. Они использовались для управления интонацией при чтении
вслух: паузы, восклицания, вопросы и т.д. При чтении про себя эти знаки помогают легче распознавать структуру текста и акценты. Такие знаки не требуют обязательного проговаривания в виде слов при чтении.
. , ; : ! ? !? ...
А проговариваемые знаки появились позднее разделительных как средство повышения лаконичности и выразительности в науках, например, в арифметике.
а = б + в а равно б плюс в
Проговариваемые знаки требуют больше умственных усилий для осмысления, чем разделительные. Это стоит учитывать при выборе знаков для языка программирования.
Число[] [] проговаривается как «массив» []Число [] проговаривается как «массив» Массив<Число> < и > являются разделительными
На умственные усилия влияет также расположение знака относительно того, к чему он применяется. Расположение бывает правостороннее, левостороннее, внутреннее,
открывающее и закрывающее. Все эти разновидности расположений применяются и в школьной литературе, и в математике, и в программировании.
Привет! правостороннее #программирование левостороннее @пользователь левостороннее -а левостороннее а - б внутреннее человек-амфибия внутреннее (фрагмент текста) пара: открывающее, закрывающее "Текст в кавычках" и открывающее и закрывающее м[...] правосторонне-открывающее
Опираясь на опыт чтения самых разнообразных текстов со всевозможными комбинациями расположения знаков, можно заметить следующее:
правостороннее, открывающее и закрывающее расположение наиболее распространённое, поэтому его осмысливать легче всего;
внутреннее расположение менее распространено, поэтому осмысливать его уже тяжелее;
левостороннее расположение наименее распространено, поэтому осмысливать его тяжелее всего;
Если знак располагается так, как это не принято в школьной литературе и математике, то это существенно увеличивает умственные усилия по осмыслению.
!вкл! ?название ?объект?.код !объект!.код []Число Число[]
Затруднение в таких случаях связано с тем, что мозг вынужден убеждаться, что это не ошибка, а намеренная запись. Ведь несвойственная вещь нуждается в перепроверке. Для этого мозгу приходится изучать окрестности вокруг знака.
Один и тот же знак может предполагать сразу несколько расположений. И каждое расположение может иметь несколько разных смыслов в зависимости от контекста. Поэтому один и тот же знак может быть нагружен многими смыслами, порой вообще не связанными между собой.
Число 1.234,5 меньше числа 5.432,1. если а + б = 0, то б = -а
В примере выше знак точки в самом конце расположен справа и означает окончание предложения, а в числах он расположен внутри и означает разделение частей числа. А знак равно расположен между переменными и нагружен как вопросительным (сравнительным), так и утвердительным смыслом.
Нагруженность знака многочисленными расположениями и смыслами существенно увеличивает трудоёмкость осмысления. По этой причине следует с осторожностью относится к идее вводить левостороннее расположение знака в дополнение к правостороннему, когда знаков перестаёт хватать.
а? ?а
Цена неочевидности приоритетов
Отдельного внимания заслуживают левостороннее и внутреннее расположение знака.
!а а || б а && б
Их осмысление требует кроме всего прочего ещё и поиска границ того, на что знак воздействует. В языках программирования в таких ситуациях в дело вступает таблица приоритетов операций, которые этими знаками обозначаются. Именно эта таблица определяет границу того, на что знак воздействует.
!а!.б! || в == г
Точный смысл:
(!(а!.б!)) || (в == г)
Процесс осмысления:
(!а!.б! || в == г отсекаем правостороннюю форму (!(а!.б! || в == г начинаем поиск правой границы (!(а)!.б! || в == г (!(а!).б! || в == г (!(а!.)б! || в == г (!(а!.б)! || в == г (!(а!.б!) || в == г упёрлись в меньший приоритет ... (!(а!.б!)) || (в == г) похоже это именно оно ... (!(а!.б! || в == г) не похоже на правду
Для сравнения:
не(а!.б!) или в == г
Ситуация усугубляется тем, что из-за обилия знаков и слов в современных языках программирования их таблицы приоритетов такие огромные, что их никто не знает и даже не пытается запоминать. Для примера, одна из самых простых таблиц приоритетов среди современных промышленных языков:
Постфиксные ++ -- Унарные ++ -- + - ~ ! Умножение * / % Сложение + - Сдвиги << >> >>> Отношения < > <= >= instanceof Сравнения == != Бинарное «и» & Бинарное «искл» ^ Бинарное «или» | Логическое «и» && Логическое «или» || Тернарные ? : Присваивания = += -= *= /= %= &= ^= |= <<= >>= >>>=
Со временем, натренировав свой мозг на распознавание определённых знаков в рамках какого-то языка с какой-то таблицей приоритетов, профессиональный программист
перестаёт чувствовать всю их сложность. Вроде бы как и нет проблемы.
Но это только до тех пор, пока профессионал не столкнётся в каком-то другом языке с новыми знаками, их новым качеством или другой таблицей приоритетов. Например, с левосторонним расположением знака вопроса, который в таком виде встречается крайне редко.
?а!.б! || в == г "?" работает также как "!" или нет?
Если профессионалу приходится иметь дело одновременно с тремя и более языками программирования, то постоянно переключать в голове знаки и таблицы приоритетов
становится проблематично. И чтобы избавиться от сомнений, ему становится проще явно обозначать границы и приоритеты с помощью круглых скобок и пробелов. Чтобы действовать наверняка и без всяких сюрпризов.
(?(а!.б!)) || (в == г)
Таким образом, сложность осмысления левостороннего и внутреннего расположения знака напрямую зависит от сложности таблицы приоритетов операций. И каждый такой случай, тем более незнакомый и непривычный, является испытанием и для новичков, и для профессионалов. А поскольку зачастую такой знак нагружен многими смыслами, то сложность начинает зашкаливать.
А вот правостороннее расположение считывается легко, поскольку порядок применения знака просто соответствует порядку его записи в тексте.
Всё это свидетельствует о принципиальной важности количества знаков в языке и важности размера таблицы приоритетов. Таблица приоритетов это не просто справочник. Это та незримая работа, которую мозг проделывает при виде каждого знака. И это стоит учитывать при выработке системы знаков в языке.
Польза стандартных знаков
Трудоёмкость осмысления знака зависит также от его стандартности. Это единое понимание знака в рамках того или иного сообщества людей. Можно условно выделить очевидные, стандартные профессиональные и нестандартные знаки.
Очевидные знаки человек осваивает через школьную литературу и математику. И они постоянно на виду в повседневной жизни. Поэтому они наиболее понятны самому широкому кругу людей. Вот список очевидных знаков, которые в программировании удобно использовать со смыслом, близким к литературному или математическому:
Проговариваемые: = равно (теперь равно, изменить на) + плюс - минус * умножить на / поделить на < меньше <= меньше либо равно > больше >= больше либо равно -> превращается в => следовательно Разделительные: , разделитель перечисляемых элементов ; разделитель самостоятельных фраз " начало и конец обособленного текста () начало и конец подчинённого фрагмента
Стандартные профессиональные знаки не являются очевидными для обычного человека, но широко используются в программировании и имеют одинаковое расположение и смысл в подавляющем большинстве наиболее популярных языков программирования (с заданной областью применения и целевой аудиторией).
Проговариваемые: == равно != не равно += увеличить на -= уменьшить на *= приумножить (в N раз) /= сократить (в N раз) % взять остаток от деления на ! не (отрицание, левостороннее расположение) Разделительные: . уточнение имени : указание типа данных [] начало и конец списка ключей или элементов {} начало и конец блока // комментарий \ экранирование
Нестандартные знаки используются в своём конкретном смысле лишь в ограниченном количестве языков программирования. Поэтому они понятны в основном тем, кто постоянно имеет с ними дело по роду своей деятельности.
?: !! ..< &<< &>> &* ~= и др.
С очевидными знаками сталкиваются все образованные люди по мере изучения школьной литературы и математики. Но изучение остальных знаков, будь они стандартные профессиональные или нестандартные, должно иметь некоторую целесообразность.
Зачем новичку тренировать свой мозг на распознавание нестандартных знаков? Ведь затем при изучении популярных языков программирования придётся заново осваивать уже стандартные знаки.
Учимся: а := б если а = б & в # г тогда ... Переучиваемся: а = б если а == б && в != г тогда ...
От детей постоянно звучит веский аргумент, что изучаемый ими в школе язык программирования «не настоящий и не пригодится в жизни». Честно говоря, на это сложно что-то возразить, даже если вы, как и автор этой статьи, душой тяготеете к какому-нибудь «ненастоящему» языку и считаете первый вид записи в примере выше более элегантным. Но с реальностью тоже приходится считаться.
Парадоксальным образом стандартность знака может быть более важна для профессионала, чем для новичка. Ведь если профессионал вынужден иметь дело одновременно с несколькими языками, то при частом переключении между ними легко запутаться и в знаках, и в смыслах. Знак становится не просто нагружен, а перегружен всевозможными смыслами.
~a логическое или битовое? ~"а" маркер? или есть понятие отрицания текста? ?a что бы это могло значить...
И самый матёрый полиглот, и закоренелый фанат, и крепкий середнячок превращается в растерянного новичка, когда видит в языке программирования знак, который раньше не видел или подзабыл со временем, или который до сего момента значил для него нечто другое. О
новичках, середнячках, фанатах и полиглотах подробнее в здесь.
Тут важно заметить, что когда-то все знаки были нестандартными, включая арифметические. И стандартными они стали лишь со временем. А однажды могут и перестать ими быть, если практика выявит в них изъяны. Поэтому порой не нужно стесняться подвергать сомнению даже самые стандартные знаки.
Например, можно подумать над тем, чтобы отказаться от стандартных знаков << и >> для обозначения битовых сдвигов. Такие знаки осложняют использование одиночных знаков < и > в качестве угловых скобок, например, при обозначения параметров в шаблонах типов
Массив<Число>. Ведь при наличии угловых скобок знак >> перестаёт быть однозначной лексемой.
Массив<Массив<Число>> >> или же > и ещё раз >
Это одна из причин, по которой знаки битовых операций отсутствуют в списке стандартных выше.
Правила отсеивания знаков
Создание языка программирования и выработка его системы знаков – процесс творческий. А продуктивный творческий процесс нуждается хотя бы в минимальных правилах.
С учётом всего вышесказанного о трудоёмкости осмысления знаков, правила отсеивания неудачных вариантов могут выглядеть так:
знак не подходит, если он в таком же качестве применяется менее, чем в {А}% самых популярных языков;
знак не уместен, если его расположение чуждо школьной литературе и математике;
знак не нужен, если программист видит обозначаемое им понятие в тексте программы
реже одного раза в {Б} дней;знак не целесообразен, если существует полное или сокращённое слово длиной до {В} букв включительно;
но знак может быть исключением из правил, если в языке программирования не более {Г} таких исключений.
Путём подстановки нужных значений А-Б-В-Г можно ограничить себя определёнными рамками.
Например, формула 70-365-3-1 фиксирует, что в языке допустимы лишь очевидные и стандартные знаки с таким же смыслом как минимум в 70% наиболее популярных языков,
нужные программисту не реже одного раза в 365 дней и не имеющие подходящего полного/сокращённого слова длиной до 3 букв включительно, но с правом на 1 исключение из всех этих правил.
Формулы 70-900-4-3 и 70-100-3-0 используются в языках семейства Артель.
Сами формулы можно использовать не только как ограничительные рамки при выработке системы знаков, но и как способ оценки уже существующих систем знаков.
Справочник
Полный список формальных характеристик знака:
Очевидный : да/нет Стандартный : да/нет Нестандартный : да/нет Проговариваемый : да/нет Разделительный : да/нет Расположение правостороннее : да/нет Расположение внутреннее : да/нет Расположение левостороннее : да/нет Расположение открывающее : да/нет Расположение закрывающее : да/нет Вариативность расположения : от 1 до 7 Чуждость расположения : от 1 до 6 Нагрузка : целое число Нагрузка расположения : целое число
В расчётах и анализе каждое расположение знака с каждым конкретным смыслом для заданного контекста рассматривается как отдельный знак.
Дополнительные определения:
вариативность расположения – это количество возможных расположений знака без учёта смысловой нагрузки;
чуждость расположения – это количество возможных расположений знака, которые не встречаются в школьной литературе и математике;
нагрузка знака – это количество смыслов, которые может иметь знак в зависимости от расположения и контекста;
нагрузка расположения – это количество смыслов, которые может иметь одно конкретное расположение знака в зависимости от контекста.
Комментарии (17)

vadimr
09.03.2026 18:42Что касается существа вопроса, рассмотренного в статье, то все эти рассуждения применимы только к семейству алголоподобных языков (которые, правда, охватывают более 90% практического программирования). Упомянутый выше APL, Lisp, Forth и тому подобные языки с организованным по другим принципам синтаксисом не укладываются в эту классификацию. Синтаксис таких языков не ставит своей целью приближение к естественному языку, а строится в направлении рациональной организации.
Допустим, программу на Лиспе практически невозможно "проговорить" из-за скобок (то есть форм, имеющих чисто визуальный или скорее даже абстрактно-структурный характер). Это же относится, например, к XML/HTML.

wmlab
09.03.2026 18:42Все гораздо хуже - в архаичных языках даже часть букв опускалась для уменьшения трудоемкости написания или вырезания. Например, RN - "имя" на древнеегипетском. Как это слово произносилось, историки не знают - "рен", "рун" или "аран"? Не экономьте символы :)

artptr86
09.03.2026 18:42Не совсем в этом дело. Древнеегипетский — семитский язык (или близок к ним). А в этих языках гласные звуки не играют такой роли, как в индоевропейских.

bentall
09.03.2026 18:42Есть Cobol. Один из старейших языков программирования. Абсолютная читаемость (для знающих английский) абсолютная многословность, невысокая выразительность. Жив в финансовой сфере, в основном на мейнфреймах, сообщество GNU развивает целых две свободных реализации. Более высокоуровневый (но менее универсальный) язык с тем же подходом — SQL. Да, я бы ещё обратил внимание тех кому хочется смотреть в эту сторону, на lsFusion. Открытый DSL, эдакий расширенный SQL, ориентированный на «околобухгалтерию».
Есть APL, он не намного моложе кобола. Прямо противоположный подход: компактная математическая запись, специальный набор символов. Тоже живёт в финансовой сфере, только ближе к аналитическому отделу, чем к бухгалтерии. У этого языка есть несколько более или менее похожих на него потомка: J/K/BQN, имеющих свободные и/или коммерческие реализации. Эталонный коммерческий Dialog APL free for personal use и доступен для самых различных платформ, начиная с Raspberry Pi.
Но мейнстрим, все знают, языки с синтаксисом Си. Слегка выделяется python, время от времени вырывающийся на вершину рейтингов, популярен в своей нише и больше похожий на Паскаль lua (или похожая, её зовут Луна), но в целом тенденция ясна.
Четвёртый путь — и это опять один из старейших языков: lisp. Даже те кто ни разу не имел дело с одним из его диалектов, знаком с подобной формой записи благодаря XML или JSON.
Меня вы спросите, где здесь мораль, я направлю свой взгляд в туманную даль...©
...Каждый выбирает по себе...©

msdos9
09.03.2026 18:42Cobol... Абсолютная читаемость (для знающих английский) абсолютная многословность, невысокая выразительность.
В дремучих 90-х несколько лет кодил на Коболе. Листинги конечно были километровые, но читалось МНЕ гораздо легче, чем нонешние си-подобные .

TastaBlud
09.03.2026 18:42Считаю, что в данном вопросе следует учитывать не только восприятие "новичка" (человека, не знакомым с некоторым языком или только вошедшим в сферу) но и написание, а также частоту употребления знаков и слов.
Так, я быстро сбежала от языков бейсико и паскале подобных, именно из-за того (и других причин тоже), что кодовые блоки писались многословно - все эти BEGIN-END, а также что для каждой конструкции было своё обозначение - FOR обязательно заканчивался NEXT, но WHILE - ENDWHILE, а LOOP - ENDLOOP. И поскольку эти ключевые слова нужно было писать ПОСТОЯННО - это было очень утомительно, а потому (для лично меня) запись { } однозначно выиграла. При этом "не прижились" ни C/C++ из-за чрезмерного перегруза :: и < > (но при этом, как ни странно, в Java они пришлись кстати), а также раздражает PHP унаследованным наследием писать -> вместо .
Но при этом я решительно отказываюсь писать and or вместо && || - поскольку они хорошо визуально отделяют выражения, как могли бы отделять скобки.
И даже в той же Java меня возмущает использование ключевых слов extends и implements вместо краткой : что было бы (имхо) намного более логично, тем более, что большой смысловой нагрузки эти слова не несут.
И неимоверно возрадовалась я, когда наконец появился оператор switch не требующий отделения ветвей оператором break - но уверена, что найдутся и те, кто заявит, что без него снижается читаемость.
А также (я считаю) для языка очень важна смысловая разгрузка: так, очень утомительно в C/C++ в уме манипулировать арифметикой указателей (вот где указать оператор * и где &, где посчитать размер структуры и сложить правильно) и арифметикой в принципе - когда для этого существуют другие средства (и не обязательно это сборщик мусора) - просто, пожалуйста, дайте при разработке языка сосредоточиться не на том, КАК надо делать, а на том, ЧТО мы хотим сделать.
В итоге что имеем: да, в свое время C/C++ стал прорывом и образцом для подражания. Аплодисменты. Но многие языки слишком дословно восприняли миссию "чтобы программисты C/C++ быстро переучились" и переняли откровенно неудачные архитектурные решения (например, тот же switch с break) и до сих пор многие программисты жертвуют собой и скоростью разработки именно в угоду "думать как машина", хотя сама "машина" - а точнее, компилятор, в общем научился угадывать замыслы программиста и проводить такие оптимизации, которые делают "мышление ближе к железу" ненужным.
Как пример, могу привести эволюцию смены языка с Java на Kotlin - благодаря встроенным функциям коллекций и управления потоком (я имею ввиду блочные функции apply, let, run и map), а также богатой стандартной библиотеке и удобного синтаксического сахара вроде функций-расширений - я могу записать алгоритм в виде "что я хочу" в одну строку вместо несколько низкоуровневой портянки "как это нужно сделать" - в Java для этого мне приходится или писать методы утилит или пользоваться сторонними библиотеками вроде Commons Collections или Lombok - и я чувствую, что напрасно трачу время и усилия для этого.
Что может быть хуже этого - да только "полностью адаптированные для человека" языки вроде SQL - вроде бы нормальные английские слова, но приходится писать их не как прозу, а как программу, и это не только сбивает с толку, но и рождает множество ограничений. На этом фоне немного выигрышнее смотрятся разные Query Builderы как тот же LINQ и прочие.
И ещё один эксперимент в виде Python: да, там в пользу читаемости отказались от знаков в пользу форматирования - и вот это самое форматирование часто подводит - кто-то при copy-paste теряет пробелы, кто-то самовольно меняет табы на пробелы и наоборот, кто-то по-своему устанавливает отступы на свои - и это всегда приходится перепроверять. А передача self везде - она излишняя при постоянном использовании, но очень нагружает психологически и при написании и при чтении. И приоритет функциональной записи operation(operand) вместо объектной operand.opetation() тоже субъективно напрягает (меня, а тысячи людей видят в этом благо)...
Вывод такой: да, в своё время C/C++ победил, но не стоит их них копировать всё. При разработке языка стоит всё-таки пописать много псевдопрограмм, чтобы оценить затрачиваемые усилия как при чтении, так и при записи - и тогда решить, какой вариант записи удобнее, насколько проще написать компилятор чтобы он не путался в наших намерениях. А универсального рецепта нет - на подобные топику статьи "вы ничего не понимаете, проще вот так делать!" найдутся и сотни несогласных, которым удобнее как раз наоборот. Как и с моим комментарием также многие не согласятся - и это прекрасно, мы все разные.

poruchuk_Rzevski
09.03.2026 18:42Меня всегда бесил Паскаль. Не только из за бегин-ендов и всяких тупых ограничений, но и из за оператора присвоения :=
Присвоение - одна из самых частых встречающихся операций в програмировании. И вдруг - в два раза больше символов, да ѝ читаемость никак не улучшается.
Ну, а если && и || непонятны, то можете их задифайнить под and и or в конце концов. Или - писать на бейсике. :)
kmatveev
Нет. Это и весь предыдущий заход про внутренний монолог - неправда. Никто не проговаривает символы, они воспринимаются напрямую.
Да, стоит.
Вся апелляция к письменному языку и устной речи безосновательна. Математики и программисты на APL и его потомках не дадут соврать.
alexxisr
Да, да. Спросите китайцев/японцев и прочих иероглифо-пишущих.
vadimr
Практика изучения китайского языка как иностранного (что близко к изучению языка программирования) показывает, что можно с равной вероятностью забыть написание иероглифа, его произношение или его смысл. Хотя носители по понятной причине чаще забывают или не знают написание.
Evil_Punker
После усвоения приличного объема кандзи читать тексты изложенные катаканой/хираганой становится мучительно. В своё время занимался скорочтением на русском языке — там исключение момента с "проговариванием" является ключевым в развитии навыка
aamonster
Вот-вот. И это, отмечу, в естественном языке, ориентированном на передачу устной речи. Код же вообще иначе воспринимается.
А поднятая автором тема яйца выеденного не стоит: с одного синтаксиса на другой той же парадишмы переходишь легко. Что есть значки, что нет их – день на привыкнуть. Вот приоритеты да, не всегда на кончиках пальцев. Поэтому просто ставим скобки.
ychetyrko Автор
Да, существуют техники чтения без проговаривания не то что знаков, но и слов. Однако ими владеет очень малое число людей.
При этом, даже без техник быстрого чтения, знаки действительно в определённый момент могут начать восприниматься очень быстро, почти напрямую. Однако для этого с этими знаками нужно иметь дело непрерывно, много раз в день, на протяжении длительного промежутка времени. Это возможно, если программировать только на одном языке.
Если же приходится иметь дело с разными языками программирования, то, к сожалению, в разных языках программирования разное представление о том, что значит каждый знак. Это препятствует выработке навыка прямого восприятия того или иного знака.
kmatveev
Про "малое число людей" - с чего вы взяли? Художественную литературу я, например, читаю визуализируя происходящее, будто смотрю кино, мне не нужно проговаривать. Но, кстати, если в книжке происходит диалог, то я слышу, как персонажи проговаривают свои фразы. Скорочтением не владею. Математические формулы я воспринимаю символически, я не проговариваю в голове "интеграл от 0 до n по dx от ...", я понимаю его без этого.
Насчёт "одного языка" - тоже мимо. Внутри одного дня я пишу код на Java, SQL, bash, q, читаю код на C++ и Python - никаких проблем с прямым восприятием. Я думаю, что я вполне заурядный программист. Дело привычки.
bfDeveloper
Либо я и моё окружение - сплошные гении, либо нет в этом ничего сложного. Код воспринимается как логическая конструкция без проговаривания отдельных символов. Я у половины даже коротких названий не знаю. Это же тот же навык, что чтение про себя и по диагонали - им обладает большинство читателей хабра или других соц сетей.
И я спокойно переключаюсь между разными языками программирования, лишь иногда подтормаживая на самых нетипичных конструкциях. Но они могут быть даже прописаны словами и от этого они проще или нетипичнее не становятся. Оператор присваивания в C++ и JS это совершенно разные операторы независимо от того будут ли они выглядеть одинаково или нет.