Comments 17
В речи человека есть слова, но нет знаков. Для проговаривания увиденного знака мозгу приходится сначала искать соответствующее знаку слово. Если нет слова, то нет понимания. Поэтому даже матёрый профессионал вынужден осмысливать знаки
&&,||,!через проговаривание их в уме в виде слови,или,не
Нет. Это и весь предыдущий заход про внутренний монолог - неправда. Никто не проговаривает символы, они воспринимаются напрямую.
А стоит ли эта ломка того, чтобы сокращать слово из двух букв
недо одного знака!?.. И зачем нагружать мозг лишней работой по превращению знаков в слова «и», «или», «не», если сами слова и так предельно короткие?
Да, стоит.
Вся апелляция к письменному языку и устной речи безосновательна. Математики и программисты на APL и его потомках не дадут соврать.
Никто не проговаривает символы, они воспринимаются напрямую.
Да, да. Спросите китайцев/японцев и прочих иероглифо-пишущих.
Практика изучения китайского языка как иностранного (что близко к изучению языка программирования) показывает, что можно с равной вероятностью забыть написание иероглифа, его произношение или его смысл. Хотя носители по понятной причине чаще забывают или не знают написание.
После усвоения приличного объема кандзи читать тексты изложенные катаканой/хираганой становится мучительно. В своё время занимался скорочтением на русском языке — там исключение момента с "проговариванием" является ключевым в развитии навыка
Вот-вот. И это, отмечу, в естественном языке, ориентированном на передачу устной речи. Код же вообще иначе воспринимается.
А поднятая автором тема яйца выеденного не стоит: с одного синтаксиса на другой той же парадишмы переходишь легко. Что есть значки, что нет их – день на привыкнуть. Вот приоритеты да, не всегда на кончиках пальцев. Поэтому просто ставим скобки.
Да, существуют техники чтения без проговаривания не то что знаков, но и слов. Однако ими владеет очень малое число людей.
При этом, даже без техник быстрого чтения, знаки действительно в определённый момент могут начать восприниматься очень быстро, почти напрямую. Однако для этого с этими знаками нужно иметь дело непрерывно, много раз в день, на протяжении длительного промежутка времени. Это возможно, если программировать только на одном языке.
Если же приходится иметь дело с разными языками программирования, то, к сожалению, в разных языках программирования разное представление о том, что значит каждый знак. Это препятствует выработке навыка прямого восприятия того или иного знака.
Про "малое число людей" - с чего вы взяли? Художественную литературу я, например, читаю визуализируя происходящее, будто смотрю кино, мне не нужно проговаривать. Но, кстати, если в книжке происходит диалог, то я слышу, как персонажи проговаривают свои фразы. Скорочтением не владею. Математические формулы я воспринимаю символически, я не проговариваю в голове "интеграл от 0 до n по dx от ...", я понимаю его без этого.
Насчёт "одного языка" - тоже мимо. Внутри одного дня я пишу код на Java, SQL, bash, q, читаю код на C++ и Python - никаких проблем с прямым восприятием. Я думаю, что я вполне заурядный программист. Дело привычки.
Либо я и моё окружение - сплошные гении, либо нет в этом ничего сложного. Код воспринимается как логическая конструкция без проговаривания отдельных символов. Я у половины даже коротких названий не знаю. Это же тот же навык, что чтение про себя и по диагонали - им обладает большинство читателей хабра или других соц сетей.
И я спокойно переключаюсь между разными языками программирования, лишь иногда подтормаживая на самых нетипичных конструкциях. Но они могут быть даже прописаны словами и от этого они проще или нетипичнее не становятся. Оператор присваивания в C++ и JS это совершенно разные операторы независимо от того будут ли они выглядеть одинаково или нет.
Что касается существа вопроса, рассмотренного в статье, то все эти рассуждения применимы только к семейству алголоподобных языков (которые, правда, охватывают более 90% практического программирования). Упомянутый выше APL, Lisp, Forth и тому подобные языки с организованным по другим принципам синтаксисом не укладываются в эту классификацию. Синтаксис таких языков не ставит своей целью приближение к естественному языку, а строится в направлении рациональной организации.
Допустим, программу на Лиспе практически невозможно "проговорить" из-за скобок (то есть форм, имеющих чисто визуальный или скорее даже абстрактно-структурный характер). Это же относится, например, к XML/HTML.
Все гораздо хуже - в архаичных языках даже часть букв опускалась для уменьшения трудоемкости написания или вырезания. Например, RN - "имя" на древнеегипетском. Как это слово произносилось, историки не знают - "рен", "рун" или "аран"? Не экономьте символы :)
Есть Cobol. Один из старейших языков программирования. Абсолютная читаемость (для знающих английский) абсолютная многословность, невысокая выразительность. Жив в финансовой сфере, в основном на мейнфреймах, сообщество GNU развивает целых две свободных реализации. Более высокоуровневый (но менее универсальный) язык с тем же подходом — SQL. Да, я бы ещё обратил внимание тех кому хочется смотреть в эту сторону, на lsFusion. Открытый DSL, эдакий расширенный SQL, ориентированный на «околобухгалтерию».
Есть APL, он не намного моложе кобола. Прямо противоположный подход: компактная математическая запись, специальный набор символов. Тоже живёт в финансовой сфере, только ближе к аналитическому отделу, чем к бухгалтерии. У этого языка есть несколько более или менее похожих на него потомка: J/K/BQN, имеющих свободные и/или коммерческие реализации. Эталонный коммерческий Dialog APL free for personal use и доступен для самых различных платформ, начиная с Raspberry Pi.
Но мейнстрим, все знают, языки с синтаксисом Си. Слегка выделяется python, время от времени вырывающийся на вершину рейтингов, популярен в своей нише и больше похожий на Паскаль lua (или похожая, её зовут Луна), но в целом тенденция ясна.
Четвёртый путь — и это опять один из старейших языков: lisp. Даже те кто ни разу не имел дело с одним из его диалектов, знаком с подобной формой записи благодаря XML или JSON.
Меня вы спросите, где здесь мораль, я направлю свой взгляд в туманную даль...©
...Каждый выбирает по себе...©
Сразу видно кто прогуливал уроки информатики в школе.
Считаю, что в данном вопросе следует учитывать не только восприятие "новичка" (человека, не знакомым с некоторым языком или только вошедшим в сферу) но и написание, а также частоту употребления знаков и слов.
Так, я быстро сбежала от языков бейсико и паскале подобных, именно из-за того (и других причин тоже), что кодовые блоки писались многословно - все эти 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++ победил, но не стоит их них копировать всё. При разработке языка стоит всё-таки пописать много псевдопрограмм, чтобы оценить затрачиваемые усилия как при чтении, так и при записи - и тогда решить, какой вариант записи удобнее, насколько проще написать компилятор чтобы он не путался в наших намерениях. А универсального рецепта нет - на подобные топику статьи "вы ничего не понимаете, проще вот так делать!" найдутся и сотни несогласных, которым удобнее как раз наоборот. Как и с моим комментарием также многие не согласятся - и это прекрасно, мы все разные.
Меня всегда бесил Паскаль. Не только из за бегин-ендов и всяких тупых ограничений, но и из за оператора присвоения :=
Присвоение - одна из самых частых встречающихся операций в програмировании. И вдруг - в два раза больше символов, да ѝ читаемость никак не улучшается.
Ну, а если && и || непонятны, то можете их задифайнить под and и or в конце концов. Или - писать на бейсике. :)
Обратная сторона лаконичности знаков в языках программирования