ищу научные доказательства преимуществ использования DSL
https://stackoverflow.com/questions/1625608
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Лекция Грега Уилсона «Куски доказательств» ( http://www.slideshare.net/gvwilson/bits-of-evidence -2338367 ) обсуждает отсутствие доказательств в пользу следующих утверждений, выдвинутых Мартином Фаулером в качестве преимущества использования DSL:
" [использование языка, отдельного от домена], приводит к двум основным преимуществам. Первый и самый простой - это повышение производительности труда программиста. Второй ... это ... общение с экспертами в области. & Quot; - Мартин Фаулер в IEEE Software, июль / август 2009 г.
Вопрос. Существуют ли какие-либо эмпирические исследования, свидетельствующие либо об улучшении производительности программистов, либо об улучшении связи с экспертами в области использования DSL?
Многие люди, создающие DSL, не могут дать обоснованный ответ на вопрос "почему вы создаете DSL?" и "почему DSL поможет вам больше, чем хорошо продуманная объектная модель?"
Я много слышу "Я делаю это, потому что это круто, и все остальные делают это" - который не является рациональным ответом.
Я считаю, что DSL полезны, по крайней мере, в некоторых случаях, но вряд ли они будут "серебряной пулей" это должно использоваться без разбора. Я хотел бы увидеть некоторые научные работы, которые описывают, когда DSL должны и не должны использоваться - на основе эмпирических исследований.
Решение
Просто погуглив, я нашел пару интересных статей:
Практически определенные доменные языки: Исследование пользователя о факторах успеха
Другие советы
Это зависит от того, что вы считаете DSL.
Например, является ли css DSL? Я бы так подумал, тогда, очевидно, это может облегчить стилизацию страницы, так как в HTML 3 мы использовали таблицы для аранжировок и не имели такой гибкости, как сейчас.
Если у вас есть DSL, чтобы учащиеся могли создавать молекулы, используя только атомарные символы (H20), тогда это было бы проще, чем выполнять кодирование самостоятельно, поскольку вы можете быстро посмотреть на молекулярную конфигурацию, если вы дадите символы и типы склеивание, например.
Я не знаю бумаги, показывающей так или иначе, но, если ваша целевая аудитория не программисты, то DSL имеет смысл, поэтому мы можем предложить бухгалтерам писать их приложения, используя их терминологию, а не иметь их предъявлять требования к разработчикам.
DSL существуют уже давно, но в настоящее время становятся все более популярными, поэтому время покажет, когда появятся новые примеры хороших и плохих применений: когда лучше использовать и когда это на самом деле вредно. Например, я бы не стал писать программное обеспечение для медицинского мониторинга на DSL.
Вся предпосылка "научного" в этом случае сомнительно. Просто не существует способа гарантировать критерии «воспроизводимый», «контрольный (групповой)». требуется для эмпирического исследования.
В целом, в бизнес-программировании нет серьезных эмпирических исследований преимуществ чего-либо до его использования. Будь то SQL, объектно-ориентированные языки, функциональные языки, сборка мусора и т. Д.
Эти вещи, как правило, решаются рынком с течением времени.
Почему это так, вероятно, является комбинацией двух причин. Во-первых, получить хорошее эмпирическое исследование очень дорого, а с экономической точки зрения гораздо дешевле просто попробовать его. Другая заключается в том, что каждая ситуация отличается, поэтому эмпирическое исследование должно начинаться с ограничения узкой проблемы очень узко, чтобы иметь правильное сравнение между использованием DSL и не использованием, и конечный результат исследования не будет очень полезно за пределами конкретного типа проблемы, которая была выбрана.
Я думаю, что мы можем смело сказать из опыта, что ничто не является «серебряной пулей», и настаивание на веской причине для подхода улучшит любое решение, потому что даже если DSL поможет ситуации, если вы не знаете, почему вы делаете это, вы не будете знать, делаете ли вы это правильно, и можете в конечном итоге пропустить всю выгоду.
Это разумный вопрос, и я думаю, что есть проблемы с определениями, такие как «что такое DSL»? Когда модное слово становится «горячим» это становится возможностью для маркетинга и отрывается от основной науки, если таковая имеется.
Несколько лет назад я написал книгу («Построение лучших приложений», ISBN 0-442-01740-5, давно вышедшую из печати), в которой я попытался оценить производительность не только программ, но и программистов. Я пытался взглянуть на это, используя теорию информации.
Я придумал грубую меру ремонтопригодности, где проблема существует в виде структуры знаний в чьей-то голове (нет проблем для искусственного интеллекта), и ее решение существует в виде текстовой структуры, обрабатываемой машиной. Я смотрю на отношения между этими двумя структурами. Например, если в описании умственной проблемы произошли изменения, сколько изменений в исходном коде потребуется, чтобы правильно перенести это в текст программы? Простой способ измерить это состоит в том, чтобы сравнить код до и после. Теперь среднее значение, измеряемое в пространстве вероятных изменений, и чем ниже среднее, тем более понятен исходный код.
Мой тезис состоял в том, что чем больше поддерживаемого кода, тем больше он напоминает ментальную модель предметной области, поэтому разумно назвать его «проблемно-ориентированным». или более «специфичный для домена». Одна из особенностей такого кода, который я заметил, заключается в том, что он скорее является оператором проблемы, нежели решением проблемы. Решение заключается не в языке, а в реализации языка, его подструктуры. Это эхо, хотя и не прямое согласие, с понятием «декларативный» против "императив" язык.
Поэтому, пытаясь ответить на ваш вопрос, я бы сказал, давайте отойдем от того, что люди могут захотеть " DSL " иметь в виду и вместо этого посмотреть на определение, которое по крайней мере умеренно однозначно.
В рамках разработки этой идеи я наткнулся на несколько методов, одним из которых является Дифференциальное выполнение , которое, по-видимому, обеспечивает хорошую ремонтопригодность для кодирования пользовательского интерфейса, а также уменьшает размер исходного кода примерно на порядок. Моя теория заключается в том, что это успешный пример того, каким может быть DSL.
Я не утверждаю, что ремонтопригодность может быть достигнута, если сопровождающему не придется подниматься по кривой обучения. Я думаю, что реальная ремонтопригодность достигается за счет того, что программистам приходится изучать вещи, которые могут быть непростыми для понимания, но однажды понятые имеют желаемое значение.
От лингвистов Saphir и Worf мы можем узнать, что грамматические особенности языка влияют на наше мышление = если вы создадите DSL, вы будете думать более предметно-ориентированным и, вероятно, менее универсально. Все дело в абстракции, так же как языки программирования общего назначения стремятся абстрагироваться от машины, поэтому мы можем сосредоточиться больше на алгоритмах, структурах и дизайне, чем на наборе команд, режимах адресации, размерах регистров и т. Д.
Не уверен, что кто-либо провел какие-либо исследования в той степени, в которой вы нуждаетесь. Однако мой опыт заключается в том, что создание DSL может быть в первую очередь дорогостоящим (возможно, в 2 раза или больше, чем в более простой объектной модели, чтобы сделать то же самое). Однако после создания разработчики получат немедленную выгоду, если смогут быстрее справляться с DSL, чем с моделью.
Проблема в том, что он рассматривает все DSL как равные. Некоторые из них было бы проще реализовать, другие сложнее - если кто-то использует Fluent Interfaces / Внутренние DSL или внешние DSL, это приведет к разным временам / затратам на реализацию.
Одним из основных преимуществ, которые могут не охватываться такими исследованиями, является легкость, с которой DSL может привести к выражению и реализации кода. Это также может помочь другим понять смысл кода, возможно, проще - и поскольку фаза обслуживания жизненного цикла разработки программного обеспечения является таким большим компонентом SDLC, это может привести к гораздо большим преимуществам (в долгосрочной перспективе), чем изначально потеряно при создании DSL. .
