DSL(domain specific language)는 범용적인 문제에 초점을 맞추는 일반적인 프로그래밍 언어와는 다르게 특수한 문제에만 초점을 맞추는 언어다. DSL은 컴퓨터의 역사와 함께 오래도록 회자되었다.
DSL을 많이 사용하는 커뮤니티인 유닉스 커뮤니티에서는 그것을 작은 언어(little languages) 혹은 미니 언어(mini languages)로 부른다. 흔히 그것을 little 언어 또는 mini 언어라고 부릅니다. (Eric Raymond는 이러한 전통을 논한 유용한 기록을 제공한다.) 널리 통용되는 유닉스식 접근은 하나의 언어에 대한 문법을 정의하고, 목적하는 언어를 코드를 생성하거나 DSL을 위한 번역 프로그램(interpreter)를 작성한다. 유닉스는 이러한 작업을 도와주는 많은 툴을 갖고 있다. 나는 주로 이런 종류의 DSL을 External DSL이라고 지칭한다. XML 설정 파일도 하나의 External DSL이다.
Lisp과 smalltalk 커뮤니티 또한 DSL에 대한 강한 전통을 갖고 있지만 사용하는 방식에 있어서 차이가 있다. 그들은 새로운 언어를 정의하기 보다는 범용적인 목적의 언어를 DSL로 변형시킨다.(Paul Graham은 이를 Programming Bottom-Up에서 잘 설명해놓았다.) 이러한 Internal DSL(또는 embedded DSL)은 프로그래밍 언어를 그대로 활용하여 DSL을 정의한다. 이것은 어떤 언어에서도 작업할 수 있는 보편적인 방법이다. 나는 항상 접하는 문제를 DSL의 형태로 정의할 수 있는 기능에 대해 고민해왔다. 그런데 Lisp과 Smalltalk 사용자들은 훨씬 앞서 이런한 방법을 활용했다.
최근에 작성한 나의 논문, Language Workbenches가 DSL의 Killer-app 인가?에는 이들 두 가지 형태의 DSL에 대한 많은 예를 수록하고 있다. 또한, 두가지 방안에 대한 장단점을 자세하게 언급했고, DSL이 널리 보급되었으면 하는 마음에 최근 개발 된 language workbench 도구에 대해 많은 이야기를 했다.
이러한 두 가지 조류는 PragDave의 The Pragmatic Programmers, LLC의 영향력의 배경이기도 하다. The Pragmatic Programmers, LLC는 오랫동안 DSL의 팬이었다. 특히, 유닉스 진영의 전통의 영향을 따르는 훌륭한 논의가 The Pragmatic Programmer의 12절에 있다. 아마도 난 그 내용을 Pragmaticum 12이라고 말해야 할 것 같다. Dave1는 그의 사려 깊은 인터뷰2에서 코드 생성 기능을 자주 활용하지만, 루비(Ruby)를 사용할 때는 다르다고 말한다.
나는 항상 DSL을 만든다는 생각으로 설계를 해나가곤 했다. DSL로 활용할 의도로 클래스와 메소드를 만들어 가는 것이다. 내가 사용하는 언어가 허용하는 범위내에서 최대한의 시도를 했지만, 한계에 부딪히면 곧바로 코드 생성을 활용했다. ThoughtWorks에서 우리는 코드 생성을 사용해 왔고 비슷한 기술들을 우리의 커다란 시스템에서 사용해 왔다. 어떤 언어를 사용하느냐에 따라 DSL과 같은 별도의 언어에 대한 필요성도 현격하게 달라진다. Smalltalk를 사용할 때 별도의 언어를 필요로 하지 않았지만, C++/Java/C#에서는 별도의 언어가 필요한 것은 너무나도 자연스러운 일이다.
결과적으로 다른 언어에 비해 internal DSL에 적합한 언어가 존재하는 것은 자명해 보인다. Lisp과 smalltalk를 통해서 전통적인 어어에 비해 하나의 기본적인 아이디어에 충실해서 보다 간단하면서 특정 분야에 충실한 최소지향적 언어(minimalist languages)가 internal DSL에 적합하다고 결론을 지었다. (function application을 위한 Lisp과 객체와 메시지에 특화된 Smailltalk) 그러나, 루비는 보다 프로그래머사이의 관습을 선호하며, Lisp이나 Smalltalk과는 달리 방대한 (기능과 API를 가진) 언어이지만, internal DSL에 적합하다.
그래서 아마도 internal DSL이 필요로 하는 것은 적절한 선택에서 비롯한 간명함이라고 생각된다. 널리 쓰이는 것들을 쉽게 사용할 수 있게 해주고, 복잡함을 최대한 해소한 멋진 문법을 제공해야 한다. 그것이 어떤 언어든 이러한 간명함을 갖는 것은 매우 중요한다. 나는 종종 java나 c#보다 Smalltalk이나 루비로 프로그래밍을 즐기는 이유를 글로 표현하는 것이 어려움을 알게 된다. 주로 그 이유로 정적인 타입 정의와 동적인 타입 정의를 언급했지만, 그때마다 나는 핵심을 놓치고 있음을 느꼈다. 아마도 Internal DSL에 대한 친밀함이 그 핵심에 더욱 가까울 것이다.
원문: DomainSpecificLanguage
번역: 영회, 백기선
DSL을 많이 사용하는 커뮤니티인 유닉스 커뮤니티에서는 그것을 작은 언어(little languages) 혹은 미니 언어(mini languages)로 부른다. 흔히 그것을 little 언어 또는 mini 언어라고 부릅니다. (Eric Raymond는 이러한 전통을 논한 유용한 기록을 제공한다.) 널리 통용되는 유닉스식 접근은 하나의 언어에 대한 문법을 정의하고, 목적하는 언어를 코드를 생성하거나 DSL을 위한 번역 프로그램(interpreter)를 작성한다. 유닉스는 이러한 작업을 도와주는 많은 툴을 갖고 있다. 나는 주로 이런 종류의 DSL을 External DSL이라고 지칭한다. XML 설정 파일도 하나의 External DSL이다.
Lisp과 smalltalk 커뮤니티 또한 DSL에 대한 강한 전통을 갖고 있지만 사용하는 방식에 있어서 차이가 있다. 그들은 새로운 언어를 정의하기 보다는 범용적인 목적의 언어를 DSL로 변형시킨다.(Paul Graham은 이를 Programming Bottom-Up에서 잘 설명해놓았다.) 이러한 Internal DSL(또는 embedded DSL)은 프로그래밍 언어를 그대로 활용하여 DSL을 정의한다. 이것은 어떤 언어에서도 작업할 수 있는 보편적인 방법이다. 나는 항상 접하는 문제를 DSL의 형태로 정의할 수 있는 기능에 대해 고민해왔다. 그런데 Lisp과 Smalltalk 사용자들은 훨씬 앞서 이런한 방법을 활용했다.
최근에 작성한 나의 논문, Language Workbenches가 DSL의 Killer-app 인가?에는 이들 두 가지 형태의 DSL에 대한 많은 예를 수록하고 있다. 또한, 두가지 방안에 대한 장단점을 자세하게 언급했고, DSL이 널리 보급되었으면 하는 마음에 최근 개발 된 language workbench 도구에 대해 많은 이야기를 했다.
이러한 두 가지 조류는 PragDave의 The Pragmatic Programmers, LLC의 영향력의 배경이기도 하다. The Pragmatic Programmers, LLC는 오랫동안 DSL의 팬이었다. 특히, 유닉스 진영의 전통의 영향을 따르는 훌륭한 논의가 The Pragmatic Programmer의 12절에 있다. 아마도 난 그 내용을 Pragmaticum 12이라고 말해야 할 것 같다. Dave1는 그의 사려 깊은 인터뷰2에서 코드 생성 기능을 자주 활용하지만, 루비(Ruby)를 사용할 때는 다르다고 말한다.
나는 항상 DSL을 만든다는 생각으로 설계를 해나가곤 했다. DSL로 활용할 의도로 클래스와 메소드를 만들어 가는 것이다. 내가 사용하는 언어가 허용하는 범위내에서 최대한의 시도를 했지만, 한계에 부딪히면 곧바로 코드 생성을 활용했다. ThoughtWorks에서 우리는 코드 생성을 사용해 왔고 비슷한 기술들을 우리의 커다란 시스템에서 사용해 왔다. 어떤 언어를 사용하느냐에 따라 DSL과 같은 별도의 언어에 대한 필요성도 현격하게 달라진다. Smalltalk를 사용할 때 별도의 언어를 필요로 하지 않았지만, C++/Java/C#에서는 별도의 언어가 필요한 것은 너무나도 자연스러운 일이다.
결과적으로 다른 언어에 비해 internal DSL에 적합한 언어가 존재하는 것은 자명해 보인다. Lisp과 smalltalk를 통해서 전통적인 어어에 비해 하나의 기본적인 아이디어에 충실해서 보다 간단하면서 특정 분야에 충실한 최소지향적 언어(minimalist languages)가 internal DSL에 적합하다고 결론을 지었다. (function application을 위한 Lisp과 객체와 메시지에 특화된 Smailltalk) 그러나, 루비는 보다 프로그래머사이의 관습을 선호하며, Lisp이나 Smalltalk과는 달리 방대한 (기능과 API를 가진) 언어이지만, internal DSL에 적합하다.
그래서 아마도 internal DSL이 필요로 하는 것은 적절한 선택에서 비롯한 간명함이라고 생각된다. 널리 쓰이는 것들을 쉽게 사용할 수 있게 해주고, 복잡함을 최대한 해소한 멋진 문법을 제공해야 한다. 그것이 어떤 언어든 이러한 간명함을 갖는 것은 매우 중요한다. 나는 종종 java나 c#보다 Smalltalk이나 루비로 프로그래밍을 즐기는 이유를 글로 표현하는 것이 어려움을 알게 된다. 주로 그 이유로 정적인 타입 정의와 동적인 타입 정의를 언급했지만, 그때마다 나는 핵심을 놓치고 있음을 느꼈다. 아마도 Internal DSL에 대한 친밀함이 그 핵심에 더욱 가까울 것이다.
원문: DomainSpecificLanguage
번역: 영회, 백기선
- Dave Thomas, The Pragmatic Programmer의 공동 저자이면서 The Pragmatic Programmers, LLC를 대표하는 인물인 듯 합니다. 아마 PragDave는 그의 블로그인 것 같은데, Martin Fowler가 원문의 PragDave에 걸어둔 링크는 http://pragprog.com/pragdave였는데 현재는 http://pragmaticprogrammer.com/으로 포워딩 되고 있습니다. [본문으로]
- 현재 링크가 깨져 있다. [본문으로]





이올린에 북마크하기
이올린에 추천하기

