Снимаю шляпу перед Александром Купреевым, автором статьи "Мысли о человеческом общении. С программами..." ("КВ"-15/2004) - проблема недостаточности одного лишь графического интерфейса для решения сложных задач поставлена великолепно, и с выводом о необходимости встраивания в приложения символических языков я тоже категорически согласен.

Однако, есть у меня и возражения, в том числе и по существу вопроса.

Во-первых, Форт - далеко не лучший вариант встроенного языка скриптования, хотя бы из-за отсутствия адекватных средств работы со строками и высокоуровневыми структурами данных, что для современных скриптовых языков является нормой. Не говоря уже о его совершенно неочевидной нотации - говорю это как человек, который на нем писал и который видел, как его воспринимают неподготовленные люди (в лучшем случае - с трудом).

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

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

Одного примера уже упомянутого Форта, висящего ровно посередине между интерпретируемыми и компилируемыми языками, должно быть достаточно, чтобы понять тщетность какой-либо классификации языков программирования. А ведь есть еще Java, компилируемая в интерпретируемый код, и есть компилятор GCJ, компилирующий ее прямо в машинный код. Есть совершенно не скриптовый язык Lisp и похожий на него как две капли воды скриптовый язык Scheme. Есть и скриптовый язык Ruby, отлично подходящий для построения больших приложений лучше, чем многие языки высокого уровня.

Наконец, мысль о том, что любое графическое приложение по мере достижения определенного уровня сложности не может обойтись без встроенного языка написания скриптов, тоже совершенно не нова. Отсюда и злополучный Бейсик в Microsoft Office, и AutoLisp в AutoCAD, и JavaScript в Mozilla, и т.п. Существует даже целый ряд языков, специально разработанных именно для встраивания в приложения - TCL, Scheme, Lua, и еще не помню какие. Кстати, есть и интерпретатор Форта FICL, тоже метящий именно в эту нишу.

Не стоит отмахиваться от всего этого разнообразия возможностей под предлогом сложности освоения - после восьмого-девятого языка программирования все они уже кажутся одинаковыми. В соответствии с заветами все того же наследия Unix к каждой задаче нужно подбирать инструмент, лучше всего подходящий для ее решения. Для целей оптического моделирования, пожалуй, лучше всего подойдет Lisp-подобный Scheme (хотя при любви к Форту можно попробовать и FICL), а вот для бухгалтерских программ я бы предпочел использовать объектный Ruby, который лучше подходит для разработки бизнес-приложений и поддерживает OLE32.

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

Дмитрий БОРОДАЕНКО