14

長い間、私は必要な機能セットを見つけるためにさまざまな言語を試してきましたが、見つけることができませんでした。私は自分のさまざまなプロジェクトに適切に適合する言語を持っていますが、これらの言語の共通部分を考え出し、プロジェクトの99.9%を単一の言語で実行できるようにします。私は以下が欲しい:

  • .NET上に構築されているか、.NET実装があります
  • コンパイル時と実行時の両方で.NETランタイムへの依存関係はほとんどありません(主要なユースケースの1つは、.NETランタイムが完全にカスタムである組み込み開発であるため、これは重要です)
  • 管理されていない依存関係のない100%.NETコードのコンパイラがあります
  • 任意の式のネストをサポートします(以下を参照)
  • カスタム演算子定義をサポートします
  • 型推論をサポートします
  • 末尾呼び出しを最適化します
  • 明示的な不変/可変の定義があります(素敵です-私はこれを愛するようになりましたが、それなしで生きることができます)
  • 強力なメタプログラミングのための実際のマクロをサポートします(絶対に必要です)

私が使用している主な2つの言語は、BooとNemerleですが、F#でも遊んでいます。

Nemerleに対する主な不満:コンパイラには恐ろしいエラー報告があり、実装は地獄(コンパイラとライブラリ)としてバグがあり、マクロは関数内または属性としてのみ適用でき、依存関係に関してはかなり重いです(十分ではありませんが)ディールブレーカー)。
Booに対する主な不満:任意の式のネスト(ディールブレーカー)、マクロの記述が困難、カスタム演算子の定義(潜在的なディールブレーカー)がありません。
F#に対する主な不満:醜い構文、メタプログラミングを理解するのが難しい、非フリーライセンス(壮大なディールブレーカー)。

ですから、考えれば考えるほど、自分の言語を開発することを考えます。

長所:

  • 必要な構文を正確に取得する
  • かなり速くなるターンアラウンドタイムを取得します。定量化するのは難しいですが、開発者の生産性が1.5倍になっても驚かないでしょう。特に、これにより特定のプロジェクトで使用できるテストインフラストラクチャが原因です。
  • コンパイラにカスタム機能を簡単に追加して、ランタイムでうまく機能させることができます
  • 私は自分が望むように設計され、正確に機能するものを手に入れました-これはNIHのように聞こえますが、これは私の人生を楽にしてくれます

短所:

  • 人気が出ない限り、メンテナンスの負担に悩まされます。誰もがもっとプロフェッショナルなものを望んでいると思うので、少なくともNemerleの人々を乗り越えることができることは知っていますが、それには村が必要です。
  • 最初の欠点のため、私はプロの設定でそれを使用することを警戒しています。とは言うものの、私はすでにNemerleを使用しており、独自のカスタム変更されたコンパイラーを使用しています。
  • それが人気を博さなければ、開発者を見つけることははるかに難しくなり、PaulGrahamが容認すらしないかもしれません。

したがって、これらすべてに基づいて、一般的なコンセンサスは何ですか?これは良いアイデアですか、それとも悪いアイデアですか?そしておそらくもっと有益なことに、私は大きな賛否両論を見逃しましたか?

編集:ネストの例を追加するのを忘れました-これがNemerleのケースです:

def foo = 
    if(bar == 5)
        match(baz) { | "foo" => 1 | _ => 0 }
    else bar;

編集#2:存在する場合にこの言語に変換されるコードのタイプの例を示すことは害にならないだろうと考えました(S. Lottの答えだけで、私がそれをするのを怖がらせるのに十分かもしれません)。このコードは、カスタム構文(opcode、:=、quoteblockなど)、式のネストなどを多用しています。ここで良い例を確認できます:ここ

4

10 に答える 10

15

残念ながら、失敗した言語に関する指標やストーリーはありません。成功した言語ばかりです。明らかに、失敗の数が成功の数を上回っています。

これは何に基づいていますか?2つの共通の経験。

  1. 年に 1 ~ 2 回、すべてを完全に変える製品/言語/ツール/フレームワークの売り込みに耐えなければなりません。私の答えは、過去 20 年ほどの間、一貫しています。サポートが必要な人を見せてください。私の会社がサポートします。そして、それはそれです。彼らから二度と聞くことはありません。これらのうち25件を聞いたとしましょう。

  2. 年に 1 ~ 2 回、テクノロジーを孤立させた顧客と仕事をしなければなりません。過去のある時点で、巧妙なプログラミングによって、いくつかのプロジェクトで内部的に使用されるツール/フレームワーク/ライブラリ/パッケージが構築されました。その後、そのプログラマーは去りました。他の誰もそのことを理解することはできず、彼らは私たちにそれを置き換え/書き直したいと思っています. 残念ながら、私たちもそれを理解することはできません。私たちの提案は、ゼロから書き直すことです。そして彼らは、彼らの天才がアプリのセットを数週間で構築したと不平を言っています.Java / Python / VB / C#でそれらを書き直すのに数ヶ月かかることはありません. 私がこの種の提案を 25 ほど書いたとしましょう。

それは私、1人のコンサルタントです。

実際、特に悲しい状況の 1 つは、IT ソフトウェア ポートフォリオ全体が、私的な言語とツールを使用する 1 人の賢い人物によって作成された企業でした。彼は去っていませんでしたが、自分の言語とツールセットが時代遅れになっていることに気付きました。

そしてその動きは、もちろん、予想外の方向に進んだ。彼の言語とツールは問題ありませんでしたが、世界はリレーショナル データベースを採用し始めており、フラット ファイルから移行するためにジャンクをアップグレードする方法はまったくありませんでした。それは彼が予期していなかったものでした。確かに、それは彼が予測できなかったものでした。【こんな罠にはまらないよね?】

それで、私たちは話しました。彼は Plain-Old VAX Fortran で多くのアプリケーションを書き直しました (はい、これはずっと前のことです)。そして、単純な古いリレーショナル SQL を使用するように書き直しました (当時は Ingres でした)。

1 年間コーディングした後、彼らはパフォーマンスの問題を抱えていました。彼らは、自家製の言語を置き換えるために行ったすべての素晴らしいことを確認するために、私に電話をかけ直しました。悲しいことに、彼らは可能な限り最悪のリレーショナル データベース設計を行っていました。最悪。彼らはファイルのコピー、マージ、並べ替えなどを行い、SQL を使用して各低レベルのファイル システム操作を実装し、データベースの行を左、右、中央に複製しました。

彼は完全な言語という個人的なビジョンに夢中になっていたため、比較的一般的で広く普及している新しいテクノロジーに適応できませんでした。

于 2008-10-11T10:52:32.847 に答える
5

私はそれのために行くと言います。

  • 天候に関係なく、生産に至るかどうかに関係なく、素晴らしい経験になるでしょう.
  • IL にコンパイルする場合、コンパイルしたアセンブリを C# で再利用できないことを心配する必要はありません。
  • あなたが上に挙げた言語について正当な不満を持っていると信じているなら、多くの人があなたと同じように考えるでしょう. もちろん、関心のある人 1000 人につき 1 人は維持を手伝ってくれるかもしれませんが、それは常にリスクです。

ただし、次の点に注意してください。

  • 開発前に言語仕様を STONE で取得します。あらゆる言語機能が事前に把握されていることを確認してください - 将来必要になる可能性があるものであっても。私の意見では、C# はゆっくりと「もう 1 つだけの言語拡張」という罠に陥り、最終的に破滅へと向かうでしょう。
  • 必ず最適化してください。あなたがすでに知っていることはわかりません。しかし、わからない場合は学習してください;) 構文が優れていてもIEのjavascript実装と同じくらい遅く実行される言語を望む人はいないでしょう。

頑張ってください:D

于 2008-10-11T11:16:00.943 に答える
5

私が最初にキャリアを始めた 90 年代前半の頃は、誰もが独自の社内言語を開発するという熱狂的な流行があったようです。私の最初の3 つの仕事は、これを行った企業でした。ある企業は、独自のオペレーティング システムを開発していました。

経験から、これは次の理由から悪い考えだと思います。

1) その上にあるコードベースに加えて、言語自体のデバッグに時間を費やすことになります
2) 雇った開発者は、言語の学習曲線を経る必要があります
3) 開発者を惹きつけて維持するのは難しくなります専有言語での使用は、誰かのキャリアの行き止まりです

私がこれらの 3 つの仕事を辞めた主な理由は、彼らが独自の言語を持っていたためでした。そして、多くの企業がこのルートを採用しなくなったことに気付くでしょう :)。

私が主張したい追加の議論は、ほとんどの言語には、言語を開発することをフルタイムの仕事とするチーム全体があるということです。あなたは例外かもしれませんが、パートタイムで言語に取り組むだけで、そのレベルの開発に匹敵することができるとしたら、私は非常に驚きます.

于 2008-10-11T14:27:15.753 に答える
5

Nemerle に対する主な不満: コンパイラには恐ろしいエラー報告があり、実装は地獄のようにバグが多く (コンパイラとライブラリ)、マクロは関数内または属性としてしか適用できず、依存関係がかなり重い (ただし、それだけでは十分ではありません)。ディールブレイカー)。

あなたの投稿は 2 年以上前に書かれているようです。今日はネメル語を試してみることをお勧めします。コンパイラは安定しています。今日のブロッカー バグはありません。VS 統合には多くの改善点があり、SharpDevelop 統合もあります。

チャンスを与えれば、がっかりすることはありません。

于 2011-02-08T10:15:13.370 に答える
4

あなたが見た目と同じくらい頭がいいなら (可能性が高い)、私のアドバイスは、先に進んで言語の設計を最初に行い、それを数回反復し、スマートプログラミング言語に関連する信頼できる賢い仲間に尋ねることです。あなたが思いついた具体的なデザインについてコミュニティに参加してから、決定を下してください。

たとえば、デザインを作成する過程で、Nemerle を簡単にハックするだけで必要なすべてが得られることに気付くかもしれません。問題について真剣に考えているだけで多くのことが起こる可能性があり、最終的な解決策は、プロジェクトを開始したときに実際に考えていたものとは異なる場合があります。

最悪のシナリオでは、設計を実際に実装することに行き詰まっていますが、それまでに設計を校正して成熟させ、それが適切な道であったことを高い確率で知ることができます。

関連するアドバイスとして、小さく始めて、絶対に必要な機能を定義し、それを基に構築して残りを取得します。

于 2008-10-11T11:14:50.430 に答える
4

決して独自の言語を開発しないでください。

独自の言語を開発するのはばかげた罠です。さらに悪いことに、想像力で提供できるものに制限され、開発環境と実際に作成しているプログラムの両方を解決する必要があります。

これが当てはまらないのは、Larry Wall や AWK の連中、またはプログラミングの境界をテストすることに専念している相当数の人々のグループの一員である場合です。あなたがこれらのカテゴリのいずれかに属している場合、私のアドバイスは必要ありませんが、タスクに適したプログラミング言語がなく、タスクを実行する人々の特性がないニッチをターゲットにしているとは思えません.

于 2008-10-11T10:54:54.963 に答える
2

自分の言語を書くことは簡単なプロジェクトではありません。特にあらゆる種類の「プロの設定」で使用されるプロジェクト

これは膨大な作業であり、独自の言語を記述しても、それを使用する大きなプロジェクトを記述できるとは思えません。必要な機能の追加、バグの修正、一般的な言語設計などに長い時間を費やすことになります。

私はあなたが望むものに最も近い言語を選び、あなたが必要とすることをするためにそれを拡張することを強くお勧めします。それはあなたが望むものになることは決してありませんが、あなたがあなた自身の言語を書くのに費やす時間と比較すると、それは小さな妥協点だと思います。

于 2008-10-11T10:48:34.790 に答える
2

Scala には .NET コンパイラがあります。この状態はわからないけど。これは、Scala の世界 (JVM に重点を置いている) では二流市民のようなものです。しかし、新しい言語をゼロから作成する代わりに、.NET コンパイラを採用することは良いトレードオフかもしれません。

Scala は、メタプログラミング部門の ATM にやや弱いです。メタプログラミングの必要性は、他の言語機能によって多少軽減される可能性があります。いずれにせよ、メタプログラミング機能を実装したとしても、誰も悲しむことはないと思います。また、コンパイラ プラグイン インフラストラクチャも準備中です。

于 2008-10-11T13:04:31.847 に答える
1

私は、ほとんどの言語がすべての法案に適合することは決してないと思います。

お気に入りの 2 つの言語 (私の場合は C# とScheme ) を組み合わせて、一緒に使用することもできます。

専門家の観点からすると、これはおそらく良い考えではありません。

于 2008-10-11T14:35:18.577 に答える
0

既存の言語ではできないと感じていることを聞くのは興味深いことです。C# では実行できない、どのようなプロジェクトに取り組んでいますか?

私はただの好奇心です !

于 2008-10-11T11:00:12.003 に答える