도메인 특정 언어는 언제 사용해야합니까? [닫은

https://stackoverflow.com/questions/1003241

05-07-2019
|

문제

나는 언제 도메인 특정 언어. 장점과 단점에 대한 리소스를 찾았지만 어떤 종류의 프로젝트가 그 사용을 보증 할 것인가?

DSL을 생성하고 유지하기위한 시간에 큰 투자가있는 것 같습니다. 따라서 어떤 응용 프로그램 공간에서 시간 투자에 대한 생산성 수익을 얻을 수 있습니까?

편집하다: DSL의 가장 일반적인 사용은 지속되는 데이터 상태를위한 파일 형식 인 것 같습니다. 프로그램 로직 및 구조 (아마도 코드 생성)에 DSL을 사용하는 것은 어떻습니까? 이것은 언제 가능합니까?

#2 편집 나는 주로 특정 DSL의 가치가있는시기에 대해 묻고 있습니다. 물론 시간을 절약하기 위해 기존 DSL을 가능한 한 많이 사용해야합니다.

해결책

또 다른 DSL을 만드는 데는 충분한 이유가 거의 없습니다. 세상은 특수 목적 언어로 뚱뚱합니다.

이 라인과 함께 생각하십시오.

Python, Java, C ++와 같은 일반 목적 언어로 문제를 해결하십시오.
이 솔루션을 최적화하여 일반적인 기능을 고려하고 정말 멋지고 우아하고 확장 가능한 클래스 라이브러리를 구축하십시오.
"직교성"을 강조하기 위해 해당 클래스 라이브러리를 최적화하십시오. 모든 기능이 문제없이 잘 작동하는지 확인하십시오.
구문 만 단순화 해야하는 경우 멋진 클래스 라이브러리 주변에서 스크립팅 래퍼를 만듭니다. 이것은 당신의 DSL입니다. Python의 경우, 이것은 쉽습니다. 이미 역동적 인 언어입니다. Java의 경우 활용할 수있는 것들이 있습니다. C ++의 경우이 유연한 스크립팅 환경을 구축하는 것이 약간의 작업 일 수 있습니다.
여전히 추가 최적화가 필요한 경우 DSL에 대한 컴파일러를 작성하는 것이 좋습니다.

다른 팁

ACM 컴퓨팅 설문 조사 기사 도메인 별 언어를 개발하는시기와 방법 Martin Fowler의 2010 년 책과 마찬가지로이 주제에 대한 조언을 제공합니다. 도메인 별 언어.

첫째, 나는 할 것이다 사용 DSL 귀하가 개발하는 문제 도메인이 널리 알려진 도메인이며, 해당 도메인의 일부 비즈니스 전문가는 이미 그러한 DSL을 구축하기 위해 이미 많은 노력을 기울여서 모든 것을 해결하기 위해 길이를 스스로 통과 할 필요가 없습니다. 그들이 이미 알아 낸 문제.

당신이 생각하고 있다면 창조 DSL, 귀하의 비즈니스가 매우 특정한 영역에서 이루어지고 특정 문제 영역에 집중하는 데 대부분의 시간을 보내면 그렇게하는 것을 고려할 것입니다. 여러 문제 도메인에 대한 응용 프로그램을 중심으로 바운스한다면 그 접근 방식을 취하는 것은 조언하지 않을 것입니다.

예를 들어, 귀하의 비즈니스가 세금 신청을 구축하는 데있어서 Soley 인 경우 세금 시스템 DSL을 구축하는 것이 좋습니다. 이를 통해 다양한 세금 신청에서 귀하의 언어가 유용 할 수있을뿐만 아니라 업계의 다른 비즈니스에서도 달성하는 유사한 일을하려는 비슷한 일을하려는 시장 (사용 가능)도 가능합니다.

물론, 이미 존재하는 언어 위에 DSL 대 프레임 워크를 구축하는 데 드는 비용/이점을 가중시켜야합니다.

떠오르는 상황 중 하나는 요구 사항에 매우 높거나 불가능한 수준의 사용자 정의/구성이 필요한 경우입니다.. 따라서 대신 DSL에 대한 일종의 스크립팅 모델을 제공합니다.

예를 들어 자동차 어셈블리 "ARM"을 가져 와서 다양한 공장 구성을 지원하기위한 구성 모델을 제공하는 것은 불가능합니다. (이것을 감지하고, 이런 일이 일어날 때이 일을 할 때 ... 등을 감지하지 마십시오.)

그러나 각 고객에 대한 전문 논리로 새로운 애플리케이션을 컴파일하는 것은 좋은 방법이 아닙니다. 따라서이 경우 DSL이 될 작은 프레임 워크를 만들고 판매하는 각 로봇 암에 대해 DSL에 작은 앱을 작성하고 DSL을 컴파일하고 실행하는 핵심 소프트웨어와 함께 저장합니다. 대신 스크립트. 또는 DSL을 프로그래밍하는 도구는 로봇 암과 함께 포함되므로 고객이 만든 DSL에서 팔을 "프로그램"할 수 있습니다.

떠오르는 실제 예제 중 하나는 Yahoo Pipes (DSL로 생각할 수 있음) 또는 자동화 된 웹 크롤러의 Robots.txt Directive입니다. 그들은 본격적인 DSL이 아닐 수도 있지만 DSL이 유용한 위치를 보여줍니다.

글쎄, 누군가는 그것을 말해야하므로 여기에 간다 :

LISP는 일부에 의해 도메인 별 언어로 간주됩니다. 어느 도메인. 잘지지되고 매우 확장 가능한 DSL.

경우에 따라 LISP (또는 Haskell과 같은 유사한 언어)에서 DSL을 만들어내는 것은 실제로 최소한의 노력으로 많은 힘을 제공 할 수 있으므로 가치가 있습니다. DSL이 항상 큰 유지 보수 부담 일 필요는 없습니다.

가장 분명한 것은 언어가 이미 존재하고 잘지지 될 때 분명히 사용해야한다는 것입니다. 이것의 주요 예는 모티프 기반 GUI 개발을위한 UIL이며 소프트웨어 빌드를위한 것입니다.

직접 만들어야한다면 도메인을 찾아야한다고 말하고 싶습니다. 많은 노력을 기울여야하며 컴파일러가 실제로 대부분의 오류를 찾을 수는 없지만 도메인 별 컴파일러가 할 수있는 곳에서 많은 노력을 기울입니다. GUIS는 대부분의 작업이 레이아웃을 설정하는 데있어 훌륭한 예이며, 일반적으로 기본 GUI 시스템에 맞지 않는 구문 적으로 유효한 C ++ 호출을 만드는 방법이 많이 있습니다 (예 : 전체 대화 상자를 포함하려고합니다. 버튼 내부의 위젯).

UIL 컴파일러는 C ++ 컴파일터에 대한 멋진 정상 편집 가능한 코드처럼 보이는 GUI 사양에서 오류를 찾을 수 있기 때문에 UIL은 특히 GUI 개발에 큰 이익을 얻었습니다. 그것이 잘 지원된다는 사실은 코드가 플랫폼과 GUI 빌더간에 포트가 쉽다는 것을 의미합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow