いつ自分のプログラミング言語を作成するのが合理的ですか？

長い目で見れば、独自の言語を作成する方が優れているような、キラーアプリケーションのタイプ、アルゴリズムの問​​題のクラスなどはありますか？

PS：確かに、私は既存の言語用の新しいコンパイラではなく、新しいプログラミング言語とコンパイラを意味します。

編集：答えてくれてありがとう。DSLの作成が絶対に不要な場合や、DSLが良いアイデアである場合の例をいくつか挙げてください。

人が教育目的で自分の言語を書くことは確かに重要です。プログラミング言語の設計とコンパイラの設計について学ぶため。しかし、実際の使用はほとんどありません。

あなた自身の言語を書くとき、あなたは：

• あなたの問題に途方もない量の複雑さを加える
• 新しい言語とコンパイラの作成と保守にかなりの量の作業を追加する

したがって、プロジェクト用に独自の言語を作成する場合、他の言語が上記のコストを相殺する必要がないという機能が提供されます。

たとえば、ゲーム開発を考えてみましょう。多くの場合、ゲーム内またはスクリプト言語内のミニ言語が必要です。これらの言語を使用して、発生するゲーム内イベントの膨大な量をスクリプト化します。ただし、この場合でも、ほとんどの場合、既存のスクリプト言語を選択し、ニーズに合わせて調整します。

元VBコンパイラのチーフデベロッパーであり、現在Project OsloとM言語に取り組んでいるPaul Vickを引用します。

新しい言語を構築することは、既存の言語に大きく基づいている言語であっても、途方もなく驚くほど困難です。しかし、多くのプログラマーは「ねえ、私は言語を使用しています。これはどれほど難しいのでしょうか？」と考え、それに取り組みます。…おそらく98％以上の人が牽引力を得ることができませんが、楽観者を祝福します。彼らなしでは、成功する言語の2％を得ることができません。個人的には、C＃やJava、RubyやPythonなどの言語を取得できるようにするために、何百万ドルも何時間も無駄にしない言語を犠牲にして喜んでいます。

したがって、新しい言語を思い付くのは悪い考えであるという事実は、人々に新しいDSLの開発を思いとどまらせるべきではなく、単に一時停止し、できれば少し謙虚さを与えるべきです。重要なのは、小さいことから始めて、小さいままでいることです。

DSL：間違いなく悪い考えです！

いつ合理的ですか？

気分がいいとき！

これらの人々が基本的に次のような卑劣なコメントを聞いてはいけません。

「難しすぎて、X言語は思いつくどの言語よりも優れているので、やらないでください」。

問題は、DSLの作成は常に行われるということです。フレームワークはDSLです。マクロはDSLです。プログラムの関数を作成するたびに、それはDSLの一部です。確かに、文法の範囲内ですが、語彙は言語の一部です。これが、業界がしばしば独自の用語を作成する理由です。より効率的です。

「やらない」が正解だった場合、私たちは皆COBOLとFortranを書いているでしょう。

あなたがあなた自身の言語を書くことを考えているなら、あなたはマーティン・ファウラーの今後のDSL本の一部を読みたいかもしれません。

素晴らしい学習体験である以外に、ゼロから言語を作成するビジネスケースを考えることはできません。

編集：DSLの場合、多くのビジネスケースがありますが、ここで重要なのは、夢中になって、それをシンプルに保つことです。

重要な質問は、「どのような問題を解決しようとしていますか？」であることをお勧めします。「誰がROIを取得しますか？」

独自のスキルと経験を構築しようとしている場合は、全速力で前進しますが、他の誰かの問題を解決するはずの本番システムではそうではありません。

新しい言語が必要な主な理由のように思えるのは、既存の言語ではうまく処理できないコードのパターンを発見し始めるからです。しかし、独自の言語を作成することには多くの問題があります。既存の言語用に構築されたすべてのライブラリとフレームワークを逃してしまいます。新しい言語の設計と実装に多くの時間を費やします。これは、実際のプログラミングタスクに費やす必要のない時間です。あなたは他の開発者にあなたの言語を使うべきだと納得させるために多くの努力を費やすでしょう。また、新しい開発者を募集してトレーニングするのは大変です。

新しいパターンを発見したときに言語を拡張できるLispのような言語で書いてみませんか？その後、確立された言語のすべての利点を備えた新しい言語のすべてのパワーを取得します。

1つの理由は、言語設計とコンパイラー構築について学ぶための実験として作成することです。

もう1つの理由は、サードパーティAPIを追加するオプションがない場合に、アプリケーションにスクリプト言語を組み込むことです。

新しい言語を作成せずにプログラミングできるとは思わないので、それがあなたがしていることであり、問​​題を理解していることを理解するのは良いことです。

• 言語とは何ですか？
  語彙、構文、およびセマンティクス。

VB、Java、C＃などの既製の言語は、単なる基本言語です。クラス、メソッドなどを追加するとすぐに、語彙とセマンティクスが追加されます。言語の実装には多くの方法があります-解析と翻訳、解析と解釈、既存の言語の上にあるマクロ、既存の言語へのクラスとメソッドの追加。

• 言語に何をしてほしいですか？
  問題を簡潔に表現するのに適しています。

これを行ったかどうかはどうやってわかりますか？私が使用するメジャーは編集カウントです。1文の要件Aが発生した場合、要件をコードに実装します。完了し、すべてのバグを解決したら、コードをチェックインします。コードリポジトリに、行った変更のリストBが表示されます。Bが小さいほど、言語は良くなります。実際の要件と考えられる要件のスペース全体で平均すると、その測定値によって、言語がどのように「ドメイン固有」であるかがわかります。

• なぜ簡潔さが良いのですか？
  バグを最小限に抑えるためです。

1つの要件を実装するためにN個のコード変更が必要で、時々ミスを犯す場合、導入するバグの数はおおよそNに比例します。N= 1の制限では、試行せずにバグを導入することはほとんど不可能です。

これは、最近見られる「コードの肥大化」に対する直接的な挑戦であることに注意してください。

追加：例のリクエストに応じて、差分実行を参照してください。すぐに理解できるとは言いませんが、UIコードを大幅に削減します。

（元の）質問でこの単語を使用することは常に「実行可能」ですが、十分にサポートされ成熟した言語とフレームワークが存在することを考えると、あまり有用ではなく、非常にまれに最適です。

しかし、これは興味深い知的挑戦です。

チームのコアビジネスがプログラミング言語である場合のみ。

私は金融会社で作成されたプログラミング言語に取り組んできました。

明らかに、建築家自身にとってこれは大きな挑戦であり、彼自身のスキルを向上させました。

必然的に、言語はC＃やJavaのようなものに近い速度で成長したり、改善したりすることはできませんでした。

誰も他の誰かのペットプロジェクトを改善する仕事を引き受けたくなかったので、言語はすぐに停滞しました。

元の建築家が去りました。言語は枯れ、10年後に死んだ。

この10年は、行き詰まった言語で仕事をする不幸な人にとっては地獄でした。

独自の言語を作成しますが、実際に使用するよう他の人に依頼しないでください。他の誰かがあなたに感謝することを期待しないでください。

言語の設計は楽しいものです。ただし、プログラミング言語に制限する必要はありません。

適度に複雑なアプリケーションを構築する場合、複雑な反復タスクを簡単に実行できるように、一種のマクロ/スクリプト言語を追加するのが好きです。ほとんどのユーザーはこの機能を使用しませんが、それを使用する少数のユーザーは非常に感謝しています。また、サポート担当者が顧客の問題を解決するのに役立つことが重要であることを確認します。

あなたのスキルを伸ばし、学ぶために行われた場合、それは完全に合理的です。

それ以外に、質問をしなければならない場合、そうではありません。特定のクラスのアルゴリズムに対処できるか、既存の言語よりも優れた特定の問題領域に対処できるかを判断しようとする場合、まず、対処する分野の専門家である必要があります。あなたのスキルと経験があなたにそう言うとき、あなたはそれが適切であることを知るでしょう。

そして、あなたもそれについて間違っている可能性がありますが、あなたはそれをあなたに納得させるために（またはあなたがあなたがそうだと思う専門家ではないことをあなたに示すために）別の専門家を必要とするでしょう。ここで見られるような単純な質疑応答ではなく、活発な議論です。

独学の目的を除いて、私は今日、あなた自身の言語を作成する必要は全くないと主張したいと思います。どんな状況でも。今まで。あなたが何をしたいかに関係なく、あなたのニーズに応じる/適応できる既存の言語のボートがたくさんあります。

それは決定的に状況に依存します。noskloが言ったように-良いアイデア、真新しいコンセプト、またはそのようなものがあれば、それを行うことを強くお勧めします。

一般に、確立された技術に依存することをお勧めします。

ただし、独自の「言語」の作成に興味がある場合は、YACCとLexをチェックしてください。

アンチパターンの「四角い車輪の再作成」にとらわれないでください。

つまり、すでに行われたものを再作成しているということです。元のものよりも劣っています。

Wouterは、新しいアイデアのために新しい言語を作成することで知られていました。彼の作品であるWouterのプログラミング言語ページからインスピレーションを引き出すことができます。

いつ自分の言語を作成しますか？

あなたがしたいとき、大規模な趣味のプロジェクトとして。

ドメイン固有の言語用。これらは非常に複雑な場合があります。アーカイブをチェックアウトして、インタラクティブフィクション（またはテキストアドベンチャー）コミュニティで何が起こっているかを見てください。

目標が非常に野心的で、Paul GrahamのArcプロジェクトのように、本当に前進できると思うとき。

また、低レベルのコンストラクトを開発する過程で、十分に適応可能な言語（おそらくC ++、間違いなくCommon Lisp）で。

あなたがそうするようにそれを避けるべき時、私は、ペストのようにそれを避けるような決まり文句を避けたいと思いますか？

実際のプロジェクトの継続的な開発の基礎となるとき。それは常に安価で市販されているものよりも真剣に遅れを取り、さらなる開発を妨げます。独自のバージョンのCOBOLを使用している会社で働いていましたが、独自の言語を維持している別の会社で働きたくありません。COBOLの他のバージョンがより良い機能とより良いツールを得るのを見ましたが、同じ問題に悩まされていました。（二度とCOBOLを使いたくありませんが、それは別の話です。）

独自の言語を作成する状況はこれに該当しません。趣味のプロジェクトは実際の開発には使用されません。Arcのようなものは成功する（そして複数の実装とさらなる進化と開発を得る）か失敗する（そして誰もそれを使用しない）。ドメイン固有の小さな言語はプロジェクトの一部に過ぎず、小さいため時間とともに改善できます。テキストアドベンチャー言語は、個々のゲームを書くために使用され、それらのゲームは、趣味のプロジェクトであることに加えて、開発の継続にはほとんど使用されません。

私の見方では、DSLは一般に「弱いアイデア」であり、長期的には標準言語を使用し、「非DSL」のライブラリとしてドメイン固有のニーズを構築する方が生産的です。

しかし、あなたのニーズはあなたの会社のためにDSL（わずかに変更されたgccやlisp実装だけでなく）を持つことが望ましいほど十分にカスタムであることが判明するかもしれません。多くの企業は、独自の言語を作成/維持せずに、現在行っていることをターゲットとする現在の言語のドロップインを使用しています。たとえば、PHPには便利なドロップインがあると聞きました。Luaはドロップインであるように設計されており、ModelViewはPythonを使用し、AutoCADはスクリプト作成者としてAutoLISPを使用しています。

既存のツールを活用できるのであれば、独自のプログラミング言語を作成しても問題はありません。今日の世界では、これは既存の言語（JavaやC＃など）で使用可能な構文で定義するか、既存の言語でコードを生成する小さな変換システム（マクロエキスパンダー）を記述することを意味します。

マシンコードに至るまで、すべての車輪を再発明しています...

DSLの非常に良い理由は、ドメインデータを簡潔に表現することです。これにより、ドメインの専門家は他のユーザーを介さずにデータを直接操作できます。そのコツは、結果のプログラムを処理しやすい形式にすることです。

一般的に言えば、答えは大きなNOです。そこにある何百もの言語の中には、通常あなたの問題に合ったものがあります。

しかし、新しい言語を開発することが合理的な選択肢である状況があります-

• 競合他社がメイン開発プラットフォームの1つを所有するようになったとき。GoogleのJavaへの現在の依存と「go」の開発について考えています（給与でこれまでで最も成功した言語の著者がいる場合に役立ちます！）。
• 新しいプラットフォーム用に大量のコードを記述する必要があり、既存の言語が冗長でエラーが発生しやすい場合（たとえば、Web開発用のphp）。
• これまでに一度も遭遇したことのない規模と並列性の問題に出くわすと、これほど多くのデータを処理するためのハードウェアがこれまでになかったためです。たとえば、Scalaや（ある程度GO）。

言語が得意なのは、構成性、または同じコンポーネントを異なる方法で組み合わせることです。

ドメインの問題で多数の直交スイッチを設定するだけでよい場合、言語はおそらくフォーム、グラフィックUI、またはストレートテキスト設定にあまり追加しません。ファイル。（ここでは、キーと値のペアでいっぱいのファイルは、「言語」が意味するものではないと仮定しています。）

OTOH（設定が実際の言語のような場合）動詞と名詞は、さまざまな（かつ斬新な）組み合わせでさまざまな複雑さでまとめることができます。他の方法で必要なものを指定しようとする組み合わせの爆発が圧倒されるため、言語はほとんど避けられないものになります。

学習演習は別として、他の言語、特定の問題ドメイン、および既存の言語がその問題ドメインに対処する方法を理解している場合にのみ、独自のプログラミング言語を作成することは合理的であり、この理解は新しい言語が合理的であることを十分に理解している質問をする必要のない解決策。

趣味のプロジェクトでそれを行うために最後に着手したとき、構文をどのように見せたいかを指定し始め、途中でプロローグを再発明しました。あなたが言語を発明する必要があると思うときにぴったりかもしれない他の言語は、lisp、lua、またはHaskellのようなものです。基本的に、あなたが大学で無視したすべての言語は、それらは決して有用ではないと思ったためです。

1つの理由は、すでに述べたように、教育目的のためです。しかし、もっとあります。たとえば、などの多くの研究の言語があるSing#上の特異点のオペレーティングシステムとBitCのCoyotos既存の言語が（言語レベルでのインスタンスの検証のために）必要な機能を提供しないために設計されています。

Tom Van Cutsemは最近、まさにこの質問に対するエッセイの回答を書きました。

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

箇条書きの要約（そのページから）：

• 構文の抽象化メカニズムとしての言語：別の言語の組み込み抽象化メカニズムを使用して抽象化できない反復的な「定型的な」コードを減らすため。
• 思考形成者としての言語：ソフトウェアの構築方法のパラダイムシフトを誘発する（「抵抗が最小の経路」を変更する）。
• 単純化としての言語：既存のパラダイムをその重要な部分だけに要約し、多くの場合、理解と洞察を高めます。
• 法執行機関としての言語：重要なプロパティまたは不変条件を強制し、おそらくプログラムからより有用なプロパティを推測しやすくするため。

おそらく決して。

基本的に他の言語に言語を埋め込む場合、Luaが最良の選択です。

Small Domain Specifc Languagesは現在使用されており、一部のアプリケーションでは意味があります。

それ以外は、主に学問的な理由です。

必要のないときに言語を作成するのは、その開発と保守に複雑さが伴うため、本当に悪いことです。私はそのプログラムだけに特化した何らかのスクリプト言語を導入する多くのプロジェクトを見てきましたが、それはベースとなるものの開発を大幅に遅らせていました。良い例は、Phantom、AutoHotKey、AutoItなどの自動化言語です。これらのツールは、Luaのようなよく知られた埋め込み言語を使用する場合、IMOの方がはるかに優れています。

あなたの「編集」は本質的に異なる質問のようです（「新しい汎用プログラミング言語をいつ作成すべきか」と人々が理解していた元の質問ではなく、「DSLをいつ作成すべきですか？」）。人々は「元の」質問に完全に答えているようですが、DSLをいつ使用するかについての特定の基準を与える答えはほとんどありません。だから私はチェックリストを提案します：

1. あなたのユーザーベースは数人よりも大きく、一般に非技術的および/またはシステムアクセスが制限されています（したがって、既存の汎用言語を学習/使用することを期待するのは不合理です）。開発チームまたはソフトウェア組織内にある場合は、代わりに「スクリプトを書くだけ」と言うことができます。
2. ユーザーは十分に頻繁に使用する必要があり、十分に多様で変化する動作が必要です（つまり、自分が管理する機能の固定ライブラリを提供することはできません）
3. ユーザーが指定できる動作は、データとして指定するには複雑すぎます（たとえば、データベーステーブル、ユーザー入力マトリックス、タスクのリスト、またはキーと値のコレクションを使用して達成することはできません...あなたはこれらで多くの複雑さを達成できるからです）。DSLの代わりにデータ入力または構成を使用して動作を実現できる場合、作業がはるかに少なくなるため、おそらくそうすべきです。ある種の条件、または構成可能性/連鎖、またはいくつかの異なる抽象化のモデリングは、必要な動作が単純なデータ/構成に対して複雑すぎることを示している可能性があります
4. ただし、動作は十分に制限されているため、簡潔なDSLで指定できます。大きな危険は「プラットフォームの肥大化」です。たとえば、ユーザーが「追加するだけでいいですか？」という要求を始めた場合です。インターネットへの接続、ファイルシステムからの読み取りと書き込み、またはプロセスのオープンとクローズが必要な場合、これはもはやDSLではありません。（私はこれが実際に起こることを見てきました...ユーザーは小さなPython呼び出しを埋め込み、徐々にPythonスクリプトに成長し、最終的に制限/モジュール性/パフォーマンスを破壊します）

これらすべてが当てはまる場合、DSLが適切である可能性があります。

長い目で見れば、独自の言語を作成する方が優れているような、キラーアプリケーションのタイプ、アルゴリズムの問​​題のクラスなどはありますか？

場合によります。

脳を取りましょう。（少なくとも今のところ）プログラミング言語との境界に遭遇するのは、とても複雑な混乱のようです。したがって、脳を実際に仮想化するには、他のアプローチが必要であり、そのために他のセマンティクスと構文が必要です。

一般的に言えば、特定のシナリオに対して「より良い」言語を含む他の戦略につながるような複雑なトピックがまだあります。