「論理的」なものから「論理的」なものへの変換は自動化できる?

これは、すべての場合ではないですが、可能です。
例えば、CコンパイラC言語アセンブリに自動的に変換します。SQLを処理するJavaプログラムもあります。TomcatのJasperはJSPJavaコードに変換します。
転記・論理積論理和・条件分岐ができるプログラム言語であれば、どんなプログラム言語のエミュレーションもできます。
ということで、「論理的」なものから「論理的」なものへの変換は可能です。


ただし、一般に、そうやって自動生成したプログラムは「読みづらい」です。というよりも「読むに耐えない」です。
なぜなら、「意図」が反映されないからです。意図は「非論理的」だから。
どうしてそうなるかというと、「論理体系は何も語らない」からです。プログラム言語の構文規則というのは「論理体系」です。
つまり、例えば「クラス定義の後にextendsと書ける」という言語規則があるとしても、継承の概念を表しているわけではないということです。
JButtonはJComponentを継承しますが、なぜOutputStreamを継承していないのか、なぜPreparedStatementインタフェースを実装していないのか、ということは構文規則からはわかりません。というより、構文上は、JButtonがPreparedStatementを実装していたとしても何の問題もありません。
「論理的」な記述では「意図」があらわせません。あらわせるのは事実だけです。もともと「意図」があらわせないので、変換結果はまったく意味不明になってしまうのです。


もうひとつ、大切なことがあります。
「論理的なもの」を別の「論理的なもの」に変換する「論理的なもの」は自動的には作れないのです。
構文規則を与えればそのプログラム言語からアセンブラに変換するプログラムを、自動生成することはできません。
これも「論理体系は何も語らない」からです。
構文規則は、概念をあらわさないからです。概念は「非論理的」です。「論理的なもの」の変換には概念の理解が必要になります。
extendsの構文規則が継承の概念を表すものではないということです。


このことから、いくら論理的な仕様記述を実現したとしても、その仕様からプログラムへの変換は自動的には行えないか、自動生成したプログラムは理解不能ということになります。
理解可能なプログラムが自動生成できるような仕様記述というのは、表現方法が違うだけの同じ言語にならざるを得ません。
プログラミングで、作業量を減らすことはできても、考える量は減らせないということになります。