* セキュリティキャンプ2017 の応募用紙からいただいた意見について
-(by [[K]], 2017.06.05)

** (0) これはなに？
-セキュリティキャンプの応募用紙から、Essenに対してたくさんの感想や批判的意見や提案をいただきました。すごく参考になりました。大変ありがたいことです！
-そのうちの多かったものについて、紹介させていただきます。

** (1) コンマを省略可能にしたことに対する批判
-「コンマが省略できることは基本的に悪くないけれど、マイナス符号がある場合はコンマを省略できないなんていうのは、仕様として汚いのではないか？そんなことならコンマ必須とすべきではないか？」

-うーむー。まあその指摘は正論だと思います。
-じゃあ、負の数の前に0 を置くのはどうですか？ そしたら -2 が 0-2 になって、ひとまずコンマは省略したままにできますよね？・・・いまいち？？
-まあマイナスの数はこの仕様と折り合いがよくないのは認めます。しかし、プラスの数しか記述しないと絶対に分かっている文脈でも、現在のほとんどの言語ではコンマを強要されますよね。それがコンマなしも選べるようになっていると思えば、それは悪くない話なんじゃないかと私は思います。
-元々この仕様は、コマンドラインでは引数がスペース区切りになっており、それを真似して書けるような言語は作れないだろうかと考えたのが発端です。カンマをなくしたいとうわけではないです。書きたいときは書けばいいのです。
-一つのことに対して書き方が複数あるのは柔軟でいいことだと思いませんか？一貫性がなくて美しくないと考えることももちろんできますが、文脈や状況に応じて適切な記法が使えるというのは、そんなに簡単にあきらめていい理想ではないと私は思います。
-どうしてもいやなら、常にコンマは省略しないで書けばいいでしょう。それでなんにも悪くないです。その代わり省略している人を見つけて文句を言ったりはしないでくださいね。
-プログラミング言語の一つの方向性として、できるだけ数式に近づけるという方向性があると思いますが、数学でも行列などでは数の区切りにいちいちコンマを付けたりはしていません。それに似せているだけだとお思いください。

** (2) 計算値キャッシュに関する批判
-「キャッシュを作ればそれが永続化されてずっと高速でいられるって言うのはいい話だと思うけど、一方で危険じゃないか？純粋な計算だけじゃなかったら、それが正しく機能しないことにならないか？純粋な関数かどうかを判定する仕組みがあればいいのでは？」

-もし、よく考えずに、なんでもかんでもキャッシュしてしまえっていうことであれば、まさにその問題は起きると思います！・・・だから私はその立場をとりません。
-Essenが目指すのは、キャッシュしたいときに手助けしてくれる存在であることです。
-その関数をキャッシュすべきかどうか、それはプログラマが決めることです。Essenが決めることではありません。
-そもそも仮に副作用のない純粋な関数だったとしても、キャッシュをすべきかどうかは悩ましいのです。利用頻度が高く、同じ引数での呼び出しが多く、その上計算が重たい関数でなければいけないのです。そうではないものをキャッシュしてもメモリを食うだけでいいことがありません。
-画面表示などの純粋な計算以外の命令が混ざっていたらキャッシュ禁止にすべきか？・・・それはいいアイデアだと思う反面、もしかしたらその画面表示はデバッグのために一時的に入れたものかもしれず、だからそれをもってキャッシュ禁止であると決めつけるのはやっぱり違う気がします。

** (3) 構文や演算子の拡張についての批判
-「自由な構文の拡張や演算子の追加変更を許したら読みにくいだけなのでは？」

-この意見はいい指摘だとも思いました。なぜなら私はこの指摘にもかかわらず、自由な構文の拡張を許したいと思うからです。なぜこの指摘に共感しなかったのか、それを考えているうちに自分の立場が分かりました。
-私はそもそも読みやすい言語を目指してはいなかったのです。書きやすい言語だけを目指していたのです。

-そもそも読みやすい言語って何かと言えば、言語側でそれなりに厳格なルールがあって、それに従っている限り自然に読みやすくなるような言語を指していると思うんです。
-一方で自由な言語は、制約をできるだけ少なくしようとするので、読みやすくなるかならないかは書き手のスキル次第になります。
-たとえばC++では演算子のオーバーライドができますが、演算子は割り算なのに実際にやる処理は引き算だったり、掛け算なのに実際は足し算だったりとか、足し算と引き算が逆だったりとか、そういうことだってその気になればできます。それはけしからんかもしれませんが、でも文脈によってはそのほうが便利かもしれないのです。

-私は何か制約を与えることが好きな性分ではなく、自由が大好きです。そのせいで混乱が起きたり収拾がつかなくなることはあるかもしれませんが、でもそこから生まれてくるものだってあると思うんです。あれもだめ、これもだめって言われたら、まあ確かに安全かもしれないけど、それは牢獄の中の自由ですよね。私は自己責任でもっといろいろできる言語がほしいのです。

-そういえばC言語はビット演算とか絶妙なポインタ操作とかそういうプログラミングテクニックがあります。それらは「読みにくいからけしからん」ものなのでしょうか？・・・まあそういう考え方も一理あります。そんな絶妙な書き方をしなくたって今のコンパイラなら最適化でどうにでもしてくれるかもしれません。だったら分かりやすいほうがいいかもしれません。でも人によっては、ビット演算をそのまま書くほうがすっきりするというか、分かりやすいと感じる人もいるのです（最適化が信用できないとか）。そういう人にはそう書いてもいいことにしてあげればいいじゃないですか。そういう話です。


** (4) 並列処理を支援したらいいのではないかという提案
-「なんかちょろっとアノテーションを付けるだけで並列処理ができるような言語こそ、望まれているのではないか？」

-ご指摘はその通りだと思われます。
-でも私はEssenをそういう言語にはしない予定です。
-どうしてかというと、並列処理は本当にややこしい問題がたくさんあるからです。ということで、EssenはCPUのコアがいくつあっても基本的にシングルコアでしか動きません。つまり同時に複数の命令が実行される状況は想定しません。でも、適当なタイミングでプログラムが切り替わる「疑似並列処理」はサポートします。なぜなら、これは非常に有用だと私が思うからです。
-本来のマルチコアによる並列実行は、速度向上のために行われます。私が目指している疑似並列実行は、速度向上には寄与しません。結局シングルコアでしか動いていないからです。
-でもプログラムAが長い数値計算をしているときに、別のプログラムBからプログラムAの変数を参照して挙動を確認できたら面白いと思いませんか？それができれば、デバッグだってすごくはかどりそうです。
-つまり処理速度のための並列処理ではなく、開発効率向上のための並列処理なのです。
-真の並列処理は、アクセス競合などでややこしいバグの温床になります。それはプログラミングが嫌いになってしまうリスクがあると思い、あえてできなくしてあるのです。まあ速度で一番を目指しているわけではないから、これでいいかなと思っています。
-真の並列処理は、アクセス競合などでややこしいバグの温床になります。それはプログラミングが嫌いになってしまうリスクがあると思い、あえてやらないことにしてあるのです。まあ速度で一番を目指しているわけではないから、これでいいかなと思っています。


* こめんと欄
#comment
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS