CoffeeScriptは、Rubyに触発された、きれいな構文でJavaScriptに変換する言語です。Cにトランスパイルして、パフォーマンスを犠牲にすることなく、より読みやすいコードを可能にする同様の言語はありますか?そのようなものが存在しない場合、それを作成しない正当な理由はありますか?
CoffeeScriptは、Rubyに触発された、きれいな構文でJavaScriptに変換する言語です。Cにトランスパイルして、パフォーマンスを犠牲にすることなく、より読みやすいコードを可能にする同様の言語はありますか?そのようなものが存在しない場合、それを作成しない正当な理由はありますか?
回答:
CoffeeScriptは非常に単純な理由でJavaScriptにコンパイルされます。JavaScriptは事実上のクライアント側の言語であり、ブラウザーベンダーがCoffeeScriptをネイティブにサポートすることを期待するのは不合理です。
ほぼ同様の方法で、ほとんどすべてのプラットフォーム用のCコンパイラーと豊富なCライブラリーがあるため、C言語翻訳者にとっての高水準言語の主なポイントは即時の移植性です。たとえば、Valaは次のように設計されています。
GNOMEは伝統的にC指向のプロジェクトであり、GObjectは特にCで書かれています。Valaは、より親しみやすい性質(および構文)に関係なく、マシンコードにコンパイルした場合、GNOME開発者の間であまり愛されないでしょう。別の言語であるGenieがそれを改善するために構築されたという点まで、誰もが構文を好むようには見えませんでした。
C ++の例として、Facebook はPHPからC ++へのトランスレーターであるHipHopを開発しました。彼らは、PHPコードをすべて置き換えたり、エンジニアを再訓練したり(最悪の場合は置き換えたり)することなく、非常に具体的な問題であるCPU使用率を解決しようとしていました。これははるかに具体的な例です。Facebookの拡張性の問題は非常に独特であり、PHP拡張機能はCおよびC ++で作成されているため、中間C ++コードにアクセスできることも有用です。
したがって、中間コードへのアクセスが必要な場合は、ほとんどの場合、高レベル言語から別の言語への翻訳者がお勧めです。CoffeeScriptの場合、ブラウザーの幅広い採用のためにJavaScriptコードが必要であり、Vala、GenieおよびHipHopの場合、既存のコードベースのために必要です。明らかに中間コードにアクセスできるということは、必要に応じてさらに最適化できることを意味します。
しかし、一般的に言えば、結果のコードを使用していない場合、Cまたは他の言語に翻訳する言語を作成することは、あまり良い考えではありません。Cに対処できない場合は、他の言語を選択してください。偶然にも、Bjarne Stroustrupによって書かれた最初のC ++コンパイラであるCFrontは、クラスからCへのトランスレータを持つCでしたが、それは主に、新しい言語として、クラスでC をブートストラップすることが不可能だったためです。
ヤンニス・リゾスがそうでなければ素晴らしい答えにならなかったいくつかのポイントをカバーするつもりです。
はい、多くの言語が存在します。Cは非常に移植性が高く、高度に最適化されているため、コンパイラバックエンドの一般的なターゲットですが、LLVMではあまり意味がありません。
私がこれを行うことを知っているいくつかの実装は次のとおりです。
元のCプログラムと同じくらい高速
いいえ、Cを中間言語として使用しているからといって、その速度に達するとは限りません。Cが高速である理由は、他の言語では明らかに異なるコードの記述方法のためです。それは単なるポータブルアセンブリであり、特別なものではありません。
OCamlは、バイトコード、ネイティブコード、直接解釈、またはCにコンパイルできます。