独自のプログラミング言語を作成するのが妥当なのはいつですか？
長い目で見れば、自分の言語を作成する方がよい、キラーアプリケーションの種類、アルゴリズムの問題のクラスなどはありますか？
PS：念のために言うと、私は既存の言語用の新しいコンパイラではなく、新しいプログラミング言語とコンパイラを意味します。
[〜＃〜] edit [〜＃〜]：回答ありがとうございます。 DSLを作成することが絶対に不要な例や、DSLが良いアイデアである場合を挙げてください。
教育目的で自分の言語を書くことは確かに重要です。プログラミング言語の設計とコンパイラの設計について学ぶ。しかし、実際の使用はほとんどありません。
あなた自身の言語を書くことであなたは：
- 問題に驚異的な複雑さを追加する
- 新しい言語とコンパイラーの作成と保守にかなりの量の作業を追加する
したがって、プロジェクト用に独自の言語を作成することを計画している場合、他の言語が提供する機能が上記のコストを相殺する必要はありません。
たとえば、ゲーム開発を見てみましょう。多くの場合、ゲームやスクリプト言語にミニ言語が必要です。彼らはこれらの言語を使用して、発生するゲーム内イベントの膨大な量をスクリプト化しています。ただし、この場合でも、ほとんどの場合、既存のスクリプト言語を選択し、ニーズに合わせて調整します。
VBコンパイラの元開発者で、現在Project OsloとM言語に取り組んでいるPaul Paul Vickを引用しておきます。
新しい言語を構築することは、既存の言語に主に基づいている言語であっても、驚くほど困難です。しかし、多くのプログラマーは、「ねえ、[〜＃〜] i [〜＃〜]言語を使用します。これはどれほど難しいのでしょうか？」それに行く。 …おそらく98％を超える人々はまったく牽引力を獲得できていませんが、彼らなしでは成功する言語の2％を得ることができないので、神は楽観主義者を祝福します。私は個人的に、C＃やJavaやRubyのような言語を入手できるように、決して実現しない言語で無駄に費やされた何百万ドルも何時間も犠牲にして=およびPythonなど。
したがって、新しい言語を思い付くことが悪い考えであるという事実は、人々が新しいDSLを開発することを思いとどまらせるべきではなく、単に一時停止し、できれば少し謙虚にすべきです。重要なのは、小さなことから始めて、小さなままであることです。
それはいつ合理的ですか？
気に入ったとき！
基本的に次のような卑劣なコメントをしているこれらの人々に耳を傾けないでください。
「難しすぎてX言語が思いつく他のどの言語よりも優れているので、やらないでください」。
問題は、DSLの作成は常に行われることです。フレームワークはDSLです。マクロはDSLです。プログラムの関数を書くたびに、それはDSLの一部です。もちろん、それは文法の範囲内ですが、語彙は言語の一部です。これが、産業界がしばしば独自の自国語を作成する理由です。
「それをしないでください」が正解だったとしたら、私たちは皆、COBOLとFortranを書いているでしょう。
あなた自身の言語を書くことを考えているなら、あなたは Martin Fowlerの次のDSL本 の一部を読みたいかもしれません。
言語を一から作成するビジネスケースは、途方もない学習体験であるということ以外には考えられません。
編集：DSLには多くのビジネスケースがありますが、ここで重要なのは、慌てずにシンプルに保つことです。
重要な質問は、「どのような問題を解決しようとしているのですか？」そして「誰がROIを得るのですか？」
独自のスキルと経験を構築しようとしている場合、他の誰かの問題を解決するはずの本番システムではなく、全速力で進んでください。
新しい言語が必要な主な理由のように思われるのは、既存の言語ではうまく処理できないコードのパターンを発見し始めるためです。しかし、あなた自身の言語を作成することには多くの問題があります。既存の言語用に構築されたすべてのライブラリーとフレームワークを見逃してしまいます。新しい言語の設計と実装に多くの時間を費やすことになりますが、それは実際のプログラミングタスクに費やす必要がないすべての時間です。あなたは他の開発者にあなたの言語を使うべきだと説得する多くの努力を費やすでしょう。そして、あなたは新しい開発者の採用とトレーニングに苦労するでしょう。
新しいパターンを発見したときに言語を拡張できるLISPのような言語で書いてみませんか？次に、確立された言語のすべての利点を備えた新しい言語のすべての能力を手に入れます。
1つの理由は、言語設計とコンパイラー構築について学ぶための実験としてそれを作成することである可能性があります。
別の理由として、サードパーティのAPIを追加するオプションがない場合に、スクリプト言語をアプリケーションに組み込むことが考えられます。
新しい言語を作成せずに /をプログラミングできないと思うので、それがあなたがしていることを理解し、問題を理解するのは良いことです。
- 言語とは？
語彙、構文、およびセマンティクス。
VB、Java、C＃などの既製の言語は、 base 言語にすぎません。クラス、メソッドなどを追加するとすぐに、語彙とセマンティクスが追加されます。言語の実装には多くの方法があります-解析と翻訳、解析と解釈、既存の言語の上にあるマクロ、既存の言語へのクラスとメソッドの追加。
- 言語で何をしたいですか？
問題を簡潔に表現するのに適しています。
これを行ったかどうかはどうやって分かりますか？私が使用する測定は edit count です。 1文の要件Aが出てきた場合は、要件をコードに実装します。完了してすべてのバグが見つかったら、コードをチェックインします。コードリポジトリから、加えた変更のリストが表示されますB。 Bが小さいほど、言語は優れています.実際の要件と可能な要件の範囲で平均化された測定値は、言語が「ドメイン固有」であることを示しています。
- 簡潔さが良いのはなぜですか？
バグを最小限に抑えるため。
1つの要件を実装するためにN個のコード変更が必要で、間違いを犯すことがある場合、導入するバグの数はNにほぼ比例します。N= 1の制限では、を導入することはほとんど不可能ですバグせずに。
これは、今日見られる「コード膨張」に対する直接的な挑戦であることに注意してください。
ADDED：例のリクエストに応じて、 差分実行 を参照してください。すぐに理解できるとは言いませんが、UIコードを大幅に削減します。
（元の）質問でWordを使用することは常に「実現可能」ですが、十分にサポートされ成熟した言語とフレームワークが豊富に存在することを考えると、それほど頻繁に役立つわけではなく、非常にまれです。
しかし、それは興味深い知的挑戦です。
チームのコアビジネスがプログラミング言語の場合のみ。
私は金融会社で作成されたプログラミング言語に取り組んできました。
明らかに、建築家自身にとってこれは大きな挑戦であり、彼自身のスキルを向上させました。
必然的に、言語は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があるスクリプターとして。
一般的に言えば、答えは大きなNOになります。何百もの言語のうち、通常は問題に適したものが存在します。
しかし、新しい言語を開発することが合理的な選択肢である状況があります：-
- 競合他社の1つが主な開発プラットフォームの1つを所有している場合。私はGoogleが現在Javaに依存していることと、「go」が発達したことを考えています（給与計算で最も成功した言語の著者がいる場合に役立ちます）。
- 新しいプラットフォーム用に大量のコードを記述する必要があり、既存の言語が冗長でエラーが発生しやすい場合。 Web開発用のphp。
- これほど多くのデータを処理するためにこれほど多くのハードウェアをこれまで誰も持っていなかったために、これまでにないスケールと並列処理の問題に遭遇したとき。 Scala and（ある程度GO）。
既存のツールを活用できるのであれば、独自のプログラミング言語を書くことに何の問題もありません。今日の世界では、これは、既存の言語で使用可能な構文（JavaまたはC＃）など）で定義するか、既存のコードを生成する小さな変換システム（マクロエキスパンダー）を記述することを意味します言語。
機械コードに至るまで、たくさんの車輪を再発明しています...
DSLの非常に良い理由は、ドメインデータを簡潔に表現することです。これにより、ドメインの専門家は他の人を介さずにデータを直接操作できます。その秘訣は、結果のプログラムを処理しやすい形にすることです。
どの言語が得意ですかcompositionalityまたは同じコンポーネントを異なる方法でまとめます。
ドメインの問題で一連の直交スイッチを設定する必要があるだけの場合、言語はフォーム、グラフィックUI、または単純なtext-configにあまり追加しません。ファイル。 （ここでは、ファイルがキーと値のペアでいっぱいであると想定していますではない「言語」の意味。）
OTOH、設定が実際の言語に似ている場合。動詞と名詞は、さまざまな（そして斬新な）組み合わせで任意の複雑度にまとめることができます。その場合、他の方法で必要なものを指定しようとする組み合わせの爆発により、言語はほとんど避けられなくなります。
Tom Van Cutsemは最近、まさにこの質問に対するエッセイの回答を書きました：
http://soft.vub.ac.be/~tvcutsem/whypls.html
箇条書きの要約（そのページから）：
- 構文抽象化メカニズムとしての言語：別の言語の組み込みの抽象化メカニズムを使用して抽象化できない反復的な「ボイラープレート」コードを削減します。
- 思考形成要因としての言語：ソフトウェアの構造化方法にパラダイムシフトを引き起こす（「最小抵抗のパス」を変更する）。
- 簡素化としての言語：既存のパラダイムをその本質的な部分にまで煮詰め、多くの場合、理解と洞察を高める。
- 法執行機関としての言語：重要なプロパティまたは不変条件を適用し、プログラムからより有用なプロパティを推測しやすくするため。
練習問題は別として、他の言語、特定の問題ドメインを理解し、既存の言語がその問題ドメインに対処し、この理解が十分に理解できる場合にのみ、独自のプログラミング言語を作成するのが妥当です知っている =新しい言語は、質問をする必要がない合理的な解決策です。
前回、趣味のプロジェクトでそれを行うことを始めたとき、構文をどのように見せたいかを指定し始め、途中でプロローグを再発明していることに気付きました。言語を発明する必要があると思われる場合に適している可能性のある他の言語は、LISP、lua、またはHaskellのようなものです。基本的に、あなたがそれらが決して役に立たないだろうと思ったので、大学であなたが無視したそれらすべての言語。
すでに述べたように、1つの理由は教育目的です。しかし、もっとあります。たとえば、 Singularity オペレーティングシステムのSing#や Coyotos のBitCのような多くの研究言語は、既存の言語のために設計されています必要な機能を提供しない（たとえば、言語レベルでの検証）。
おそらくない。
基本的に他の言語で言語を埋め込む場合は、Luaが最適です。
小規模ドメイン固有言語は現在使用されており、一部のアプリケーションでは理にかなっています。
それ以外の場合、理由は主に学問的なものです。
必要のないときに言語を作成することは、その開発と保守に複雑さが伴うため、行うのが本当に悪いことです。そのプログラムにのみ固有のスクリプト言語を導入する多くのプロジェクトを見てきましたが、それはベースとなるものの開発を大幅に遅くするものでした。良い例は、Phantom、AutoHotKey、AutoItなどのインスタンス自動化言語です。これらのツールは、Luaのようなよく知られているエミング言語を使用すれば、IMOのほうがはるかに優れています。
あなたの「編集」は本質的に異なる質問のようです（「新しい、汎用プログラミング言語をいつ作成する必要があるか」と人々が理解していた元の質問ではなく、「いつDSLを作成する必要がありますか？」）。人々は「元の」質問に完全に答えたようですが、DSLをいつ使用するかの具体的な基準を示す回答はほとんどありません。だから私はチェックリストを提案します：
- ユーザーベースが数人よりも多く、一般的に技術的ではない、および/またはシステムアクセスが制限されている（したがって、既存の汎用言語を学習/使用することを期待するのは不合理です）。それが開発チームまたはソフトウェア組織内にある場合は、代わりに「スクリプトを書くだけ」と言うことができます。
- ユーザーはそれを十分に頻繁に使用する必要があり、十分に多様で変化する動作が必要です（つまり、ユーザーが管理する関数の固定ライブラリを提供することはできません）。
- ユーザーが指定できる動作は複雑すぎてデータとして指定できません（たとえば、データベーステーブル、ユーザー入力行列、タスクのリスト、またはKey-Valueコレクションを使用してそれを達成することはできません...慎重に考えてくださいあなたはこれらで多くの複雑さを達成できるからです）。 DSLの代わりにデータ入力または構成を使用して動作を達成できる場合は、作業がはるかに少ないため、おそらくそうすべきです。ある種の条件付け、または構成可能性/連鎖、またはいくつかの異なる抽象化のモデリングは、必要な動作が単純なデータ/構成には複雑すぎることを示している可能性があります
- ただし、動作はまだ十分に制限されているため、簡潔なDSLで指定できます。大きな危険は「プラットフォームの肥大化」です。ユーザーが「追加できますか？」のリクエストを開始した場合。インターネットに接続したり、ファイルシステムから読み書きしたり、プロセスを開いたり閉じたりする必要がある場合、これはDSLではありません。 （私はこれが実際に起こるのを見ました...ユーザーは小さなpython呼び出しを埋め込み、徐々にpythonスクリプトに成長し、最終的にすべての制限/モジュール性を破壊することを許可しました/パフォーマンス）
これらのすべてに該当する場合は、DSLが適切です。
長い目で見れば、自分の言語を作成する方がよい、キラーアプリケーションの種類、アルゴリズムの問題のクラスなどはありますか？
場合によります。
私たちの脳を取ってみましょう。 （少なくとも今は）プログラミング言語との国境に遭遇するほど複雑な混乱のようです。したがって、おそらく私たちの脳を実際に仮想化するには、他のアプローチが必要であり、そのために他のセマンティクスと構文が必要です。
一般的に言えば、特定のシナリオに「より良い」言語を含む他の戦略につながる可能性のある複雑なトピックがまだあります。