나만의 프로그래밍 언어를 만드는 것이 합리적입니까?

장기적으로 내 언어를 만드는 것이 더 나은 킬러 응용 프로그램 유형, 알고리즘 문제 클래스 등이 있습니까?

추신 : 확실히, 기존 언어의 새로운 컴파일러가 아닌 새로운 프로그래밍 언어와 컴파일러를 의미합니다.

편집 : 답변 주셔서 감사합니다. DSL을 만드는 것이 절대적으로 불필요하거나 DSL이 좋은 아이디어 일 수있는 몇 가지 예를 제공 할 수 있습니까?

교육 목적으로 자신의 언어를 쓰는 것은 확실히 관련이 있습니다. 프로그래밍 언어 설계 및 컴파일러 설계에 대해 학습합니다. 그러나 실제 용도는 거의 없습니다.

자신의 언어를 쓰면 다음과 같습니다.

• 문제에 엄청난 양의 복잡성을 추가
• 새로운 언어와 컴파일러를 작성하고 유지하는 데 상당한 양의 작업 추가

따라서 프로젝트에 자신의 언어를 작성하려는 경우 다른 언어가 제공하는 기능으로 위의 비용을 상쇄 할 필요가 없습니다.

게임 개발을 예로 들어 보자. 그들은 종종 게임이나 스크립팅 언어 내에서 미니 언어가 필요합니다. 그들은 이러한 언어를 사용하여 발생하는 엄청난 양의 게임 내 이벤트를 스크립트합니다. 그러나이 경우에도 거의 항상 기존 스크립팅 언어를 선택하고 필요에 맞게 조정합니다.

VB 컴파일러의 전 수석 개발자이자 프로젝트 오슬로와 M 언어로 작업하는 Paul Vick을 인용하겠습니다.

새로운 언어, 심지어 기존 언어를 기반으로하는 언어를 구축하는 것은 마음이 구부리고, 엄청나게 어렵습니다. 그러나 많은 프로그래머는 "이봐, 생각 난 과에 가서 얼마나 열심히이?가 될 수 언어를 사용하는". … 아마도 그들 중 98 % 이상이 전혀 견인력을 얻지 못하지만 낙관론자들에게 신의 축복을 빕니다. 나는 개인적으로 C #과 Java, Ruby, Python 등과 같은 언어를 얻을 수 있도록 언어를 낭비하지 않고 수백만 달러와 시간을 희생하려고합니다.

따라서 새로운 언어를 고안하는 것이 나쁜 아이디어라는 사실은 사람들이 새로운 DSL을 개발하는 것을 설득해서는 안되며, 잠시 멈추고 희망적으로 약간의 겸손을 주어야합니다. 열쇠는 작게 시작하고 작게 유지하는 것입니다.

DSL : 확실히 나쁜 생각입니다!

언제 합리적입니까?

당신이 그것을 느낄 때!

기본적으로 다음과 같이 말끔한 의견을 가진 사람들의 말을 듣지 마십시오.

"너무 어렵고 X 언어가 다른 언어보다 낫기 때문에 그렇게하지 마십시오."

문제는 항상 DSL을 만드는 것입니다. 프레임 워크는 DSL입니다. 매크로는 DSL입니다. 프로그램에 대한 기능을 작성할 때마다 DSL의 일부입니다. 물론 문법의 범위 안에 있지만 어휘는 언어의 일부입니다. 그렇기 때문에 업계에서 종종 고유 한 언어를 만드는 것이 더 효율적입니다!

"하지 마라"가 정답이라면, 우리는 모두 COBOL과 Fortran을 쓸 것입니다.

자신의 언어를 쓸 생각이라면 Martin Fowler의 다가오는 DSL 서적의 일부를 읽으십시오 .

나는 엄청난 학습 경험이 아닌 언어를 처음부터 새로 만드는 비즈니스 사례를 생각할 수 없습니다.

편집 : DSL의 경우 많은 비즈니스 사례가 있지만 여기서 핵심은 옮기지 않고 단순하게 유지하는 것입니다.

중요한 질문은 "어떤 문제를 해결하려고합니까?"입니다. "누가 ROI를 얻습니까?"

자신 만의 기술과 경험을 쌓으려고한다면, 다른 사람의 문제를 해결해야하는 프로덕션 시스템에서는 전속력으로 발전 할 수 있습니다.

새로운 언어를 원하는 주된 이유는 코드에서 기존 언어가 제대로 처리하지 못하는 패턴을 발견하기 시작한 것 같습니다. 그러나 자신의 언어를 만드는 데는 많은 문제가 있습니다. 기존 언어 용으로 구축 된 모든 라이브러리와 프레임 워크를 놓치게됩니다. 새로운 언어를 디자인하고 구현하는 데 많은 시간을 할애하는데, 이는 실제 프로그래밍 작업에 소비 할 필요가없는 시간입니다. 다른 개발자가 자신의 언어를 사용해야한다고 설득하기 위해 많은 노력을 기울일 것입니다. 그리고 새로운 개발자를 모집하고 훈련하는 데 어려움을 겪을 것입니다.

새로운 패턴을 발견 할 때 언어를 확장 할 수있는 Lisp와 같은 언어로 작성해보십시오. 그런 다음, 확립 된 언어의 모든 이점과 함께 새로운 언어의 모든 기능을 활용할 수 있습니다.

한 가지 이유는 언어 설계 및 컴파일러 작성에 대해 배우기위한 실험으로 작성하는 것입니다.

다른 이유는 타사 API를 추가 할 수있는 옵션이 없을 때 응용 프로그램에 스크립팅 언어를 구축하는 것입니다.

나는 당신 이 새로운 언어 를 만들지 않고 프로그래밍 할 수 있다고 생각하지 않기 때문에 그것이 당신이하고있는 일을 깨닫고 문제를 이해하는 것이 좋습니다.

• 언어 란 무엇입니까?
  어휘, 구문 및 의미.

VB, Java, C # 등과 같은 상용 언어는 기본 언어 일뿐 입니다. 클래스, 메소드 등을 추가하자마자 어휘와 의미가 추가되었습니다. 구문 분석 및 번역, 구문 분석 및 해석, 기존 언어 위에 매크로, 기존 언어에 클래스 및 메소드 추가 등의 언어를 구현하는 방법에는 여러 가지가 있습니다.

• 언어는 무엇을 원하십니까?
  간결하게 문제를 표현하는 데 좋습니다.

이 작업을 수행했는지 어떻게 알 수 있습니까? 내가 사용하는 측정 값은 edit count 입니다. 한 문장 요구 사항 A가 나오면 요구 사항을 코드로 구현합니다. 모든 버그가 해결되면 코드를 체크인하고 코드 리포지토리에서 변경 사항 목록을 제공합니다. B. B가 작을수록 언어가 더 좋습니다. 실제 및 가능한 요구 사항의 공간에 대한 평균을 측정하면 해당 언어의 "도메인 별"방법을 알려줍니다.

• 간결함이 좋은 이유는 무엇입니까?
  버그를 최소화하기 때문입니다.

N 코드를 변경하여 1 요구 사항을 구현하고 때로는 실수를 저지르는 경우 도입하는 버그 수는 N에 대략 비례합니다. N = 1 인 한계에서는 시도하지 않고 버그를 도입하는 것이 거의 불가능 합니다.

이것은 오늘날 우리가 보는 "코드 팽창"에 직접적인 도전입니다.

추가 : 예제 요청에 대한 응답으로 차등 실행을 참조하십시오 . 나는 그것을 빨리 이해할 수 있다고 말하지는 않지만 UI 코드를 크게 줄입니다.

(원래의) 질문에 단어를 사용하는 것은 항상 "실행 가능"하지만 존재하는 잘 지원되고 성숙한 언어와 프레임 워크가 풍부하기 때문에 유용하지 않으며 거의 ​​최적이 아닙니다.

그러나 흥미로운 지적 도전입니다.

팀의 핵심 비즈니스가 프로그래밍 언어 인 경우에만 가능합니다.

저는 금융 회사에서 만든 프로그래밍 언어를 연구했습니다.

분명히 건축가 자신에게는 이것이 큰 도전이었고 자신의 기술을 향상 시켰습니다.

필연적으로 C #이나 Java와 같은 수준에서 언어가 성장하거나 향상 될 수 없었습니다.

새로운 사람이 다른 사람의 애완 동물 프로젝트를 개선하려는 임무를 수행하기를 원하지 않았기 때문에 언어는 곧 정체되었습니다.

원래 건축가는 떠났다. 그 언어는 10 년 후에 시들고 죽었다.

그 10 년은 불운을 겪은 사람은 막 다른 언어로 일하는 것에 대해 지옥이었습니다.

자, 자신의 언어를 만드십시오. 그러나 다른 사람에게 실제로 사용하도록 요청하지 마십시오. 다른 사람이 당신에게 감사를 기대하지 마십시오.

언어를 디자인하는 것은 재미있을 수 있습니다. 그러나 프로그래밍 언어로 자신을 제한 할 필요는 없습니다.

적당히 복잡한 응용 프로그램을 작성하는 경우 복잡한 반복 작업을 쉽게 수행 할 수 있도록 일종의 매크로 / 스크립트 언어를 추가하고 싶습니다. 대부분의 사용자는이 기능을 사용하지 않지만 사용하는 소수는 매우 감사합니다. 또한 지원 담당자가 고객 문제를 해결하는 데 도움을주는 것이 가치가 있는지 확인합니다.

당신의 기술을 확장하고 배우기 위해 행해지면 완전히 합리적입니다.

그 외에는, 질문을해야한다면 그렇지 않습니다. 기존 언어보다 특정 클래스의 알고리즘 또는 특정 문제 도메인을 처리 할 수 ​​있는지 여부를 파악하려는 경우 먼저 해결하려는 분야의 전문가 여야합니다. 당신은 당신의 기술과 경험이 그렇게 말할 때 그것이 적절하다는 것을 알게 될 것입니다.

그리고 당신도 그것에 대해 틀릴 수 있지만, 당신을 설득하기 위해 (또는 당신이 당신이 생각하는 전문가가 아니라는 것을 보여주기 위해) 다른 전문가가 필요할 것입니다. 여기에서 찾을 수있는 단순한 Q-A가 아닌 활발한 토론.

자기 교육적 목적을 제외하고는 현재 자신의 언어를 만들 필요가 없다고 주장하고 싶습니다 . 어떤 상황에서도. 이제까지. 당신이하고 싶은 것에 관계없이, 당신이 필요로하거나 적응할 수있는 기존 언어의 보트가 있습니다.

상황에 따라 결정됩니다. nosklo가 말했듯이-좋은 아이디어가 있다면 새로운 개념이나 그와 비슷한 것이 좋습니다.

일반적으로 저는 확립 된 기술에 의존 할 것을 제안합니다.

그러나 자신 만의 "언어"를 만들고 싶다면 YACC & Lex를 확인하십시오.

반 패턴 "사각 바퀴 재생성"에 빠지지 마십시오.

이미 수행 한 것을 다시 작성한다는 것을 의미합니다. 원본보다 나쁩니다.

Wouter는 새로운 아이디어를위한 새로운 언어를 만드는 것으로 유명했습니다. 그의 작품에서 영감을 얻을 수 있습니다 : Wouter의 프로그래밍 언어 페이지 .

자신의 언어를 언제 만들 수 있습니까?

당신이 원할 때, 큰 취미 프로젝트로.

도메인 별 언어 이것들은 매우 정교 할 수 있습니다. 아카이브 를 확인하여 대화 형 소설 (또는 텍스트 어드벤처) 커뮤니티에서 진행되는 작업을 살펴보십시오 .

목표가 매우 야심적 일 때 Paul Graham의 Arc 프로젝트 처럼 실제 발전을 이룰 수 있다고 생각할 때 .

또한 저수준 구조를 개발하는 과정에서 충분히 적응 가능한 언어 (아마도 C ++, 분명히 일반적인 Lisp)로.

당신이 원하는 것처럼 피할 때, 전염병처럼 피하는 것과 같은 진부한 피하기를 바랍니다.

실제 프로젝트를위한 지속적인 개발의 기초가 될 때. 싸구려 상용 제품보다 항상 뒤 떨어질 것이며, 더 많은 개발을 방해 할 것입니다. 나는 자신의 COBOL 버전을 가진 회사에서 일했고 자신의 언어를 유지하는 다른 회사에서 일하고 싶지 않습니다. 우리는 다른 버전의 COBOL이 더 나은 기능과 더 나은 도구를 얻는 것을 보았지만 동일한 문제가 발생했습니다. (나는 다시 COBOL과 함께 일하고 싶지 않지만 또 다른 이야기입니다.)

자신의 언어를 만들 수있는 상황은 여기에 해당되지 않습니다. 취미 프로젝트는 실제 개발에 사용되지 않습니다. Arc와 같은 것은 성공할 것이고 (다수의 구현과 발전과 발전을 얻음) 실패 할 것입니다 (아무도 그것을 사용하지 않을 것입니다). 작은 도메인 별 언어는 프로젝트의 일부일 뿐이며, 규모가 작기 때문에 시간이 지남에 따라 향상 될 수 있습니다. 텍스트 어드벤처 언어는 개별 게임을 작성하는 데 사용되며, 취미 게임 일뿐 아니라 이러한 게임은 개발을 계속하는 데 거의 사용되지 않습니다.

저의 관점은 DSL은 일반적으로 "약한 아이디어"이며, 장기적으로 표준 언어를 사용하고 "비 -DSL"라이브러리로 도메인 별 요구를 구축하는 것이 더 생산적이라는 것입니다.

그러나 회사에 DSL (약간 수정 된 gcc 또는 lisp 구현이 아닌)을 사용하는 것이 바람직 할 정도로 사용자 요구가 충분히 사용자 정의 된 것으로 판명 될 수 있습니다. 많은 회사들이 자신의 언어를 작성 / 유지하지 않고 현재하고있는 일을 목표로하는 현재 언어의 드롭 인을 사용합니다. 예를 들어, PHP에 좋은 기능이 있다고 들었습니다. Lua는 드롭 인 방식으로 설계되었으며 ModelView는 Python을 사용하고 AutoCAD는 AutoLISP를 스크립터로 사용합니다.

기존 도구를 활용할 수 있다면 자신의 프로그래밍 언어를 작성하는 데 아무런 문제가 없습니다. 오늘날 세계에서 이는 기존 언어 (Java 또는 C #)에 사용할 수있는 구문으로 정의하거나 기존 언어로 코드를 생성하는 작은 변환 시스템 (매크로 확장기)을 작성한다는 의미입니다.

기계 코드로가는 길은 많은 바퀴를 재창조하고 있습니다 ...

DSL에 대한 아주 좋은 이유는 간결한 방식으로 도메인 데이터를 표현하기위한 것입니다. 이를 통해 도메인 전문가는 다른 전문가를 거치지 않고 직접 데이터를 처리 할 수 ​​있습니다. 그런 다음 트릭은 결과 프로그램을 처리하기 쉬운 형태로 만드는 것입니다.

일반적으로 대답은 큰 NO입니다. 수백 개의 언어 중 일반적으로 문제에 맞는 언어가 있습니다.

그러나 새로운 언어를 개발하는 것이 합리적 옵션 인 상황이 있습니다.

• 경쟁 업체 중 하나가 이제 주요 개발 플랫폼 중 하나를 소유 한 경우 저는 현재 구글이 자바에 의존하고 있으며 "go"개발에 대해 생각하고 있습니다.
• 새로운 플랫폼을 위해 많은 코드를 작성해야하는데 기존 언어가 장황하고 오류가 발생하기 쉽습니다 (예 : 웹 개발 용 PHP).
• 스칼라와 같은 어느 정도의 데이터를 처리 할 하드웨어가 없었기 때문에, 이전에는 없었던 규모와 병렬성의 문제에 직면했을 때 (예 : GO).

언어가 좋은 것은 구성 성 또는 동일한 구성 요소를 다른 방식으로 구성하는 것입니다.

도메인 문제로 여러 직교 스위치를 설정 해야하는 경우 언어는 양식, 그래픽 UI 또는 직선 텍스트 구성보다 많은 것을 추가하지 않을 것입니다. 파일. (여기서는 키, 값 쌍으로 가득 찬 파일 이 "언어"의 의미 가 아니라고 가정합니다 .)

구성이 실제 언어와 같은 경우 OTOH. 동사와 명사를 복잡성에 관계없이 여러 가지 (그리고 새로운) 조합으로 묶을 수 있습니다. 그러면 다른 방법으로 원하는 것을 지정하려고 시도하는 조합 폭발이 압도적이므로 언어는 거의 불가피해질 것입니다.

학습 연습을 제외하고, 다른 언어, 특정 문제 도메인 및 기존 언어가 해당 문제 도메인을 해결하는 방식을 이해 하고 새로운 언어가 합리적 이라는 것을 알기에 충분히 이해하는 경우에만 고유 한 프로그래밍 언어를 작성하는 것이 합리적입니다. 질문 할 필요없이 해결책.

마지막으로 취미 프로젝트에서 시작했을 때 나는 구문이 어떻게 보이고 싶었는지 명시하기 시작했고 프롤로그를 재발견했습니다. 언어를 발명해야 할 때 적합 할 수있는 다른 언어는 lisp, lua 또는 Haskell과 같은 언어입니다. 기본적으로 대학에서 무시한 모든 언어는 유용하지 않을 것이라고 생각했기 때문에.

한 가지 이유는 이미 언급 한 바와 같이 교육 목적입니다. 그러나 더 있습니다. 예를 들어, 같은 많은 연구 언어가 Sing#상의 특이점 운영 체제와 BitC의 Coyotos 기존의 언어 (언어 수준에 인스턴스 검증을 위해) 필요한 기능을 제공하지 않기 때문에 설계되었습니다.

Tom Van Cutsem은 최근이 질문에 대한 에세이 답변을 썼습니다.

http://soft.vub.ac.be/~tvcutsem/whypls.html

글 머리 기호 요약 (해당 페이지에서) :

• 구문 추상화 메커니즘으로서의 언어 : 다른 언어의 내장 추상화 메커니즘을 사용하여 추상화 할 수없는 반복적 인 "boilerplate"코드를 줄이기 위해.
• 사고 셰이퍼로서의 언어 : 소프트웨어를 어떻게 구성해야하는지에 대한 패러다임 전환을 유도합니다 ( "최소 저항 경로"변경).
• 단순화하는 언어 : 기존 패러다임을 필수 부분으로 정리하고 이해와 통찰력을 높이는 경우가 많습니다.
• 법 집행 기관으로서의 언어 : 중요한 속성이나 변형을 강제하고 프로그램에서보다 유용한 속성을 쉽게 추론 할 수 있습니다.

아마 절대.

Lua는 기본적으로 다른 언어로 언어를 포함하려는 경우 얻을 수있는 최선의 선택입니다.

Small Domain Specifc 언어는 현재 사용되고 있으며 일부 응용 프로그램에서는 의미가 있습니다.

그 이외의 이유는 주로 학문적입니다.

필요하지 않을 때 언어를 만드는 것은 언어를 개발하고 유지 관리하는 데 따르는 복잡성 때문에 실제로 나쁜 일입니다. 나는 그 프로그램에만 특정한 종류의 스크립팅 언어를 소개하는 많은 프로젝트를 보았고, 기본 개발을 크게 늦추는 것이 었습니다. 좋은 예는 Phantom, AutoHotKey, AutoIt과 같은 자동화 언어입니다. Lua와 같은 잘 알려진 제방 언어를 사용하면 이러한 도구가 IMO보다 훨씬 나을 것입니다.

귀하의 '편집'은 실질적으로 다른 질문 인 것 같습니다 ( "사람들이 새로운 범용 프로그래밍 언어를 작성해야 할 때"로 사람들이 이해 한 원래 질문보다는 "DSL을 작성해야합니까?"). 사람들이 '원래'질문에 철저히 대답 한 것 같지만 DSL 사용시기에 대한 특정 기준을 제공하는 답변은 거의 없습니다. 그래서 나는 체크리스트를 제안한다 :

1. 귀하의 사용자 기반은 일반적으로 비 기술적이거나 시스템 액세스가 제한된 소수의 사람들보다 큽니다 (따라서 기존 범용 언어를 배우고 사용하기를 기대하는 것은 합리적이지 않습니다). 개발자 팀이나 소프트웨어 조직 내에 있으면 "스크립트 만 작성하십시오"라고 말할 수 있습니다.
2. 사용자는 충분히 다양하고 변화하는 행동이 필요한만큼 자주 사용해야합니다 (예 : 사용자가 유지 관리하는 고정 된 기능 라이브러리 만 제공 할 수는 없음)
3. 사용자가 지정할 수있는 동작은 데이터로 지정하기에는 너무 복잡합니다 (예 : 데이터베이스 테이블, 사용자 입력 매트릭스, 작업 목록 또는 키-값 수집을 사용하여이를 달성 할 수 없음 ... 신중하게 생각하십시오. 이것으로 많은 복잡성을 달성 할 수 있기 때문에). DSL 대신 데이터 입력 또는 구성을 사용하여 동작을 수행 할 수 있다면 작업이 훨씬 줄어들 기 때문일 것입니다. 어떤 종류의 조건부, 조합 성 / 함께 체인화 또는 몇 가지 다른 추상화를 모델링하면 필요한 동작이 일반 데이터 / 구성에 너무 복잡하다는 신호일 수 있습니다.
4. 그러나 동작은 간결한 DSL로 지정할 수있을 정도로 여전히 제한되어 있습니다. 큰 위험은 '플랫폼 팽창'입니다. 예를 들어 사용자가 "추가 할 수 있습니까?" 인터넷에 연결하거나 파일 시스템에서 읽고 쓰거나 프로세스를 열고 닫아야하는 경우 더 이상 DSL이 아닙니다. (실제로이 문제가 발생하는 것을 보았습니다 ... 사용자는 작은 파이썬 호출을 포함하고 점차적으로 파이썬 스크립트로 커지고 결국 한계 / 모듈 / 성능을 파괴 할 수 있습니다)

이 모든 것이 사실이라면 DSL이 적합 할 수 있습니다.

장기적으로 내 언어를 만드는 것이 더 나은 킬러 응용 프로그램 유형, 알고리즘 문제 클래스 등이 있습니까?

따라 다릅니다.

우리의 뇌를 보자. 우리가 (최소한) 모든 프로그래밍 언어와의 경계에 직면하는 것은 복잡한 혼란으로 보입니다. 뇌를 실제로 가상화하려면 다른 접근 방식과 다른 의미론 및 구문이 필요합니다.

일반적으로 말해서, 주어진 시나리오에 대해 더 나은 언어를 포함하는 다른 전략으로 이어질 수있는 복잡한 주제가 아직 있습니다.