Эрик Реймонд - Искусство программирования для Unix

Одной чрезвычайно прагматичной причиной, по которой следует продолжать усердно работать со структурированными данными, а не с мини-языком, является то, что в сетевом мире средства встроенного мини-языка являются предметом неправильного использования, которое может причинять беспокойство или даже быть опасным. JavaScript — главный экземпляр в категории "причиняющих беспокойство". Разработчики данного языка не предвидели того, что он будет использоваться для всплывающей рекламы настолько навязчиво, что создаст потребность в функциях браузера, подавляющих интерпретацию JavaScript.

Макровирусы Microsoft Word показывают, как мини-язык может стать действительно опасной брешью в безопасности системы, простои и потери производительности от которой ежегодно обходятся в миллиарды долларов. Полезно отметить, что несмотря на существование в мире как минимум 20 млн. пользователей [91] 16 20 миллионов — сдержанная оценка, основанная на графиках Linux Counter и других источниках по состоянию на середину 2003 года. Unix, в Unix-среде никогда не было вспышек макровирусов, характерных для Windows. Существует множество причин этому, включая принципиально лучшую с точки зрения безопасности конструкцию Unix; но по крайней мере одной причиной является тот факт, что почтовые агенты в Unix по умолчанию не обрабатывают исполняемое содержимое в документах, просматриваемых пользователем [92] 17 Программа Kmail , которая рассматривалась в главе 6, по этой причине даже не отслеживает внешние ссылки в HTML-документах. .

Если существует какая-либо возможность того, что пользователи приложения могут запускать программы из неблагонадежных источников, рискованные функции мини-языка приложения могут в конце концов привести к необходимости его подавления. Языки, подобные Java и JavaScript, явно изолируются в "песочнице", т.е. они имеют ограниченный доступ к своему окружению. Это сделано не только для того, чтобы упростить их конструкцию, но и для того, чтобы воспрепятствовать потенциально деструктивным операциям со стороны ошибочного или злонамеренного кода.

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

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

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

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

Для разработчика языка хорошим принципом является рассмотрение альтернативы сообщениям об ошибке. Если в намерениях программиста существует действительная неоднозначность, то сообщение об ошибке целесообразно, однако во многих случаях намерения очевидны, и будет великим благом заставить язык просто выполнять правильные действия. Хорошим примером является С, принимающий дополнительную запятую в конце списка инициализатора массива, что значительно упрощает как редактирование, так и машинную генерацию инициализаторов массива. Контрпримером является придирчивость различных HTML-анализаторов, особенно их обыкновение бесшумно отбрасывать части документа из-за тривиальной ошибки верстки.