[prog.flame] Затрону таки тему Nemerle

RSDN-овские флеймы про Nemerle, как и советские газеты, я уже давно не читаю. Но после анонса релиза версии 1.0 на LOR-е время от времени просматриваю LOR-овское обсуждение. И вот на чем я себя ловлю: за все время, пока Nemerle мозолит мне глаза, я не встречал ни одного вменяемого объяснения преимуществ управления синтаксисом языка для прикладного программирования.

Главная фишка Nemerle, которую ставят во главу угла его евангелисты, – это синтаксические макросы. По сути, ядро языка очень минималистично. В нем нет даже таких привычных вещей, как if-ы и for-ы. Все это строится за счет синтаксических макросов, которые доступны не только разработчикам языка, но и пользователям. Любой прикладной программист может наваять свой собственный синтаксис для свой специфической задачи. Фактически, главное достоинство языка – это простое создание встраиваемых Domain Specific Languages (internal DSL-ей) для конкретных прикладных областей.

Ссылки по теме: #1, #2, #3.

Когда синтаксические макросы используются для формирования самого языка (if-ы) или его стандартной библиотеки (Regexp, LINQ и пр.), то это проблемы разработчиков языка и библиотек. Прикладных программистов это не касается. AFAIK, изрядное количество машинных команд IBM 360 реализовывались на самом деле не в процессоре, а через т.н. микрокод – набором совсем уж низкоуровневых команд процессора. И эта механика прикладных разработчиков нисколько не заботила.

Зато когда макросы начинают использоваться прикладными программистами, тут правила уже иные. Во всех спорах вокруг Nemerle всплывает один и тот же вопрос: ну и что делать, если Вася Пупкин придумал супер-пупер DSL, написал на нем туеву хучу кода, а затем свалил, а на проект пришел Ваня Сидоров? Что делать Ване Сидорову с этим DSL-ем, как с ним разбираться, как его сопровождать?

И вот на этот вопрос у Nemerle-истов я не видел вменяемых ответов. Стандартная отмазка – а когда Вася Пупкин оставляет после себя туеву хучу классов с методами – это разве не DSL? Разве с этим не приходится разбираться?

Гнилая отмазка. Практика показывает, что с туевой хучей процедур, функций, классов, методов, модулей, пакетов и пр. сущностей удается справляться. Не без труда, но удается. Уже лет 50 как. Уже собран изрядный опыт, созданы специальные инструменты – те же продвинутые IDE с инспекцией кода. Подавляющее большинство работающего вокруг нас ПО разработано именно так.

Как дело пойдет, если прикладные задачи начнут решаться посредством комбинирования DSL-ей – вот это terra incognita. В истории разработки ПО соответствующих крупномасштабных экспериментов было всего нечего. Самый большой – это Lisp. Который уже давным-давно не мейнстрим и серьезного влияния на мейнстрим не оказывает. Т.е. процент разрабатываемого на Lisp-е ПО находится где-то в рамках статистической погрешности ;) Но как раз на примере Lisp-а можно видеть, что DSL-естроение черевато. Интересующихся адресую к Social Problems of Lisp ;)

Было время, когда я увлекался мелкими DSL-ями – это были интересные эксперименты, но не более того. Хотя даже исходя из своего скромного опыта могу указать одно важное преимущество кучи классов/методов перед DSL-ями: чужое API (на важно, объектное или процедурное) не сложно инкапсулировать в свое собственное API. А вот с DSL-ями так не получится.

Т.е., если у нас есть “чужой и корявый” API для какой-то прикладной области, то мы можем построить вокруг него свой “правильный и красивый” фасад. Взять, например, библиотеку libcurl. Да, она работает, да в ней все уже давно сделано. Но пользоваться ей – убиться веником :) Однако, всего несколько простеньких утилитных классов превращают это неблагодарное занятие во вполне себе нормальное и не лишенное некоторой приятности ;) В случае с API такой фокус прокатывает. А вот в случае, если бы libcurl была представлена как расширение синтаксиса?