ищу научные доказательства преимуществ использования DSL - PullRequest
3 голосов
/ 26 октября 2009

В выступлении Грега Уилсона «Куски доказательств» (http://www.slideshare.net/gvwilson/bits-of-evidence-2338367) обсуждается отсутствие доказательств, лежащих в основе следующих утверждений, которые выдвинул Мартин Фаулер в качестве преимуществ использования DSL:

«[использование языка, специфичного для домена] приводит к двум основным преимуществам. Первое и самое простое - это повышение производительности труда программиста. Второе ... это… общение с экспертами в области». - Мартин Фаулер в IEEE Software июль / август 2009

Вопрос: Существуют ли какие-либо эмпирические исследования, свидетельствующие либо об улучшении производительности программистов, либо об улучшении связи с экспертами в предметной области благодаря использованию DSL?

Многие люди, создающие DSL, не могут дать обоснованный ответ на вопрос «почему вы создаете DSL?» и «почему DSL поможет вам больше, чем хорошо продуманная объектная модель?»

Я много слышу: «Я делаю это, потому что это круто, и все остальные делают это» - что не является рациональным ответом.

Я считаю, что DSL полезны, по крайней мере, в некоторых случаях, но вряд ли они будут «серебряной пулей», которую следует использовать без разбора. Я хотел бы увидеть некоторые научные работы, которые описывают, когда DSL должны и не должны использоваться - на основе эмпирических исследований.

Ответы [ 7 ]

2 голосов
/ 26 октября 2009

Это зависит от того, что вы считаете DSL.

Например, является ли css DSL? Я бы так подумал, тогда, очевидно, это может облегчить стилизацию страницы, так как в HTML 3 мы использовали таблицы для аранжировок, и у нас не было такой гибкости, как сейчас.

Если у вас есть DSL, чтобы учащиеся могли создавать молекулы, используя только атомарные символы (H20), тогда это было бы проще, чем выполнять кодирование самостоятельно, поскольку вы можете быстро посмотреть на молекулярную конфигурацию, если вы дадите символы и типы склеивание, например.

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

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

1 голос
/ 10 января 2010

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

1 голос
/ 03 декабря 2009

Это разумный вопрос, и я думаю, что есть проблемы с определениями, такие как «что такое DSL»? Когда модное слово становится «горячим», оно становится маркетинговой возможностью и отрывается от основополагающей науки, если таковая имеется.

Несколько лет назад я написал книгу (Building Better Applications, ISBN 0-442-01740-5, давно вышедшую из печати), в которой я пытался взглянуть на производительность не только программ, но и программистов. Я пытался взглянуть на это, используя теорию информации.

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

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

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

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

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

1 голос
/ 26 октября 2009

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

Эти вещи, как правило, решаются рынком с течением времени.

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

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

1 голос
/ 26 октября 2009

Вся предпосылка "научного" в этом случае сомнительна. Просто нет способа гарантировать критерии «воспроизводимый», «контроль (группа)», необходимые для эмпирического исследования.

0 голосов
/ 26 октября 2009

Не уверен, что кто-либо провел какие-либо исследования в той степени, в которой вы нуждаетесь. Однако мой опыт заключается в том, что создание DSL может быть в первую очередь дорогостоящим (возможно, в 2 раза или больше, чем в более простой объектной модели, чтобы сделать то же самое). Однако после создания разработчики получат немедленную выгоду, если смогут быстрее справляться с DSL, чем с моделью.

Проблема с вопросом заключается в том, что он рассматривает все DSL как равные. Некоторые из них проще реализовать, другие сложнее - если кто-то использует Fluent Interfaces / Внутренние DSL или внешние DSL, это приведет к разным временам / затратам на реализацию.

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

...