원문: EagerReadDerivation

원문: EarlyPain

comment: 무척 공감이 가는 글입니다. 아래 글도 함께 보시면 좋을 듯 합니다.

• 프로젝트 초반에 이슈화하기
• 혼란스런 프로젝트 초기에서 컨설턴트의 임무
• 반복의 중요성을 반복해서 거론하다
• 애자일 선언 in Practice

박성철님께서 블로그에 번역하셨네요. :)


원본 글은 http://martinfowler.com/articles/dblogic.html

롤러스케이트 구현

테스트 암 Test Cancer

Continuous Integration

리팩터링 정의

선언된 순서를 변경하는 것은 리팩터링인가?

발견하지 못한 버그를 수정하는 것은 리팩터링인가?

성능 최적화가 리팩터링인가?

A RefactoringBoundary.

코드 일부에 대해 인터페이스 변경이 가해지면 리팩터링으로 볼 수 있나요?

대답은 간단하다. 인터페이스 변경은 인터페이스를 호출하는 모든 코드에 변경이 요구되는 유형의 리팩터링의 일종이다. 이러한 리팩터링으로 대표적인 사례는 메소드 이름 변경(Rename Method)이다. 이름 변경은 거의 모든 리팩터링 도구에서 지원한다.

이러한 유형의 리팩터링에서는 반드시 호출하는 부분 빠짐없이 변경되어야 한다. 인터페이스 선언만 변경되고 호출하는 부분에서는 인터페이스 이름을 변경되지 않으면 시스템은 깨지고 결과적으로 행위가 변하고 만다.(역자주: 리팩터링은 시스템의 행위는 보존해야 한다.)

인터페이스 변경 리팩터링은 호출하는 모든 코드에 적용되는 것은 전제로 한다. 이는 Published Interface에 대해서는 더 노력을 기울여야 하는 이유이기도 하다. 인터페이스가 외부에 공개된 상황이라면, 인터페이스 자체가 시스템 행위의 일부로 인식되기 때문이다.

동적인 언어에 대해 이러한 변경을 다루는 것은 더욱 어렵다. 정적 타입 정의를 활용하면 다양한 지점에서 호출되는 인터페이스에 대해 명확하게 규명할 수 있다. 리플렉션(Reflection)을 사용하여 메소드 호출을 하는 경우라면, 메소드 이름이 문자열에 포함되어 있거나, 실행시점에서 구성되기 때문에 리팩터링 도구가 있다고 해도 인터페이스 변경 리팩터링이 쉽지 않다. 그래서 이러한 영역은 필수적으로 테스트가 요구되는 영역이다.  

출처: IsChangingInterfacesRefactoring

몇년전 나는 eBay에서 일하고 있는 친구들과 이야기를 나눈 일이 있다. 수많은 사용자가 이용하는 사이트에서 사용하는 기법을 듣는 것은 항상 흥미롭다. 그러나, 그중에서도 가장 흥미로왔던 것은 eBay는 거의 데이터베이스 트랜젝션(transactions)을 사용하지 않는다는 사실이다.

대부분은 사람들에게 트랜젝션이 없는 환경은 무척 놀라운 일이다. 데이터베이스를 사용한다면 트랜젝션을 쓰는 것은 너무나도 보편적인 일이다. 나를 포함한 많은 사람들은 트랜젝션을 데이터베이스가 주는 핵심적인 이점으로 여긴다.

eBay의 대규모 사용자 환경에서 성능 저하를 야기한다는 점이 트랜젝션을 쓰지 않는 이유다. eBay는 데이터를 다수의 데이터베이스에 물리적으로 나누어 놓았기 때문에 트랜젝션이 가져오는 성능 저하는 더 심각해진다. 결과적으로 트랜젝션을 사용한다는 것은 분산 트랜젝션을 의미하기 때문이다.  

고도의 파티셔닝(partitioning)과 성능 이슈에 있어서 데이터베이스가 차지하는 지배적인 비중으로 인해 eBay는 다른 많은 데이터베이스 기능들도 사용하지 않는다. 참조 무결성(Referential integrity) 보장이나 정렬은 애플리케이션 코드에서 수행한다. 트리거(triggers)나 저장 프로시저(stored procedures)를 쓰는 일은 거의 없다.

트랜젝션이 없는 환경에 대한 이야기를 처음 들었을 때, 나는 애플리케이션 개발자에게 미치는 결과 특히 트랜젝션이 없다는 것에 대해 전반적으로 어떻게 느끼는가를 물어보았다. 대답하기를 처음에는 어색했지만, 생각보다 별 문제 없이 마칠 수 있었다고 한다. 데이터베이스에 커밋(commit)하는 순서에 유의해야 하고, 중요한 것을 먼저 커밋해야 할 뿐이다. 각각의 커밋시점에서 성공 여부를 확인하고, 실패했을 때는 어떻게 할 것인지를 결정해야 한다.

이러한 프로그래밍 스타일은 내 호기심을 자극했지만 이에 대해 거론하는 것을 조심해왔다. Dan Pritchett가 이번주에 QCon에서 eBay의 아키텍처에 대해 흥미로운 발표에서 관련 내용이 언급되었기 때문에 이제는 공개적으로 논할 수 있게 되었다. 발표 내용은 인터뷰와 함께 조만간 InfoQ에 공개될 것으다.

나는 이런 식의 트랜젝션 없이 프로그래밍 하는 방식에 대해서 자세히 살펴보고 싶다. 대안으로 여길 수도 있지만, 트랜젝션 처리를 하지 않는 것은 많은 사람들이 생각하는 것 보다 훨씬 보편적이기도 하다. 다수의 업무 프로세스가 여러 개의 리소스를 사용하는 경우는 오랫동안 유지되어야 하는 분산 트랜젝션을 갖고 있어야 할 수 있다. 혹은 트랜젝션 처리를 지원하지 않는 리소스를 포함하는 경우도 있다.

너무 편향적으로 흘러서는 안된다. 트랜젝션 처리를 고려할 필요가 없다고 주장하는 사람은 없다. 나는 eBay가 트랜젝션 처리를 하지 않는 것이 그들에게 적절한 결정이었는지에 대해서는 잘 모른다. 그러나, eBay의 사례로 인해 많은 사람들이 생각하는 것과는 달리 트랜젝션 처리 없이도 문제 없이 시스템을 운영할 수 있다.

출처: Transactionless

* 이 아저씨 그새 갱신했네요. 갱신 부분 다시 번역합니다.

최근에는 JRuby가 점차 성숙 단계로 들어서고 있고, 몇몇 사람들이 ant를 rake로 대치해서 빌드 스크립트를 개선할 궁리하고 있다.  

실제로 나의 동료였던 Matt Foemmel은 이러한 작업을 시작하여 진척사항을 FoemBlog에 기록하고 있다. Matt는 많은 빌드 스크립트를 작성해왔고, 2000년 즈음 우리 둘은 XML 기반의 빌드 파일을 바람직한 방향으로 오판했다. 또한, 우리 둘은 지금 완전한 스크립트 언어가 필요하다고 믿고 있다.

빌드 스크립트에는 선언적인 성격의 것과 절차적 성격을 지닌 것이 있다. 빌드 파일의 관건은 요구되는 작업 그리고, 작업 사이의 의존성을 정의하는 것이다. 이는 선언적인 부분으로 ant나 make와 같은 도구가 제격이다. 문제는 빌드가 복잡해지면 이러한 구조적인 요소만으로는 충분하지 않다는 것이다. 조건에 따른 로직이 필요해진다. 특히, rake에서 예를 든 것과 같이 고유의 추상적인 요소들을 정의해야 할 때는 더욱 그렇다.

Rake의 강점은 선언적인 특성과 함께 절차적인 특성을 제공한다는 것이다. Rake를 사용하면 선언적인 문법을 활용하여 간단하게 작업과 의존관계를 정의할 수 있는데다가 문법이 호스트 언어인 루비를 쓰는 DomainSpecificLanguage이기 때문에 루비의 강력한 기능을 제약없이 활용할 수 있다.

자바 프로그램 빌드를 위해 Rake를 사용하게 되면 자바 VM을 자주 시작시켜야 하는 번거로움이 주요 이슈로 지적된다. JRake는 자바 VM 내부에서 JRuby를 통해 구동한다. 그래서, 이러한 이슈를 해소할 수 있다.

빌드를 위해 Rake를 쓰면 새로운 의견을 배워야 한다는 점을 문제로 지적하는 경우가 종종 있다. 이들이 간과하는 바는 ant 역시 고유한 언어를 갖고 있다는 점이다. 단지, 호환성이 확보된 XML을 쓴다고 해서 ant의 다양한 작업(task)과 이들을 함께 사용하는 방법에 대한 배워야 하는 필요성이 사라지는 것은 아니다. 물론, 이미 ant를 알고 있는 경우라면 rake를 배우는 것이 부담이 될 수 있지만, 둘을 공평하게 놓고 보면 rake와 ruby 조합이 더 어려운 것은 아니다. 또한, 스크립트 언어를 사용하면 많은 다른 이점을 얻을 수 있다. (나는 모든 프로그래머가 적어도 하나의 스크립트 언어에는 익숙해야 한다고 믿는다. 스크립트 언어는 유용한 것들을 매우 많이 제공한다.)

지대한 투자가 있었기에 ant는 앞으로도 한동안 사용되겠지만, 우리 생각에 앞으로는 rake가 더 나은 솔루션이 될 것이다.

원문: JRake

어떻게 소프트웨어 개발자의 생산성을 향상시킬 수 있는가?

지금까지 다년간의 일상을 통해 얻는 대답은 컴퓨터를 사용하는 대부분의 사람들에게 적용되는데, 보다 큰 화면을 쓰라는 것이다.

15년전 모든 개발자가 21인치 화면으로 작업해야 한다고 권고해서 사람들을 놀라게 하곤 했다. 당시, 모두가 최소한 20인치 화면 두 개는 갖고 있어야 한다고 주장했다.

그것이 왜 중요한가? 작은 화면을 사용하면 한번에 많은 것을 볼 수 없다. 따라서, 다른 것을 보기 위해서는 지금의 창 앞에 새창을 띄워야 한다. 두 개의 화면을 이용하면 한번에 필요한 모든 꾸러미를 모두 화면에 놓을 수 있다. 단지 머리를 움직이기만 하면 된다. 내 눈은 지금 Emacs에서 편집중인 문자 사이를 가볍게 움직일 수 있다. 나는 수많은 하위 창이 열린 IDE를 열어둔 채로 오른편에는 브라우저에서 문서를 열어놓을 수 있다. 터미널 윈도우를 열기 위해서 작업 표시줄을 둘러볼 필요가 없이, 마우스를 이미 열려있는 창으로 가져가서 타이핑을 한다. 시도해보지 않은 사람은 얼마나 개선되는지 짐작할 수 없다. 나는 두 개의 화면을 쓰기 시작한 후에 달라진 것을 확연하게 느낄 수 있다.

그리고 두 개의 화면을 사용하는 것은 대부분의 사람들이 생각하는 것처럼 비싸지 않다. 친구와의 채팅으로 가격을 알아보니 내 두대의 삼성(Samsung) 204B 모델은 $700이었다. 개발자의 몸값은 비싸고, 그에 비하면 모니터 가격은 그리 큰 비용이 아니다 (흠.. 내 책상에는 세번째 화면을 맞이할 공간이 있군.)

최근에는 흔하게 작은 화면에서 페어 프로그래밍을 하는 모습을 볼 수 있다. 이것은 어리석은 짓이다. 큰 화면을 사용하는 것은 현명한 투자다.^[각주:1]

원문: BigScreen

POJO라는 용어는 Rebecca Parsons, Josh MacKenzie와 내가 2000년 9월 한 컨퍼런스를 준비하는 대화에서 비롯되었다. 대화 중에 우리는 업무 로직을 엔터티 빈(Entity Beans)보다는 일반 자바 객체에 포함시켰을 때 장점이 많다는 점에 공감을 이뤘다. 우리는 왜 사람들이 시스템을 구현할 때 일반 자바 사용을 꺼리는지 궁금했고, 마침내 단순한 객체는 그럴싸한 이름이 없기 때문이라는 결론에 이르렀다. 그래서 우리는 일반 자바 객체에 솔깃할만한 이름 POJO를 붙여 주었고, POJO는 곧 인기를 끌기 시작했다.

원문: POJO

서문

소프트웨어 개발 분야에서 새로운 사고는 실제로는 기존의 생각에서 변형된 것이다. 이 논문도 그 중 하나에 해당하한다. 내가 Language Workbenches라고 부르는 일종의 도구들의 유형에 대해 기술한다. 이러한 도구의 예는 Intentional Software, JetBrains의 Meta Programming System 그리고 MS의 Software Factories등 이다. 이들 도구는 내가 언어 지향적 프로그래밍(language oriented programming)이라고 말하던 기존의 개발 방식을 취하지만, IDE 도구를 통해 보다 원활한 언어 지향적 프로그래밍이 가능하게 한다. 비록 그들이 성공할지 예측하긴 힘들지만, 이들은 소프트웨어 개발 분야에서 수면 위로 부상하는 가장 흥미로운 것의 하나라고 생각한다. 어떻게 동작하는지 그리고 향후 유용성 증대를 위한 이슈를 대략적으로 나마 설명하는 것은 충분히 흥미롭기에 이 글을 작성한다.


개요

소프트웨어 시스템을 domain specific language를 활용하여 기술하려는 소프트웨어 개발 방식은 오래도록 있어 왔다. 유닉스 진영에서는 전통적으로 lex와 yacc로 코드를 생성하는 작은 언어들(little languages)가 존재했왔다. Lisp 커뮤니티에서도 Lisp 내에서 매크로(macro)를 활용하여 언어를 개발하는 것을 볼 수 있다. 이러한 접근은 강력한 지지자들이 있지만, 그다지 널리 보급되지는 못했다.

최근 몇 년 사이에 새로운 유형의 소프트웨어를 통해서 이러한 개발 방식을 지원하려는 시도가 있었다. 가장 먼저 그리고 가장 널리 알려진 것이 Intentional Programming이다. 이것은 원래 Charles Simonyi가 Microsoft에 있을 때 처음으로 개발했다. 그러나, 비슷한 시도를 하는 다른 사람들이 있고, 이러한 접근에 대한 사람들의 흥미를 급속도로 유발시키고 있다.

나는 이쯤에서 이 글에서 사용할 몇몇 단어를 정의하겠다. 이 분야에 대해서는 보편적으로 쓰이는 표준 어휘가 없기 때문에 내가 사용하는 단어들이 어떤 곳에서든 통용될 것이라고 기대할 수는 없다. 여기서는 간략하게 정의를 하겠지만 글이 계속되면서 더 자세히 설명할 것이기 때문에 당장에 이해가 가지 않아도 걱정할 필요는 없다.

이 글을 위해서 만들어낸 두 개의 용어는 '언어 지향적 프로그래밍(Language Oriented Programming)’과 ‘Language Workbench’이다. 언어 지향적 프로그래밍이라는 용어는 domain specific language의 집합으로 소프트웨어를 개발하려는 생각을 실현하는 개발 방식을 통칭하여 말할 때 사용한다. Language Workbench는 앞서 언급한 새로운 종류의 툴을 가리킬 때 사용한다. 따라서, Language Workbench는 언어 지향적 프로그래밍을 위한 하나의 수단이다. Domain Specific Language(DSL)이라는 용어에도 익숙하지 않은 사람들이 있을 것이다. DSL은  특정한 유형의 문제를 위해 고안된 제한된 형식의 컴퓨터 언어를 말한다. 몇몇 커뮤니티에서는 오로지 특정 문제 영역을 다루는 언어로만 DSL을 사용하지만, 나는 범위만 한정한다면 어떠한 영역에서도 DSL을 사용할 수 있다고 생각한다.

나는 먼저 한가지 예제를 통해 언어 지향적 프로그래밍의 현재 모습을 간략히 기술하고, 다양한 변이를 이루는 접근 방법들을 개략적으로 살펴보겠다. 그리고, 다양한 접근 각각에 대한 긍정적인 면과 부정적인 면에 대한 다양한 논의들을 살펴볼 것이다. 만일 언어 지향적 프로그래밍에 친숙한 독자라면, 이 내용들을 읽지 않기를 바랄 수 있다. 하지만 실제로 대부분의 개발자들이 이러한 개념에 익숙하지 않다는 것을 알고 있다. 대략의 설명을 바탕으로 이후에는 어떤 language workbench가 있고, 상충되는 것들을 어떻게 해결할지 알아볼 것이다.

내가 이 글을 쓸 때, 하나의 글로 쓰기에는 너무 크다는 것을 알았다. 그래서, 논문의 일부를 들을 다른 글로 나누었다. 글의 특정 내용이 다른 글을 참조할 필요가 있을 때는 바로 아래에 링크를 달아 두었다. 특히, 주로 쓰이는 language workbench를 이용하여 DSL을 만들어낸 실제적인 사례를 느끼기 위해서는 MPS를 이용한 예제를 참조하기 바란다. 이후에 이어지는 글을 충분히 이해하기 위해서 이곳의 language workbench에 대한 일반적인 설명을 끝까지 읽어볼 필요가 있다.


목차

• 언어 지향적 프로그래밍의 간단한 예
• 언어지향 프로그래밍의 전통
  • 유닉스의 작은 언어(Little Languages)
  • Lisp
  • Active Data Models
  • Adaptive Object Models
  • XML 구성 설정 파일
  • GUI 생성기
• 언어 지향 프로그래밍(language oriented programming)의 장단점
  • 외부 DSL
  • 내부 DSL
  • 프로그래머가 아닌 사람의 참여
  • 언어지향 프로그래밍의 상충관계 요약
• Language Workbench의 현황
• Intentional Software
• Meta-Programming System
• Software Factories
• Model Driven Architecture (MDA)

* Elements of a Language Workbench 이하는 번역하지 않습니다.

원문 최근 갱신: 2005년 6월 12일
번역: 영회, 백기선
원문: Language Workbenches: The Killer-App for Domain Specific Languages?

내 경험안에서 Language Workbench로 분류로 적당한 것으로 이야기를 시작하겠다. 이들 도구들이 개발 초기에 있다는 점을 기억해야 한다. 대규모 소프트웨어 개발에서 Language Workbench가 사용되기 위해서는 아직 수년의 시간이 필요하다.

Intentional Software
Intentional Programming은 Language Workbench의 시조격이다. 원래 Intentional Programming은 Charles Simony가 Microsoft 연소구에서 개발했다. 몇 년 전에 Simony는 Microsoft를 떠났고 Intentional Software를 독자적으로 개발하기 위해서 회사를 차렸다. 보편적인 시작이기는 하지만 그는 개발에 대해 별다른 공개를 하지 않았다. 그 결과 Intentional Software에 무엇인지 그리고 어떻게 사용하는지에 대한 정보가 없다.

나는 Intentional Software와 약간의 시간을 보낼 수 있는 기회가 있었고, 작년부터인가 ThoughtWorks의 몇몇 동료들은 Intentional과 함께 일하고 있다. 그 결과 베일 속에 가려진 intentional에 대해 엿볼 기회가 있었다. 다행히 내년쯤 그들의 작업이 공개될 예정이라고 한다.

(용어 측면에서 그들이 Microsoft사에서 작업했던 것에 대해서는 Intentional Programming이라 하고, 자사의 작업은 Intentional Software라 부른다.)

Meta-Programming System
JetBrains가 개발 한 Meta Programming System은 이후에 출시되었다. JetBrains는 뛰어난 IDE 덕분에 소프트웨어 개발자들 사이에서 꽤 좋은 평판을 얻고 있다.

IDE를 통해 얻은 JetBrains의 경험은 language workbenche와 몇가지 측면에서 연관을 지닌다. 먼저 툴 시장에서 IntelliJ의 성공은 기술적인 능력과 실용적인 면 모두에 걸쳐 상당한 신뢰를 제공한다. 두 번째로 language workbench 기능의 상당부분이 IntelliJ 이후의 IDE의 기능과 매우 밀접하게 연관되어있다.

JetBrains은 수년을 Fabrique라고 하는 웹 애플리케이션 개발을 위한 풍부한 기능을 제공하는 개발 환경을 위해 투자했다. Fabrique 개발 경험으로 그들은 미래에는 보다 효과적으로 이러한 유형을 툴을 개발하기 위한 플랫폼이 필요하다는 확신을 갖게 되었다. 이러한 욕구가 바로 JetBrains를 MPS 개발로 이끈 장본인이다.

Intentional Software에 대한 정보 공개는 MPS에 큰 영향을 끼친다. MPS는 Intentional Software보다 개발에 투자한 시간이 적었지만, JetBrains는 공개된 개발 주기를 중요하게 여긴다. JetBrains는 유용한 기능이 개발되자마자 곧 바로 조기 공개 프로그램(Early Access Program)을 통해 MPS를 선보이기로 했다. 현재 2005년 전반기 정도로 예측하고 있다.

나는 운좋게도 최근에 Sergey Dmitriev와 일할 수 있었는데, 그는 MPS를 주도하고 있다. MPS 작업이 JetBrains의 매사추세츠 사무실 밖에서도 수행되게 되었고, 내가 이를 접하는 것이 더욱 수월해졌다. 지리적으로 가까워지고 그들의 열린 태도로 인해서 나는 MPS를 몇 가지 구체적인 예제에 사용할 수 있게 되었다.

Software Factories
Software Factories는 마이크로소프트의 Jack Greenfield와 Keith Short에 의해 시작되었다. 소프트웨어 팩토리를 Language Workbench 분류에 넣기에 모호한 요인들이 있지만, DSL을 위한 노력 즉, 언어 지향적 프로그래밍(language oriented programming)은 소프트웨어 팩토리에서 중요한 역할을 한다.

소프트웨어 팩토리 개발팀은 모델 주도의 개발(Model Driven Development)에 배경을 두고 있다. 소프트웨어 팩토리 개발팀에는 CASE 툴 개발자와 영국의 객체 지향 커뮤니티를 주도하는 사람들이 포함되어 있다. 그래서, DSL로 그래픽을 활용하는 것은 놀랄 일이 아니다. 그러나, 대부분의 CASE 툴 진영과 달리, 이들은 그래픽 요소에 담는 의미적인 부분과 코드 생성에 대한 통제에 깊은 관심을 갖고 있다.

내 논의의 대부분은 전통적인 애플리케이션 프로그래밍에 대해 언급했다. 소프트웨어 팩토리 개발팀은 특히 DSL을 소프트웨어 개발 이외의 영역에 활용하는데 많은 관심을 갖고 있다. 가령, 자동화가 어려운 배포, 테스트 그리고 문서화가 여기에 해당한다. 마이크로소프트의 DSL팀은 몇달전부터 비주얼 스투디오 2005 팀 시스템의 일부로 다운로드가 가능하게 했다.

Model Driven Architecture (MDA)
OMG의 MDA에 대해 알고 있다면, 내가 언급한 language workbenches와 MDA의 비전 사이의 유사성을 보았을 것이다. 논쟁을 유발할만한 이슈이지만 지금으로썬 MDA의 일부 비전은 language workbenches의 형태라고 말할 수 있다. 하지만, MDA가 language workbenches의 모두를 포용하는 것은 아니며, MDA에기반하여 language workbenches를 구축하는 것은 잘못된 것이다. 여기에 대해서는 다른 글을 통해 자세하게 기술하였다.

다양한 형태의 언어지향 프로그래밍이 꽤나 널리 사용되는 것을 알 수 있다. 대략적으로 이들을 두 가지 스타일로 나누는 것이 유용함을 발견했다. 하나는 DSL을 포함하는 프로그래밍 언어와 다른 언어로 작성하고 컴파일러나 인터프리터를 사용하여 변환하는 외부 DSL(External DSL)이다. 이것은 된다. Unix의 작은 언어, 액티브 데이터 모델(active data model)그리고 XML 구성 설정 파일 등이 여기에 속한다. 다른 하나는 DSL을 포함하는 프로그래밍 언어로 DSL을 작성하는 내부 DSL(Internal DSL)로 Lisp의 전통이 전형적인 예다.

이들 둘을 구분하기 위해 적절한 용어가 없어, 이 글을 위해 내부/외부로 구분되는 용어를 만들었다. 내부 DSL은 종종 포함된 DSL(embedded DSL) 이라는 말이 쓰이지만 워드에 포함된 VBA와 같이 외부 DSL이지만 포함되는 것들이 있기 때문에 혼란을 피하기 위해 포함된(embedded)이라는 표현은 쓰지 않겠다. 하지만, DSL에 관련된 많은 글에서 포함된 DSL가 같은 표현을 자주 보게 될 것이다.

외부 DSL과 내부 DSL을 위해 고려할 사항은 상당한 차이가 있기 때문에 나누어서 설명하는 것이 좋겠다.

외부 DSL(External DSL)

외부 DSL을 애플리케이션에 사용된 주요 언어와 다른 언어로 작성된 DSL이라고 정의했다. 앞의 마지막 두 예제가 여기에 해당하며 Unix의 작은 언어와 XML 구성 설정 파일이 좋은 예이다.

외부 DSL의 주요 장점은 선호에 따라 어떤 형태로든 사용이 가능하다는 것이다. 따라서 도메인을 읽고 수정하기 가장 쉬운 형식으로 표현할 수 있다. 구성 설정 파일의 파싱과 실행 가능한 코드를 생성할 수 있는 변환기 구현이 가능하다면 그 외에는 형식에 제약을 받지 않는다.

여기에서 반드시 변환기를 만들어야 한다는 단점을 발견할 수 있다. 앞서 살펴본 것처럼 단순한 언어의 경우에는 어려운 작업은 아니다. 좀 더 복잡한 언어에서는 이 작업이 힘들겠지만, 여전히 나쁜 방법은 아니다. 파서 생성기와 컴파일러 저작 도구는 매우 복잡한 언어를 DSL 다룰 때 도움을 준다. 게다가 DSL은 대개 매우 간단하다. XML을 사용하게 되면 DSL의 형식은 제한적이지만, 파싱은 매우 쉽다.

외부 DSL의 진정한 단점은 내가 기호의 통합(symbolic integration)이라고 부르는 것이 결여되어 있다는 점인데, 이는 DSL은 기반 언어와 연관성을 갖지 않는다는 점이다. 기반 언어 환경은 우리가 무엇을 하는지 신경을 쓰지 않는다. 프로그래밍 환경은 점차 복잡해지고 있고, 이러한 복잡한 프로그래밍 환경 문제는 확대되고 있다.

간단한 예를 들어, 앞서의 예에서 보았던 생성 대상 클래스에 있는 속성의 이름을 바꾸려고 한다고 가정해 보자. IDE를 사용하면 자동적으로 이름을 바꾸는 리팩토링이 가능하다. 하지만 DSL에도 적용되지는 않는다. C#과 DSL 맵핑 파일 사이에는 기호의 장벽이 존재한다. 맵핑 내용을 C#으로 변환하게 되지만 이러한 장벽은 전체 프로그램을 작성하는 능력에 제한을 가한다.

통합의 결여로 인해 도구가 필요해진다. 먼저 우리는 어떻게 DSL을 작성할 것인까? 텍스트 편집기로도 가능하지만, 현재의 IDE에 비하면 부족해보인다. 나는 팝업 목록을 제공하고, 자동 완성 기능과 잘못된 것을 빨간 줄로 표시 해주는 기능이 필요하다. 그러나, 이를 위해서는 편집기가 내 DSL의 의미를 알아야 한다.

DSL의 의미를 이해하는 편집기 없이 코딩을 할 수는 있지만, 디버깅할 때를 생각해보자. 내가 사용하는 디버깅 툴은 변환된 C#코드로 DSL을 단계적으로 접근할 수 있다. 그러나, 진짜 소스 코드 자체에 대해서는 불가능 하다. 내가 진짜로 원하는 것은 나의 DSL을 이해하는 완전한 IDE다. 텍스트 에디터와 단순한 디버깅을 사용하던 시절에 이것은 큰 이슈는 아니었겠지만 현재는 post-IntelliJ 세상이다.

외부 DSL에 대한 잘 알려진 반대 사유는 별도의 언어를 배워야 한다는 점^[각주:1]이다. 언어를 배우는 것이 어렵고 따라서 여러 언어를 사용 하는 것은 하나의 언어를 사용하는 것보다 훨씬 복잡하다는 것이다. 이러한 견해는 DSL에 대한 오해에 기인한 면이 있다. 이렇게 주장하는 사람들은 실제로는 종종 범용적인 프로그래밍 언어가 혼용되어 혼란을 야기시키는 것은 상상한다. 그러나, DSL은 대개 제한적이고 단순하여 배우기 쉽다. 도메인에 익숙해질수록 더욱 쉬워진다. DSL은 일반적인 언어와는 다르다.

특수한 경우를 제외하면 프로그램의 규모에 관계 없이 만들고자 하는 것에 대해 다각적으로 추상적인 측면을 다뤄야 한다. 앞에서 예를 든 파일 읽기도 한 가지 예가 된다. 이러한 추상화는 보통 객체와 메소드를 사용하여 다루게 된다. 사용하는 프로그래밍 언어를 이용하여 원하는 바를 표현할 수 있지만 제한된 문법만을 사용해야 한다. 외부 DSL을 사용하게 되면 보다 쉬운 방법으로 작업이 가능하다. 의문의 소지가 있는 부분은 새로운 DSL을 익히는 비용에 비해서 외부 DSL 사용으로 인해 코드 작성이 충분히 쉬워지는가 하는 것이다.

이와 유사한 이슈로 DSL 설계의 어려움이 있다. 언어의 설계는 어렵기 때문에 대부분의 프로젝트에서 여러 DSL을 설계하는 것은 매우 어렵다는 것이다. 이러한 부정적인 견해는 역시 DSL이 아닌 일반적인 목적으로 사용되는 프로그래밍 언어를 염두한 생각이다. 여기서 근본적인 이슈는 제대로 추상화 해내는 것이 어렵다는 점이다. API 설계와 DSL 설계의 차이는 그렇게 크지 않다. 따라서, 나는 DSL 설계가 좋은 API를 만드는 것에 비해 그리 어렵다고 생각하지 않는다.

많은 사람들에게 외부 DSL이 주는 큰 장점은 DSL이 컴파일 없이 실행 시점에서 평가된다는 점이다. 값이 변하는 매개변수가 있어도 프로그램을 다시 컴파일 할 필요가 없다. XML이 자바 사용자들에게 인기를 끄는 원인이기도 하다. 이것은 정적으로 컴파일을 수행하는 언어에서는 중요한 이슈이지만, 실행 시점에서 문장을 평가하는 다수의 언어에 있어서는 중요하지 않다. 한편, .Net의 IronPython과 같이 컴파일 언어와 실행 시점의 번역 언어의 혼용에 대한 관심이 증대하고 있다. 이는 C# 시스템의 문맥 안에서 IronPython이 내부 DSL을 수행하게 한다. 이것은 유닉스 진영에서 흔히 C/C++과 스크립트 언어를 혼합해 사용하던 기법과 같다.^[각주:2]

내부 DSL(Internal DSL)

내부 DSL은 외부 DSL의 장, 단점을 뒤집은 것과 같다. 애플리케이션 작성에 사용한 기반 언어와의 의미적 장벽을 없애고, 해당 언어에서 사용 가능한 모든 특성들을 활용할 수 있다. 내부 DSL의 예로는 Lisp과 Adaptive Object Model이 있다.

내부 DSL 대해 언급되는 문제는 Lisp과 같이 내부 DSL에 적합한 언어와 중괄호를 쓰는 주류 프로그래멍 언어 사이에 큰 차이가 존재한다는 것이다. 내부 DSL은 Java 나 C# 보다 Lisp 또는 Smalltalk에서 구현이 적합하다. 실제로 동적 언어 지지자들은 이 점을 주요 장점으로 꼽는다. 우리는 이미 이와 유사한 내용을 스크립트 언어에서 발견했다. 루비의 메타 프로그래밍 지원과 Rails framework에서 활용되는 양상을 생각해보라. 그러나, 많은 프로그래머 들이 동적 언어를 깊이 있게 사용해 보지 않아, 그러한 기능을 평가하고 실질적인 제약을 아직 알고 있지 못하다는 점이 문제를 복잡하게 만든다.

내부 DSL은 기반 언어^[각주:3]의 구조와 문법에 의해 제한된다. 동적 언 일수록 제한이 줄어든다. Lisp, Smailltalk나 스크립트 언어와 같은 동적 언어는 불필요한 것을 최소화한 문법을 가지고 있어 주류 언어보다 더 적합한 경향이 있다. 앞서의 C#과 루비 예를 비교해보라. 또한 동적 언어가 제공하는 클로저 (Closure)와 매크로(macro)같은 기능은 매우 유용하다. C에 기반하고 있는 언어들은 내부 DSL 작성에 적합한 기능이 많이 빠져 있지만, 존재하지 않는 것은 아니다. C#의 애노테이션(Annotation)이 좋은 예이다.

기반 언어의 개발도구는 DSL을 이해하고 있지 못하기 때문에 완전한 DSL 지원이 불가능하다. 단순한 텍스트 에디터 보다는 나은 선택히지만 개선의 여지는 많이 남아있다.

DSL에서 기반 언어의 모든 기능을 발휘 할 수 있다는 것은 혼란스러운 축복이다. 만약에 기반 언어에 친숙하면 문제 될 것이 없다. 하지만 DSL의 장점은 기반 언어를 잘 몰라도 프로그램 작성이 가능하다는 것이다. 서툰 프로그래머일지라도 도메인 기반 정보를 이용하여 시스템을 구현하는 일이 훨씬 쉬워진다는 장점을 갖는다. 그런데, 내부 DSL을 사용하면 기반 언어에 대한 지식이 없이는 혼란을 겪을 여지가 많아져 이러한 장점이 약화된다.

한가지 예로 DSL 작성을 위해 일반적인 프로그래밍 언어를 위한 개발 도구를 사용하는 경우를 고려해보자. 이들 개발도구는 상당히 많은 기능을 제공하지만, DSL 작성에는 소수의 기능만이 사용된다. 너무 많은 기능이 존재하는 것은 도리어 DSL 작성을 어렵게 할 수 있다. 개발도구가 제공하는 기능을 충분히 익히고 나서야 사용자가 실제로 작업에 필요로 하는 기능을 찾을 수 있다. 이상적인 것은 어떤 작업을 수행하는데 꼭 필요한 기능만 제공하는 즉, 부족하지 않으면서 너무 많은 것을 제공하지는 않는 개발도구이다. (Charles Simonyi는 degrees of freedom라는 개념으로 이를 설명하고 있다.)

사무용 프로그램에서 비슷한 예를 찾아볼 수 있다. 많은 사람들의 워드 프로세서가 일반적인 사용자들이 필요로 하는 것보다 훨씬 많은 기능을 제공하고 사용이 어렵다고 불평한다. 하지만, 누군가는 원하는 기능을 추가하다 보면결국 모든 사용자를 만족시키는 거대한 시스템이 된다. 대안으로 여러 개의 오피스 도구를 만들고, 적합한 작업에 활용하는 것이다. 그렇게 되면 각각의 툴은 전보다 사용하기 쉬워질 것이다. 물론, 다수의 도구 개발로 비용이 증가한다는 것이다. 이 문제는 일반적인 언어를 이용하여 DSL을 작성하는 것(내부 DSL)과 외부 DSL이 갖는 상충 관계와 매우 닮아 있다.

내부 DSL은 프로그램 언어와 밀접하기 때문에 프로그램 언어 자체와 잘 대응 되지 않는 무언가를 표현하고 싶을 때 어려움이 발생한다. 예를 들어, 기업용 정보 시스템에서 레이어(Layer) 개념은 매우 친숙한 것이다. 레이어는 패키지를 사용하여 정의 하지만 레이어 사이의 종속성을 정의하는 것은 힘들다. 그래서 UI 코드를 MyApp.Presentation에 그리고 업무 로직을 MyApp.Domail에 넣어 두겠지만, 내부DSL은 MyApp.Domain이 MyApp.Presentation에 있는 클래스를 참조할 수 없다는 것을 나타낼 수가 없다. 이는 주류 언어의 제한된 역동성을 다시 한번 보여 준다. Smalltalk에서는 메타 수준의 접근이 더욱 용이해서 이러한 것들이 가능하다.

비교를 원한다면 동적 언어로 개발한 좀더 복잡한 예제를 보라. (예제를 위한 참고 자료)


프로그래머가 아닌 사람의 참여

언어 지향적 프로그래밍의 두 형태에 상관없이 Lay Programmer^[각주:4]의 참여는 지속적으로 논의의 주제가 되고 있다. 업무 전문가를 참여시키는 프로그래밍^[각주:5]의 목표는 소프트웨어 업계의 오랜 목표와 다르지 않다. 실제로 많은 사람들은 COBOL과 FORTRAN 같은 초창기 고수준 언어로 인해 프로그래머가 사라질 것이라고 믿기도 했다. 이는 내가 코볼 추론(COBOL inference)이라고 말하는 것을 떠올리게 한다. 대부분의 기술의 등장으로 전문적인 프로그래머가 사라질 것이라는 소문이 나돌지만 그런 일은 벌어지지 않는다.

코볼 추론에도 불구하고, 일부 프로그램 작성을 사용자에게 맡기면서 종종 성공한 사례가 있다. 한가지 방법은 사용자들이 제한된 문제 영역을 분리하여 충분히 쉽게 제공하여 편안하게 프로그래밍 할 수 있게 하는 것이다. 그리고 나서, 이러한 사용자 프로그래밍 영역을 DSL로 바꾼다. 이러한 DSL은 매우 고도화 될 수 있다. MatLab의 매우 복잡한 DSL이 좋은 예이다. 이는 도메인에 집중을 해서 발생하는 복잡함이다.

사용자가 작성가능하다는 외부 DSL의 장점은 기반 언어의 짐을 덜어주면서 사용자에게 매우 명확해진다. 내부 DSL을 사용하는 경우는 아무리 간단한 언어를 다룬다고 해도 사용자가 DSL의 영역을 넘어선 작업을 했을 때 나타나는 알 수 없는 동작과 메시지로 혼란을 겪을 수 있다.

언어 지향 프로그래밍의 많은 지지자들은 사용자가 시스템의 업무 로직을 작성하는 미래를 꿈꾸고 있다. 그리고 프로그래머들이 작성한 도구에 의해, 업무 로직이 편집되고 컴파일 된다. 하기 위한 툴을 작성할 것이다. 이것은 전문 프로그래머들의 종말을 뜻하는 것이 아니다. 이때 사용한 도구의 상당 부분은 재사용이 가능해져 시스템 개발에 요구되는 작업량은 현격하게 줄어든다. 또한, 오늘날 소프트웨어 개발의 주요한 지연 사유인 의사소통 문제를 상당히 감소시킬 것이다. 코볼 추론이 냉소적으로 회자 되지만, 이러한 lay programmer의 꿈은 상당히 매력적인 것이다.

lay programming에 대해 가치 있는 일이라고 마무리했지만, lay programming만이 언어 지향 프로그래밍의 주안점은 아니다. 좋은 DSL은 비록 사용자들이 참여를 끌어내지 못하더라도 전문 프로그래머가 보다 생산적으로 일할 수 있게 한다. 결국, 좋은 DSL이라면 프로그래머가 이를 작성하고, 업무 전문가들이 검토하기 용이해야 한다.

Lay programmer 논쟁은 도박 같은 측면이 있다. 나는 특정 기술을 사용하여 대규모 프로젝트에서 사용자 참여를 이루어낼 수 있을지에 대해 회의적이지만, 만일 그런 일이 일어난다면 엄청난 성공을 거둘 것이다. 그렇다고 해서 프로그래밍 전문가가 사라지는 일은 발생하지 않는다. 오히려, 종종 소프트웨어 개발 프로젝트의 가장 큰 장애물인 업무 전문가와 개발자 사이의 지독한 의사소통 문제를 개선해 줄 것이다.


언어지향 프로그래밍의 상충관계 요약

내 생각에 언어 지향 프로그래밍의 근본적인 문제는 DSL을 사용해서 얻는 이점과 이를 효과적으로 지원하는 도구 개발 비용의 문제이다. 내부 DSL을 사용하면 도구 개발 비용은 줄지만, DSL을 사용해서 얻는 이점도 약화된다. 특히나 C 기반의 언어를 사용하는 경우는 더욱 그렇다. 외부 DSL은 잠재적인 이점은 증가되지만 DSL을 고안해내고, 변환기와 같은 지원 도구 개발에 필요한 비용 역시 커진다.

이러한 이유로 인해 언어 지향 프로그래밍의 진척이 느리다. 언어 내부 그리고 언어 외부 둘 모두 뚜렷한 단점을 가지고 있다. 그 결과, DSL을 이용하여 무엇을 할 것인가 하는데 있어서 괴리가 생겼다.

이것은 자연스럽게 language workbench의 필요성을 말해준다. Language workbench는 본질적으로 의미적 장벽의 제거로 외부 DSL에 유연성을 부여하고자 한다. 게다가, 최고의 IDE와 연계된 개발 도구를 작성하는 것을 수월하게 한다. 그 결과 언어 지향 프로그래밍의 적용이 용이해지고, 많은 사람들로부터 어색하게 느껴졌던 언어지향 프로그래밍의 장벽을 낮추고 있다.

논문 전체 보기

원문: Pros and Cons of language oriented programming

소프트웨어 개발을 대하는 두 가지 태도(SoftwareDevelopmentAttitude)중에 하나. 개발자의 여지를 허용하는 태도에서는 개발자는 책임있는 전문가이다. 그렇기 때문에 필요하다고 생각하는 것은 무엇이든 할 수 있는 자유가 주어져야 한다. 올바른 사용을 한다면 개발 환경은 수월한 작업^[각주:1]을 지원하지만, 개발자 자신이 하는 일에 대해 잘 알고 있다고 가정하기 때문에 잘못된 작업 수행을 예방하는 측면은 찾아보기 힘들다. 개발 환경을 잘못 사용하게 될 우려가 있기 때문에 이러한 태도가 유용하려면 개발자들은 더 잘 알아야 한다.

지시에 따르는 태도(directing attitude) 옹호자들은 이같은 태도는 상위 소프트웨어 개발자에게나 적용할 수 있는 엘리트 주의에 지나지 않으며 대다수의 개발자들에게 적용하는 것은 실용적이지 못하다고 비판한다.

원문: EnablingAttitude

두 가지 소프트웨어 개발의 태도(Software Development Attitude) 가운데 하나. 지시에 따르는 태도(directing attitude)의 지지자에 의하면 (소문에 따르면 거의 50% 이상의 개발자는 평균 이하라고 할 정도로) 대부분의 개발자들을 뛰어나지 못하기 때문에 그들이 어떻게 작업해야 하는지를 지시해야 한다. 이러한 지시로 인해 그들이 시스템에 해를 끼치는 일을 하는 것을 막을 수 있다. 대개 이러한 태도는 설계나 도구를 통해 개발자들의 잘못된 행위를 막고, 복잡한 영역을 피해 수행할 수 있는 것들에 제약을 가한다.

개발자의 여지를 허용하는 태도(EnablingAttitude)를 지지자들은 이와 같은 가혹한 태도를 비판한다. 그들의 논리에 의하면 잘못을 저지를 수 없는 방책을 마련하는 것을 불가능하다. 어리섞은 이들은 교묘하게 시스템을 망치는 방법을 찾아내기 때문이다.

원문: DirectingAttitude

메소드나 클래스를 봉인하여 상속 클래스가의 재정의(overriding)를 막을 수 있다.

C#에서는 sealed 키워드, 자바에서는 final 키워드를 사용한다. C#과 C++ 같은 언어는 메소드가 기본적으로 봉인된 것으로 간주한다. virtual 키워드를 부여하여 봉인을 해제한다. 반면, 자바와 같은 언어에서는 기본적으로 메스도가 봉인되지 않다.

봉인이 바람직한 것인지에 대한 많은 논란이 있다. 지시에 따르는 태도(directing attitude)를 가진 이들은 재정의가 가능한 클래스나 기능(features)에 대해 매우 조심스러워서 안전할 것으로 간주된 것만 확장을 허용 한다. 개발자의 여지를 허용하는 태도(EnablingAttitude)를 가진 이들은 확장이 필요한 메소드와 그렇지 않을 것을 예측할 수 없다는 견해를 갖는다. 프로그래머가 원하면 어떤 메소드라도 재정의를 할 수 있는 대신에 책임감을 갖고 주의해야 한다. 대개 나는 후자의 태도 갖는다.

원문: Seal

슈하리(シュハリ)는 기술을 습득하는 방법에 대한 고찰이다. 그 이름은 합기도에서 유래하였으며 Alistair Cockburn이 소프트웨어 개발 기술과 벙법론에 학습하는 방법으로써 소개했다.

슈하리는 사람은 세 가지 단계를 거쳐 지식을 습득한다는 것이다:

• 슈(シュ): 첫번째 단계에서 학습자는 스승의 가르침을 정확하게 따르게 된다. 기초가 되는 사상에 대해 깊이 고민하지 않고, 어떻게 수행해야 하는지에 초점을 맞추게 된다. 다양한 수행 방안이 있는 경우에도 스승이 가르쳐준 방식에만 집중한다.
• 하(ハ): 이 단계에서 학습자의 확장이 시작된다. 기본적인 연습을 통해 학습자는 기초가 되는 원리와 기술 이면의 사상을 배우기 시작한다. 학습자는 또한 다른 스승을 통해 배움을 얻기도 하고, 연습을 통해 배운 것을 하나로 융화시킨다.
• 리(リ): 이제 학습자는 다른 사람에게 배우는 것이 아니라 스스로 터득한다. 고유의 접근 방법을 찾아서, 주어진 환경에 맞춰서 자신이 배운 것들을 적응시켜 나간다. He creates his own approaches and adapts what he's learned to his own particular circumstances.

Alistair의 책에서 보다 자세한 설명을 볼 수 있다: Agile Software Development.

출처: ShuHaRi

이미 번역하신 분이 있어서 링크로 제공합니다: 클로저 (Closure) - 마틴 파울러

원문: Closure

이미 번역된 글이 있기에 링크로 대신합니다:

IoC 콘테이너와 디펜던시 인젝션 패턴

원문: Inversion of Control Containers and the Dependency Injection pattern

예제에서 봤듯이 언어 지향 프로그래밍은 새로운 것이 아니다. 사람들은 이미 언어 지향 프로그래밍을 꽤나 자주 사용해 왔다. 따라서 Language workbench를 살펴보기 전에 언어 지향 프로그래밍의 현황을 살펴보는 것이 좋겠다.

많은 수의 언어 지향 프로그래밍 스타일이 존재하기 때문에 이들을 요약하는 것이 유용할 듯 하다.

유닉스의 작은 언어(Unix Little Languages)

DSL로 볼 수 있는 가장 두드러진 현상은 작은언어(ittle languages)을 작성하는 유닉스의 전통이다. 유닉스의 작은언어는 변환 과정에서 유닉스로 작성된 도구가 필요한 외부(external) DSL이다. 대학을 다닐 때 유닉스의 보편적인 툴과 유사한 lex와 yacc을 가지고 놀았다. 대개 이러한 툴을 활용하면 C언어로  파서를 작성하고 작은 언어를 생성하는 것을 수월해진다. Awk는 이와 같은 작은 언어의 좋은 예다.

Lisp

Lisp은 동일한 언어로 DSL들을 표현하는 가장 대표적인 예가 된다. 기호의 처리는 Lisp 사용자들의 관행과 그 이름안에 내재되어있다. 최소지향적(minimalist) 문법, 클로저(closures), 매크로 등의 Lisp의 특징은 이러한 작업을 돕는다. Paul Graham은 이와 같은 개발 스타일에 관해 많은 글을 작성했다. Smalltalk 또한 이러한 개발 스타일에 대해 오랜 전통을 가지고 있다.

Active Data Models

고도의 데이터 모델을 작성하는 유형의 사람들은 시스템의 매우 가변적인 부분마저 데이터베이스 테이블 형태로 포착한다. 이와 같은 테이블을 메타 데이터 테이블(meta-data tables)이라고 하며, 이러한 방식을 테이블 주도의 프로그램(table-driven programs)이라고 한다. 프로그램 코드는 메타 데이터 테이블의 데이터를 해석하여 시스템의 행위를 구현한다.

이 경우도 본질적으로는 DSL이다. 구체적인 문법이 데이터베이스 테이블 형태를 갖게 된다. 이들 유형의 테이블에 담긴 Active data를 수정을 위해서 대개 GUI가 활용된다. 일반적으로 이러한 작업을 언어를 생성할 것으로 생각하지 않는다. 그러나, 관계형 데이터베이스의 문법을 이용한 작업은 쉽게 행할 수 없기 때문에 이렇게 만들어진 언어는 필요한 것에 집중되어 작게 유지되는데 유리하다..

Adaptive Object Models

하드코어 객체 프로그래머(hardcore object programmers)는 시스템 개발을 객체의 구성을 통해 유연하고 강력한 환경으로 발전해가는 것이라고 말할 것이다. 이러한 방식의 시스템은 복잡한 도메인 모델을 구축한다. 시스템의 주요 행위는 객체의 협업을 통해 매우 복잡한 사항까지 해결할 수 있는 구성을 갖추게 된다. 객체 지향 옹호자들은 adaptive object models를 보다 강력한 active data model로 간주한다.

adaptive object models 모델은 내장 DSL이다. 지금까지의 경험에 의하면, 이러한 모델은 한번 개발되어서 자리잡게 되면 개발자들이 모델에 익숙해져서 고도로 생산성 향상을 가져온다. 단점은 모델을 처음 접하는 이들에게는 상당히 어렵다는 것이다.

XML 구성 설정 파일

요즘에 수행되는 현대의 자바 프로젝트를 보면 자바보다 XML이 많이 쓰는 경우를 찾을 수 없다는 것을 알게 될 것이다. 자바 기반의 정보 시스템(Enterprise Java system)은 다수의 프레임워크를 갖게 되고, 이로 인해서 복잡한 XML 설정파일을 갖게 된다. 이러한 XML 파일은 본질적으로 DSL이다. XML은 임의로 형식을 정하는 것보다 가독성은 떨이지지만 파싱이 쉽다. 사람들은 괄호의 짝을 맞추느라 고생하는 개발자들을 위해 IDE의 플러그인을 만든다.

GUI 생성기(Builders)

사람들이 GUI를 만든 이래 거의 시스템의 GUI의 레이아웃을 드래그 앤 드롭으로 작성하는 경지에 다달았다. 대표적인 사례가 Visual Basic이라고 할 수 있지만, 나는 GUI가 익숙해지기 오래 전부터 문자 화면을 만들어내는 생성기를 사용해왔다. 이런 부류의 도구는 공개되지 않은 형식으로 레이아웃을 저장하고, 실행 환경에 맞는 코드를 생성하거나 생성된 코드에 필요한 모든 정보를 담으려고 한다. 비록 그것들이 시각적으로 뛰어나고 훌륭한 시연을 해보이긴 하지만, 이런 유형은 상호작용에 한계가 존재한다. 그래서, 경험많은 GUI 개발자들은 복잡한 애플리케이션에서는 GUI 생성기 사용을 꺼린다.

GUI 생성기는 일종의 DSL이다. 그러나, 편집하는데 있어, 우리가 익숙한 텍스트 기반 프로그래밍 언어와는 매우 다르다. 그래서, GUI 생성기를 통해 GUI를 만들어내는 이들은 그것을 프로그래밍 언어로 보지 않는다. (일부는 이것을 문제점으로 보기도 한다.)

논문 전체 보기

원문: Traditions of language oriented programming