Дариус Бласбанд

Когда дело доходит до внедрения предметно-ориентированных языков (DSL) промышленного уровня, спешка с предоставлением чего-либо как можно раньше может оказаться крайне контрпродуктивной.

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

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

На самом деле, сосредоточение внимания на этих ранних разработках может полностью поставить проект под угрозу, ставя под угрозу его долгосрочную жизнеспособность.

Вы думаете, что я преувеличиваю в отчаянной попытке сделать слабый аргумент? Читайте дальше, потому что речь идет не только о жестоком влиянии времени. Речь идет о множестве интересных технологий, доступных для разработки текстовых и графических DSL за считанные часы.

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

И сдуться они должны быть.

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

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

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

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

Решение этой проблемы удивительно простое:

Не используйте эти причудливые инструменты для чего-то большего, чем прототипирование.

Используйте их для ранней и быстрой демонстрации, если необходимо, но откатитесь назад и выберите более консервативные, менее продуктивные, но более перспективные методы реализации.

Сюда входят даже такие простые вещи, как генераторы синтаксических анализаторов.

Не поймите меня неправильно, Yacc, ANTLR и тому подобное великолепны (и вы не ожидаете, что такой компилятор, как я, скажет обратное), но их добавленная ценность ограничена, особенно при работе с языком, который вы разрабатываете сами, где упрощение синтаксического анализа — одна из наиболее разумных целей проектирования, которые вы можете преследовать. Их добавленная стоимость ограничена, и использование генератора синтаксических анализаторов создает еще одну проблему для вашего проекта.

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

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

Это позволяет вам обновлять и переделывать его графическое представление, а не тогда, когда технологии развиваются и ваша среда DSL устаревает.

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

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

Первоначально опубликовано на https://www.raincodelabs.com 12 ноября 2018 г..