別の言語の概念をエミュレートすることから、どのような問題が生じる可能性がありますか？

あなたの言語が何らかの概念、たとえばオブジェクト指向、または関数呼び出しをサポートしていない場合、ウェブ上で何度も読みましたが、この他のコンテキストでは良い習慣と考えられているので、それを行うべきです。

私が今目にすることができる唯一の問題は、他のプログラマーがあなたのコードを通常とはあまりにも異なって見つけ、彼らがプログラムするのを難しくしているかもしれないということです。これから他にどんな問題が生じると思いますか？

問題の1つは、他の言語で行う方法で何かを表現するために多くのコードを記述しているのに、使用する言語でより簡単な方法があることです。

たとえば、Stack Overflowの回答では、.NET Frameworkで使用される概念であるコードコントラクトを、それらをサポートしないPHPで部分的にエミュレートする方法を説明しました。単純な配列でも同じことができるので、私は結局何もせずにたくさんのコードを書くことになりました。

より一般的には、各言語には独自の文化、独自のベストプラクティス、独自のスタイルがあります。

• CのようにC＃コードを書き始めると、見苦しくなります。

• Haskellの使用を余儀なくされたJava開発者としてHaskellを理解するが、その長所を理解したくなく、Javaの概念を複製したいだけなら、私が書くコードは苦しむでしょう。

• 等

言語を強化しようとしても何も問題はありません（たとえば、F＃のように測定単位を導入して C＃を強化します）が、やりすぎている場合は、実際にニーズに合った別の言語を選択してください。

読みやすさの低下はそれだけで十分な問題です。それは、あなたからの広範なトレーニングなしであなたのプロジェクトを維持する可能性のある人々のプールを劇的に減少させます。

加えて、

• 外国のパラダイムを実装すると、その使用による潜在的な節約よりも費用がかかる場合があります
• 外部機能の適応にバグがあり、メンテナンスのコストが増加する可能性があります
• 外部機能の適応により、テクノロジスタックがネイティブ実装に必要な限界を超える可能性があります。

紙に書かれているほど良い考えではありません。

例1：あなたが十分な年齢であれば、Cが町の新しい子供であった時代を思い出すかもしれません。PascalとAdaのプログラマーは、Cの簡潔なオープンとクローズの中括弧が好きではありませんでした。彼らは定義しbegin、endブレースを開き、ブレースを閉じ、そして出来上がり！CAda！残念な結果は、AdaまたはCの観点からはfromいものでした。

例2、パーソナル：Common Lisp Object Systemで私が本当に気に入っていることの1つは、メソッドの前、後、および周辺です。それらは複数の場所で非常に便利です。そのため、いくつかの選択した場所でこの概念をC ++でエミュレートしました。これらのコンストラクトをC ++でエミュレートする唯一の方法は、派生クラスの開発者に、コード内の適切な場所で同じ名前の親クラスのメソッドを呼び出すことを要求することです。これは、私のクラスから派生した開発者に、C ++プログラミングとは少し異質で、おそらくC ++プログラミングのグレインに反する要件を課しました。この要件がどれほどよく文書化されていても、人々はガイドラインに従わなかっただけです。なぜなら、それはC ++パラダイムにまったく適合していなかったからです。

別の言語の概念をエミュレートすることから、どのような問題が生じる可能性がありますか？

漏れやすい抽象化。

非常に難しい場合があります。C＃からJavaアプリケーションにLINQを実装しようとしていることを想像してください。または、レキシカルクロージャーを言語に追加するだけではどうですか？新しいコンパイラを作成する必要があります。これにより、新しい言語が作成されます。

または、独自の言語を実装する必要がない場合は、最初にコードブロックまたはラムダ関数またはクロージャーまたは関数を持たない言語で高次関数（mapなど）を使用してコレクションメソッドを実装しようとすることを想像してください。クラスオブジェクト。高階関数はすべてインターフェイスとして宣言し、明示的に実装する必要があり、クロージャーでキャプチャされるすべての状態は実装クラスに明示的に保存する必要があります。それは非常に多くの余分なタイピングであり、読むのが非常に難しいので、しばしばそれは価値がありません。