История изменений

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

Сейчас попробую сформулировать мысль, тут будет небольшой подход.

Изначально в высшем мире абстракций программа это алгоритм. Это некое семантическое множество. Семантика, это те действия, которые мы делаем над данными, выраженные в абстрактном виде.

Синтаксис это уже то, что потребляет компилятор. Это низшее звено, по сути последовательности ASCII символов, минус незначащие проблемы, комментарии и тд. Т.е. последовательность лексем.

Чем ниже уровнем язык, тем больше лексем нужно, чтобы выразить ту же семантику. На языке ассемблера может потребоваться три строки по три лексемы для того, чтобы прибавить к одному числу второе. На любом высокоуровневом языке это будет одна строка вида a += b.

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

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

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

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

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

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

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

Сейчас попробую сформулировать мысль, тут будет небольшой подход.

Изначально в высшем мире абстракций программа это алгоритм. Это некое семантическое множество. Семантика, это те действия, которые мы делаем над данными, выраженные в абстрактном виде.

Синтаксис это уже то, что потребляет компилятор. Это низшее звено, по сути последовательности ASCII символов, минус незначащие проблемы, комментарии и тд. Т.е. последовательность лексем.

Чем ниже уровнем язык, тем больше лексем нужно, чтобы выразить ту же семантику. На языке ассемблера может потребоваться три строки по три лексемы для того, чтобы прибавить к одному числу второе. На любом высокоуровневом языке это будет одна строка вида a += b.

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

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

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

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

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

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