W です。

Yukihiro Matsumoto wrote:

>「良い言語」の「良い」とはどんな性質でしょう。
>
Perl プログラミング（らくだ本） 7.4 "効率の問題"(私の持っているのは
Perl4用なので Perl5 の本では章は変わっているかもしれませんが…） が、

	時間の効率を上げるためのヒント
	空間の効率を上げるためのヒント
	プログラマの効率を上げるためのヒント
	保守する人の効率を上げるためのヒント
	移植する人の効率を上げるためのヒント
	利用者の効率を上げるためのヒント

を挙げてます。これに２つほど追加し、「効率を上げるためのヒント」を「生産
性」とか「満足」に代えると、

a) 時間の X
b) 空間の X
c) 言語作成者の X
d) プログラマの X
e) 保守する人の X
f) 移植する人の X
g) 利用者の X
g) マネジメントの X
(ここで X = 効率を上げる、生産性を上げる（効率と同じか？）、満足を上げ
る、など）

とすると、既存の言語がどれに重点を置いているかの比較が分かり、今後の「良
い言語」を考える上でのヒントになりはしないかな、と。例えば、

「俺言語」は c) を重視し他は余り重く見ない
Cobol は e), を重視（異論あるかもしれませんが）
Perl は d), c) 重視で、e) は全く軽視？？
C言語は a), b), d), f) 重視。e) はかなり軽視。
フローチャートを描くとそれがプログラムになる、というツールはどうみても
g) 向けで d) 向けではない

などなど。Ruby は書きやすい・読み易い、という点で d), e) 重視、a), b) は
２の次、でしょうか（使ったこと無いので勝手なこと書いてます。すみません）。

すべてを満足させれば良い言語なのでしょうが、そうも行かない。

#ソフトウェアサイクルのうち開発にかかる工数が 20% ほど（？）で大半が保守に
#コストがかかっているとすれば e) をより重視すべきということになりはしな
いか、と。
#そういう意味で Cobol は正しかった？

議論の１つの叩き台になるかと思い書いて見ました。異論はあるかもしれません
が、まあこういう見方も出来る、ということで。

>私は某所で「２１世紀にもなるのにこんな言語(HSP)はないだろう」
>などと書きましたが、実際、良い言語の基準ってのはさまざまな気
>がします。HSPだって開発している人やその周辺は「良い言語」だ
>と思ってるでしょうし。
>  
>

2) 確かに HSP は言語としてみれば 30年前の GOTO 付き BASIC、という感じで
すが、HSP の本やサイトを見てまず思ったのは、GUI (主にゲーム系）が簡単に
書ける点。これで初心者を惹きつけている、と思いました。思い起こせば、私も
ゲームが出来る、というのがプログラミングの強い動機だったな、当初は。この
点、Ruby Tutorial は、ちょっと高踏的な印象を受けました。まず視覚に訴える
という点で HSP は普及している、と思った次第です。

3) あと、「プログラミング言語 Turing(湯浅太一監訳)」 (Turing マシンじゃ
ないです。 --知ってる人いますでしょうか？まつもとさんは確か Ruby の
mailing-list で Turing からも影響を受けたことをちらっと触れられていたよ
うな気が…）の第２章「Turing言語の設計目標」など大変参考になるのですが、
でも Turing はあまり広まっていない。フリーではないからか、それとも他の理
由があるのか。同じ理由なのか、理想的（だったはずの）OO言語 Eiffel もなぜ
か広まってない。

2) を考えると、ゲーム系周辺ライブラリが必要そう、とか。
3) は何なんでしょうね。社会学の領域なんでしょうか？「構想１０年の大作映
画」がコケ易いのに似たことが起きたんでしょうか。

// W




--
ML: langsmith quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml