[실용주의 프로그래머] 도메인 언어

[실용주의 프로그래머] 도메인 언어

-

언어의 한계가 곧 자기 세계의 한계다 - 루트비히 비트겐슈타인

-

컴퓨터 언어는 여러분이 문제에 대해 생각하는 방식과 의사소통에 대해서 생각하는 방식에 영향을 미친다. 모든 언어에는 그 언어의 특징들의 목록이 딸려온다.

특징들은 모두 어떤 해결 방안들을 제시할 수도 있지만 가려버리기도 한다.

-

우리는 언제나 앱 도메인의 어휘를 사용해서 코드를 작성하려고 노력한다.

몇몇 경우, 한 차원 더 나아가서 실제로 그 도메인의 어휘, 문법, 의미론(즉 언어)을 사용해서 프로그래밍하는 일이 가능할 때도 있다.

-

사용자들이 정리가 잘 된 진술을 많이 해준다면, 여러분은 그들이 원하는 내용을 정확히 표현하는, 그 앱 도메인에 맞추어진 소형 언어(mini-language)를 만들 수 있다.

ex)

From X25LINE1 (Format=ABC123){

    Put TELSTAR1 (Format=XYZ43B);

    Store DB;

}

-

소형 언어가 꼭 실행가능할 필요는 없다. 처음에는 단지 사용자의 요구사항을 잡아내는 한 가지 방법, 즉 명세로만 쓰여도 된다.

하지만 한 걸음 더 나아가서 실제로 이 언어를 구현하는 것은 어떨지 생각해 볼 수도 있다. 명세가 실행가능한 코드가 되는 것이다.

-

문제 도메인에 가깝게 프로그래밍하라.

소형 언어를 구현하기

-

가장 간단하게 소형 언어를 구현하는 방법은, 파싱하기 쉬운 라인 중심(line-oriented)형식의 언어로 만드는 것이다.

더 엄밀한 문법을 지닌 복잡한 언어를 구현할 수도 있다. 여기서 비결은 BNF 와 같은 표기법을 사용해서 문법을 먼저 정의하는 것이다.

-

소형 언어를 구현하는 다른 방법도 있다. 기존의 것을 확장하는 것이다.

데이터 언어와 명령형 언어

-

데이터 언어(Data language)는 앱이 사용할 어떤 형식의 데이터 구조를 만든다.

이런 언어는 환경설정 정보를 표현하기 위해 쓰이는 경우가 많다.

-

명령형 언어(Imperative language)는 실제로 실행되며, 문장, 제어 구조체(control construct)등등을 가질 수 있다.

독립 언어와 내장 언어

-

반드시 앱에 직접 사용되어야만 소형 언어가 유용한 것은 아니다. 많은 경우 우리는 컴파일하거나, 읽어들이거나, 그렇지 않은 경우 프로그램 자체가 사용하기 위한 산출물을 만들기 위해 명세 언어(specification language) 를 사용하기도 한다.

( ex) 스키마 명세를 통해 sql, c, xml 등등을 생성하고, 앱이 이것을 사용 )

쉬운 개발 아니면 쉬운 유지보수?

-

복잡한 문법을 구현하는 것은 노력이 더 필요한 일인데, 그것을 선택하는 이유는 뭘까?

복잡한 문법에 대한 트레이드오프 대상은 확장가능성과 유지보수다.

‘진짜’ 언어를 파싱하는 코드는 작성하기는 힘들지만, 사람들이 그 언어를 이해하기는 훨씬 쉬우며, 나중에 새로운 특징이나 기능을 추가해 확장하기도 훨씬 쉽다.

-

대부분의 앱이 예상 수명보다 더 오래간다는 사실에 비추어 볼 때, 현재의 고통을 참고 더 복잡하지만 가독성 좋은 언어를 채택하는 편이 더 좋을 것이다.

최초의 노력은 자원과 유지보수 비용의 절감을 통해 몇 배로 보상받게 될 것이다.

BNF, bnf 표기법, Control statement, data language, imperative language, Mini language, specification language, [실용주의 프로그래머] 도메인 언어, 내장 언어, 데이터 언어, 도메인 언어, 독립 언어, 라인 중심 언어, 명령형 언어, 명세 언어, 문제 도메인에 가깝게 프로그래밍하라, 소형 언어, 소형 언어 구현하기, 소형 언어 명세, 쉬운 개발, 쉬운 유지보수, 실용주의 프로그래머, 언어의 한계