특집기사:Xtext or EMFText

위클립스
이동: 둘러보기, 찾기

TMF 포럼에서, 던진 한 질문(EMFText가 Xtext에 비해 상대적으로 가지는 장점은 무엇인가?)이 꽤 의미 있는 전개가 되어, 이곳에도 소개합니다. 원문은 http://www.eclipse.org/forums/index.php/t/369792/에서 읽을 수 있습니다.

Notification.gif 이 논쟁은 아직 진행중입니다.

[편집] 지율

개인적으로 Xbase를 통한 JVM 통합과 그 쉬움 때문에 EMFText 보다 Xtext를 더 선호합니다.
그런데, EMF-text를 좋아하는 사람들의 의견도 좀 듣고 싶군요.

[편집] Hallvard Traetteberg

저는 주로 Xtext를 이용하지만, 몇 년 전 Java 소스 변환 프로젝트시 EMF-text를 사용했었습니다.
전반적으로 양쪽 모두 만족스러웠죠.

xtext에서 인상적인 부분은 툴링과 jvm 통합이 뛰어나다는 점입니다.
그러나 emftext는 미리 제공되는 완전한 Java 문법등을 통해 커다란 문법도 아주 잘 다루는 것 같습니다.(jamopp프로젝트)

보통의 경우 xtext를 사용하겠지만, 자바 문법이 필요한 경우라면(예를 들어 자바 코드 분석이나 변환같은), emftext를 사용할 겁니다.

[편집] Sven Efftinge (Xtend 리더, itemis)

안녕하세요, Hallvard.

> 그러나 emftext는 미리 제공되는 완전한 Java 문법등을 통해 커다란 문법도 아주 잘 다루는 것 같습니다.(jamopp프로젝트)

좀 구체적인 언급을 해 줄 수 있나요?
커다란 문법을 돌리면 문제가 있었나요?

[편집] Hallvard Traetteberg

제 문법은 그렇게 크지는 않았지만, Xbase와 연동할 경우, 종종 생성시 크기나 시간이 문제가 되었습니다.
특히, Xbase 문법이 확장된 경우에 더 그랬구요.

내가 다뤄본 문법과 모델중 가장 큰 건, EMFText 가 제공하는 자바 모델(JaMoPP 프로젝트)입니다,
모든 Java 5문법을 지원하므로, 상당히 큰 덩치이죠.

Xtext에서도 물론 가능하고 실용적일거라 생각합니다만,
제 경험에 비춰볼 때 시도하고 싶지는 않습니다.
도전해 보는 것은 어떨까요? ;-)

[편집] Sebastian Zarnekow (Xtext 부 아키텍트)

안녕하세요, Hallvard.

한 가지 언급해야 할만한게 있는데, Xtend 문법은 Java5랑 거의 같다는 거죠.
(배열을 지원하지 않는 대신 람다 문법을 지원하는 걸 빼고요)
그리고 아주 잘 작동합니다.

제 생각에 도전은 이미 받아들여졌고, 성취했다고 봅니다 :-)
이미 그런정도의 커버리지를 갖는 언어가 존재하는 이상
(예를 들어 스펙만 1000페이지가 넘는 PL/SQL 같은 언어)
문법이 너무 크다는 것이 Xtext에 문제가 될 것이라 생각하지 않습니다.

[편집] Marcus Munzert

전 메타 모델을 먼저 만들고, 문법을 개발하는 EMFText의 접근법이 더 좋습니다. (Xtext에서는 문법으로 부터 메타모델이 유도되죠)
아마도, 제가 문법 보다는 메타모델에 대해 더 깊게 고민하기 때문이 아닐까 합니다.

또한 EMFText나 Xtext에 비해 비교적 배우기 쉽다는 걸 배웠어요.
EMFText는 잘 정리된 문서들을 가지고 있고, Syntax-Zoo(100개의 문법 예제)를 통해 상당한 도움을 주죠.

이클립스 안에서나 밖에서나 생성된 DSL 파서를 쓰게 되었으니,
얼마나 쉽게 사용할 수 있느냐 하는 것은 선택에 큰 영향을 준다고 봅니다.
EMFText로 하는 건 쉬웠어요.

저흰 자체 코드 생성 프레임웍이 있어서 Xtend를 쓸 필요가 없었다는 점을 염두 해 주세요.
Xtend/Xbase나 JVM 통합등은 제 선택에 영향을 주는 요소가 아니었습니다.

[편집] Ed Merks

EMF의 신이라 언급되는 Ed Merks의 등장, 이 사람은 최근 Xtext를 이용하여 ecore 모델과 gen 모델을 동시에 DSL로 편집하고 실시간 코드 생성이 가능한 Xcore를 개발했다.

Marcus, 밑에 커멘트를 좀 남겼습니다.

> 전 메타 모델을 먼저 만들고, 문법을 개발하는 EMFText의 접근법이 더 좋습니다. (Xtext에서는 문법으로 부터 메타모델이 유도되죠)
> 아마도, 제가 문법 보다는 메타모델에 대해 더 깊게 고민하기 때문이 아닐까 합니다.

아닙니다. Xtext에서는 모델로 부터 그래마를 유도하고, 독립적으로 각자 개발 할 수 있어요.
물론 양방향 매핑을 관리해주어야 겠지만요.
아니면 시작부터 아예 분리해서 따로 개발할 수도 있습니다.
Xcore의 예에서 볼 때, 문법을 먼저 정의하고 ecore 모델을 유도할 수 있으며, 
그 둘을 분리해서 독립적으로 개발할 수 있습니다.

다시 말해, 취향이나 환경에 따라 선택할 수 있는 다양한 접근법이 있다는 거죠.
이미 존재하는 Ecore에 대해 문법을 정의할 때는 Ecore 자체를 수정하고 싶지 않겠지만,
새로운 모델을 개발 할 때, 전 Xcore를 선호합니다. 그리고 Ecore/GenModel 매핑을 정의하죠.
이런 경우, Xtext가 제공하는 프레임워크는 이상적입니다.
*.xcore 리소스 파일들은 ecore와 genmodel 인스턴스를 둘다 가지고 있는데, 이 둘은 xcore 존재조차 몰라도 되죠.

> 아마도, 제가 문법 보다는 메타모델에 대해 더 깊게 고민하기 때문이 아닐까 합니다.
>
> 또한 EMFText나 Xtext에 비해 비교적 배우기 쉽다는 걸 배웠어요.
> EMFText는 잘 정리된 문서들을 가지고 있고, Syntax-Zoo(100개의 문법 예제)를 통해 상당한 도움을 주죠.

좋은 문서는 방대한 유산입니다. Xtext는 정말 좋은 예제들이 있지만,
문서화는 필요한 만큼 이뤄져있지는 않죠.
이곳 뉴스 그룹에서 도움를 받는 것도 좋습니다.

> 이클립스 안에서나 밖에서나 생성된 DSL 파서를 쓰게 되었으니,
> 얼마나 쉽게 사용할 수 있느냐 하는 것은 선택에 큰 영향을 준다고 봅니다.
> EMFText로 하는 건 쉬웠어요.
> 
> 저흰 자체 코드 생성 프레임웍이 있어서 Xtend를 쓸 필요가 없었다는 점을 염두 해 주세요.
> Xtend/Xbase나 JVM 통합등은 제 선택에 영향을 주는 요소가 아니었습니다.

글쎄요, 많은 유저들에게 Xbase 처럼 인터프리팅과 JVM을 둘다 지원하는 임무는 
엄청난 투자가 아닐까요, Xbase 컴포넌트를 재사용하면 엄청난 효율성을 얻을 수 있어요.
제가 Xcore를 개발한 경험에 비춰볼 때, 이는 정말 재사용하기 좋게 잘 설계 되 있어요.

[편집] Hallvard Traetteberg

Sebastian 씨,

> 한 가지 언급해야 할만한게 있는데, Xtend 문법은 Java5랑 거의 같다는 거죠.
> (배열을 지원하지 않는 대신 람다 문법을 지원하는 걸 빼고요)
> 그리고 아주 잘 작동합니다.
> 
> 제 생각에 도전은 이미 받아들여졌고, 성취했다고 봅니다 :-)
> 이미 그런정도의 커버리지를 갖는 언어가 존재하는 이상
> (예를 들어 스펙만 1000페이지가 넘는 PL/SQL 같은 언어)
> 문법이 너무 크다는 것이 Xtext에 문제가 될 것이라 생각하지 않습니다.

제가 문법의 전문가는 아니지만, 복잡도(파싱 룰간의 상호 작용)와 크기(파싱 룰의 개수)를 구분하는 것은
중요하다고 생각합니다. 제 이야기는 룰의 갯수가 일으키는 문제에 대한 것이아니라, 상호작용에 관한 이야기입니다.
이따금 문법의 단순한 변경이 문제를 제거하거나 새로 만들어내는데, 그게 왜 그런지 알기가 상당히 어려워요.
(파서 처럼 생각하면서 깊숙히 조사하기 전까지는 말이죠)

Java와 다른 Xtend의 몇몇 문법들을 보면, 이따금 그들이 사용 편의성 때문이 아니라,
파서의 기술적인 문제를 우회하기 위한게 아닌가 하는 의구심이 듭니다:
 - 클래스에 대한 레퍼런스: typeof(class)
 - 캐스팅시 'as' 키워드를 사용하는 것
 - 정적 래퍼런싱에 ::를 키워드로 쓰는 것
 - val, def

[편집] Sven Efftinge

> 제가 문법의 전문가는 아니지만, 복잡도(파싱 룰간의 상호 작용)와 크기(파싱 룰의 개수)를 구분하는 것은
> 중요하다고 생각합니다. 제 이야기는 룰의 갯수가 일으키는 문제에 대한 것이아니라, 상호작용에 관한 이야기입니다.
> 이따금 문법의 단순한 변경이 문제를 제거하거나 새로 만들어내는데, 그게 왜 그런지 알기가 상당히 어려워요.
> (파서 처럼 생각하면서 깊숙히 조사하기 전까지는 말이죠)

렉싱과 파싱이 어떻게 일어나는지 확실히 알고 있어야 합니다.
그리고 하부 파싱 기술에 의한 제약과 기능도 알아둬야 하죠(예: ANTLR)

> Java와 다른 Xtend의 몇몇 문법들을 보면, 이따금 그들이 사용 편의성 때문이 아니라,
> 파서의 기술적인 문제를 우회하기 위한게 아닌가 하는 의구심이 듭니다.

맞아요, 우리는 Xbase를 구현하면서 몇몇 복잡한 문제를 우회했습니다.
하지만, 이 문제를 해결할 수 없어서 그런 것이 아니라, 
다른 사람들이 자신의 언어에 Xbase를 쉽게 확장하고 사용할 수 있도록 하기 위함이었어요.

예를 들어 네임스페이스를 구분할 때 "."을 쓴다면 (예: 정적 피쳐 호출시)
자바 유저에겐 상당히 친숙하겠지만, 언어 디자이너의 입장에서 그 지점에서 무슨일이 벌어지는지
이해하는 것은 매우 어렵고 복잡해집니다. 왜냐하면, 문법적으로 아무런 차이가 없기 때문이죠.
따라서, 같은 구조를 동일한 형태로 파싱 한 뒤, 나중에 세만틱스 분석을 통해 결정해야만 하죠.

이런 문제가 Xtext 기반 언어의 문법이 커지는데 뭔가 영향을 준다고 생각하지 않습니다.
이는 단지 Xtext가 기반한 파싱 기술의 환경상의 제약일 뿐이죠.

[편집] Sven Efftinge

> 전 메타 모델을 먼저 만들고, 문법을 개발하는 EMFText의 접근법이 더 좋습니다. (Xtext에서는 문법으로 부터 메타모델이 유도되죠)
> 아마도, 제가 문법 보다는 메타모델에 대해 더 깊게 고민하기 때문이 아닐까 합니다.

이는 단순하게 사실이 아니에요.
Xtext 는 모델을 임포트 할 수도 있고, 생성할 수도 있습니다.

문법으로 부터 유도된 ecore 파일을 쓰는 것은 개발 초기에 매우 편리한 기능이죠.

> 또한 EMFText나 Xtext에 비해 비교적 배우기 쉽다는 걸 배웠어요.
> EMFText는 잘 정리된 문서들을 가지고 있고, Syntax-Zoo(100개의 문법 예제)를 통해 상당한 도움을 주죠.

40 페이지의 문서보다는 400페이지의 문서가 나아 보인다는 건 이해합니다.
Xtext는 유용한 문서들을 제공하지만, 심화된 주제에 대한 것은 별로 없죠.
예를 들어 전체 자바 통합이나, 네임스페이스 인덱싱 같은 것들요.
네, 이것들에 대해 좀 공부해야 할 겁니다, 그러나 그럴만한 가치가 있어요.

> 이클립스 안에서나 밖에서나 생성된 DSL 파서를 쓰게 되었으니,
> 얼마나 쉽게 사용할 수 있느냐 하는 것은 선택에 큰 영향을 준다고 봅니다.
> EMFText로 하는 건 쉬웠어요.

Xtext에서 이클립스 바깥쪽의 파일을 파싱하는 코드는 두줄 밖에 안됩니다.
EMFResource API를 쓴다면, 사실 Xtext API는 뒤져볼 필요도 없어요.

> 저흰 자체 코드 생성 프레임웍이 있어서 Xtend를 쓸 필요가 없었다는 점을 염두 해 주세요.

Xtend는 언어이지 프레임워크가 아닙니다. Xtext를 쓸 때에도, 
어떤 기술이든 코드를 생성하는데 사용할 수 있습니다.
그러니, Xtend를 사용하는 것은 옵션일 뿐이에요. (쓰는게 좋은 아이디어죠)

> Xtend/Xbase나 JVM 통합등은 제 선택에 영향을 주는 요소가 아니었습니다.

Xbase는 코드 생성에 있어 관여하지 않습니다.
Xbase는 단지 다른 DSL언어에 임베드 될 수 있는 표현 언어이며,
자바와 통합할 수 있는 수단을 제공하죠.
7 언어 예제들을 보면 좀 알 수 있을거에요.

당신이 Xtext에 대해 언급한 모든 부정적인 견해로 볼 때,
당신은 잘 알고 있다는 이유만으로 EMF-Text를 좋아하는 것 같군요.
그게 나쁘다는 것은 아니지만, 어드바이스로는 좋지 않은 것 같습니다.

[편집] Hallvard Traetteberg

Sven씨,

EMF나 Xtext, Xtend Xbase를 어떻게 잘 조합하는지 이해하려면,
상당한 시간이 걸리는 것 같습니다. 
그리고 각각만 바라 볼경우 혼동될 수 있어요.

예를 들어 Xtend는 진보된 자바 언어로 언급되지만, 코드 생성에 적합한 언어로 언급되기도 하죠.
특히나 Xtext에서 사용되거나 Xbase와 함께 사용되는 경우 더 혼란스럽습니다.
그래서 이게 뭐지? 범용 언어 아니면 코드 생성 프레임워크?
물론 두가지 용도로 다 사용할 수 있지만, 사용해보기 전까지 이는 매우 혼란스럽게 만들어요.

내일 저는 버클리 대학의 그룹에서 Xtext관련 내용을 프리젠테이션 할 겁니다.
그들이 한 질문들에서 인상적인 점 중 하나는, 그들도 이 문제를 혼동하고 있다는 거였어요.
그들을 매우 명석한 사람들인데도 말이죠, 하지만 제한된 시간안에 여기 저기서 쓰일 수 있는 기술을 이해하기란 쉽지 않죠.

알고 있는 기술을 사용하고 신뢰하는 것은 자연스러운 현상이며, 그냥 자신이 원하는 일을 해주는 걸 쓰는거죠.


[편집] Sven Efftinge

> EMF나 Xtext, Xtend Xbase를 어떻게 잘 조합하는지 이해하려면,
> 상당한 시간이 걸리는 것 같습니다. 
> 그리고 각각만 바라 볼경우 혼동될 수 있어요.
> 
> 예를 들어 Xtend는 진보된 자바 언어로 언급되지만, 코드 생성에 적합한 언어로 언급되기도 하죠.
> 특히나 Xtext에서 사용되거나 Xbase와 함께 사용되는 경우 더 혼란스럽습니다.
> 그래서 이게 뭐지? 범용 언어 아니면 코드 생성 프레임워크?

코드 생성 프레임워크가 존재하는 주된 이유는 자바가 문자열을 조합하는데 매우 부적합하기 때문이죠.

Xtend는 범용 언어지만, 문자열을 조합하는데도 매우 적합합니다. (예: 코드 생성)

> 물론 두가지 용도로 다 사용할 수 있지만, 사용해보기 전까지 이는 매우 혼란스럽게 만들어요.

네, 좀 혼란스러운 걸 이해할 수 있습니다.
모델링 커뮤니티의 많은 사람들이 각기 다른 작업들에 대해 고유 언어들을 이용합니다.
(M2M, M2T, Validation, 등등) 이들 모두 DSL의 아이디어를 충실하게 지원한다고 보입니다.

그러나 제 경험으론 명확한 구분이 항상 충분한 가치가 제공되는 일인 것은 아닌 것 같습니다.
실제론 오히려 반대로 그러한 구분 때문에, 과거의 Xpand/Xtend/Check 시절 이는 수많은 제약을 가지고 있었죠.
예를 들어, 앞서 언급한 작업중 하나를 수행하는 작고 단순한 로컬 함수 하나만 추가 하고 싶은 경우가 있잖아요.

또한 모델 변환이나 코드 생성은 종종 함께 쓰이기도 하죠. 
Xbase의 모델 추론기는 메소드의 형태는 변환을 통해 모델로 만들지만,
메소드 내부는 생성된 문자열을 이용하죠.

[편집] Marcus Munzert

오류를 지적하고 명확하게 해줘 고맙습니다, Sven.

"네, 이것들에 대해 좀 공부해야 할 겁니다, 그러나 그럴만한 가치가 있어요." 라고 당신이 말한 것 처럼,
EMFText와 Xtext의 차이점을 모두 접근하고, Xtext의 진가를 인정할 만큼 
제가 충분히 알고 있지 않은 것은 명백한 것 같네요.

근데 지율은 "하지만 난 EMF-text를 좋아하는 사람들의 의견을 듣고 싶어요" 라고 말했고,
제가 이야기한 건 그 맥락상의 하나의 의견입니다.
저는 일반적으로 EMFtext가 Xtext보다 좋다던가, Xtext가 EMFText보다 좋다던가 하는 입장이 아닙니다.

사실 모든게 가능한 것인지 확신 할 수는 없지만,
제게 필요한 내용은 EMFText가 제공하고, 배우기도 쉽고 잘 돌아가서,
그걸 계속 그냥 쓰기로 결정했습니다.

우리 코드 생성 프레임웍은 EMFText에 디펜던시가 없습니다.
Xtext에 연결해서도 사용할수 있죠.
그리고 우리 클라우드 기반의 소스 생성 플랫폼 "Virtual Developer"는 
Xtext 기반의 DSL 에디터로 만든 모델을 입력으로 받습니다.

이 기사에 대한 의견은 토론 페이지를 통해 나눌 수 있습니다.

개인 도구
이름공간
변수
행위
포탈
탐색
도움
도구모음