Язык предметной области и сложность разработки Программного Обеспечения

Любой язык программирования - набор строительных блоков из которых строится язык предметной области. Иногда благодаря удачному стечению обстоятельств язык программирования практически совпадает с предметной областью, примеры MATLAB/мат.моделирование, C/системное программирование, и т. д.

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

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

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

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

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

Оппоненты много-языковых систем апеллируют к мнимой сложности, но забывают, что если только кто-то не создал ранее язык полностью и кратко описывающий предметную область, то либо на этом самом языке уже написана программа, которую мы хотим разрабатывать, либо что-то упущено в формулировке требований к программе. В конечном счете для разработчика на Python неважно - писать ли функцию RunJava(...), запускающую .jar файл с текущей виртуальной машиной Java на языке Python, или запустить скрипт Ant, где такая функция уже есть. В любом случае это будут инородные для языка Python элементы - новые термины "Языка предметной области", и сложность, то самое Big-O обоих подходов будет эквивалентна.

Таким образом реальная сложность разработки ПО таится не в том, что в системе много компонентов, а в том, что предметная область описывается большим количеством "слов" и "лексем". Все разработчики настольных приложений сталкивались с тем, что нужно рано или поздно готовить инсталлятор. Изучать систему упаковки всех ресурсов в какой-нибудь .msi, или .jar файл. Продумывать как будут регистрироваться обновления - не будет ли конфликтов на машине пользователя. Все это исчезло с появлением веб-приложений. И что же - упростился язык? Меньше стало компонентов? Да нет, просто термины "дистрибутив" и "установка на компьютер пользователя" ушли из языка предметной области разработчиков таких программ. А что до языков - да какая разница на каких кто языках разрабатывает, если соблюдаются стандарты обмена информацией.