Программирование с помощью языка, а не на языке

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

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

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

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

К чему приводит несоответствие между языком мышления и языком инструментария?

1. Дополнительный расход времени, необходимый на запись и на чтения кода.
2. Дополнительные ошибки, неизбежно возникающие в этом процессе. Нередки ситуации, когда программист лишь приблизительно понимает, что именно он пишет, и поэтому вынужден буквально исследовать свой же код. И дополнительный код, который нужно создать для поддержки сторонних понятий, также будет содержать дополнительные ошибки.
3. Отсутствие контроля над ошибками со стороны инструментов, так как они не содержат предохранителей языка, находящегося в голове программиста.
4. Необходимость "борьбы" с языком в местах, которые целевой язык ограничивает в противоположность задумке. Поэтому сторонники кодирования с помощью языка, а не на языке могут предпочесть более свободные языки, которые дают мало ограничений, и поэтому же мало чего проверяют, тем самым ослабляя и без того недостающий контроль над ошибками.
5. Избыточное комментирование, которое становится необходимым, так как целевой язык сам по себе не выражает всех исходных посылов.
6. Частое отсутствие синхронизации между программистами по общим терминам и понятиям, препятствующее обмену.
7. Бывает и такое, что исходный язык программиста ничем не лучше, если не хуже инструментального. Поэтому может статься, что все жертвы на которые нужно было пойти, были лишь для того, чтобы покормить привычки и художественное видение программиста.
8. Рано или поздно язык кодирования проникнет в язык мышления, и будет существенно влиять на принятие решений, возможно, что даже после того, как неудобоваримый язык будет устранён.

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

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