DSLの間違ったアプローチ

Scalaのような、既存vmに相乗りした言語や言語内言語の間違ったアプローチ

既存vmに相乗りした言語

既存vmに相乗りする場合、そのvmがOSの用に汎用マシンとして設計されていれば問題ありませんが、jvmがJava用のvmであるように何かの言語用のvmとして設計されている場合、直接jvmのバイトコードを生成したり、クラスを生成する方法は間違っています。

jvmバイトコードを生成している場合は、ローカル変数フレームを内部処理用に予約しておく等の特殊な事ができるため、言語仕様によってはJavaを超えることができる可能性があります。しかしJavaコンパイラの行っている最適化の恩恵は受けることが出来ません。

しかし、所詮プリプロセッサです。これはCコンパイラのC++プリプロセッサとは意味が異なります。jvmは仕様を見てもJava用のvmであることは明らかです。ACC_PUBLIC、ACC_PRIVATE、ACC_PROTECTED等とは別のアクセスフラグを作る為にはそのためのJavaのコードが必要になります。

jvmネイティブの処理はJava用の処理です。jvm用のバイトコードを作ることは、バイナリを作るのとは意味が異なりJavaの仕様の制約の中で処理を行う必要があるため、結局はJavaで書く方がパフォーマンスが高くなります。

他の言語用のvmを使用している限りパフォーマンスが必要になるような汎用言語を目指す事は間違いです。

シンタックスの違いしか無い言語

主流になっている言語に無駄なシンタックスは無いと思った方が良いです。そのシンタックスを変更するという事は、何かの機能が失われたり、他のシンタックスに影響が出ます。

ありがちなのが、変数の型宣言を省略できるという機能ですが、そのために変数の宣言用のvar等のたのシンタックスが必ず必要になります。全てはトレードオフです。

元言語より全てにおいて優れているシンタックスは作れないのです。そのためDSLはWEB、ゲーム、シュミレーション等の用途に限定し機能的に優れていなければ、存在価値がありません。

しかし、これもライブラリを作ればで十分では意味がありません。そのライブラリを使う上での特殊なシンタックスが必要になって初めて言語とする必要があるのです。