sumimさんから衝撃の事実が。
余談ですが、たしかに Self にはクラスこそありませんが、フレームワークとして traits (くだんの Traits とまぎらわしいですが…)と呼ばれるクラスと同種の機能を持つオブジェクトがかなり早い時期(すくなくとも '91)から用意されていて、この延長で Mix-in (mixin と呼称) もあります(と言っても、traits との違いは継承ツリーに含まれるか否かだけですが)。Self の mixin の明確な実装時期は分かりませんが、早ければ traits と一緒、遅くとも '94 には Self システムに組み込まれていたようです。
がーん、SelfにはRubyよりずっと前から「Mix-inだけを目的としたエンティティ」が存在していたのですね。 探せば見つかるだろうなとは覚悟していましたが、目の前につきつけられるとやはりショックですね。
しかし、改めて自分がSelfについて無知なことを露呈してしまいました。Selfについては、
くらいしか知識がありませんでした。Smalltalk系は構文的に面白くないので、 あまり興味を持てなかったのですが、やはり、調べておくべきでしたかねえ。
4274065979
以前お世話になったオーム社の編集の方から献本をいただいた。ありがたい。
この本にはずっと縁がなくて
など「すれちがい」が続いていたのだ。
せめて「Matzはまだまだマイナーなんで、Blurbは編集会議で没になりました」とか、 「コメントを求めた次の日からバケーションだったんで、3日後にコメントをもらったのは遅すぎでした」とか フォローがあったら、こんなにいじけないのに。
なんて愚痴っているけど、この本はいい本です。 ハッカーとして成功したいなら、こんな「にっき」読んでないで、この本を読むべきです。
司会とお話の両方が当たる。
司会はもうだいぶ慣れた。問題はお話だ。テーマは「慈愛」、 つまり、神の愛あるいはアガペについてだな。
しかし、愛について語るのは私よりも結城浩さんの方が似合っていると思うのだが (私はどうしてもテレてしまう)、まあ、そういうわけにもいくまい。
で、子供っぽい「条件つきの愛」や「男女の愛」と対比して、 慈愛について考えてみた。うーん、言いたいことが伝わったかどうか。
うむ、できてない。 自分で実践しきれていないことについて語るは、なかなか難しいものだ。
聖書に「心をいれかえて幼な子のようにならなければ、天国にはいることはできない」、 とある(マタイ 18:3)。
ちょうど、身近に幼な子(１才３ヶ月)がいるので、イメージしてみた。
たくさんの、まん丸い頭をしたかわいい子が「にぱっ」と口を開けながら大笑いしている イメージが脳裏にひらめいた。そんな天国に行きたいものだ。
単なる親馬鹿である。
なんか、すごいゆっくりしたペースでブログエントリで対話しているような...。
最上の日々より。
中身が見えない方は、言語が許していないことはとたんに難しくなるけど、これが、まさに私が嫌いな事です。とすると、やはりどちらが良いかでは無くて、ユーザの種類によりけり、ということなんでしょう。
Lisp:S式の理由 なんかも私には関連したテーマに見えます。
それが嫌いな人がいるのはわかります。 別にそれが悪いってわけではなくて、 そういう人にはLispって言語がありますから。
で、Lispでない言語の中身が見える必要があるかどうか、ですが、 (私にとって)重要な点は、日常的なユースケースで不便が出るかどうかです。 つまり、ほとんどの場合では「中身が見える/操作できる」ことは プログラムを書くことと直結しないので、 そのような領域に悪影響を及ぼさないかどうかが非常に重要です。
で、私の知る範囲内で、そのような「中身が見える」系の言語 (たとえばJavaScript, Perl5, Python, Ioが思いつきます)では、 日常的なユースケースの記述が繁雑になる傾向があるように思います。 JavaScriptでオブジェクトの継承や委譲を操作すると とたんにプログラムが難しくなるとか、 Pythonでいつもselfを書かないといけないとか。
私自身は中身を見せないことと、簡潔な記法にどのくらい密接な関係があるのか 断言できるほど考察が進んでいるわけではないのですが、 少なくとも実際の言語を見る限りではかなり正の相関がありそうです。
また、「中身を見せない」方がパフォーマンスチューニングの余地が大きい というのもあります。 もっとも、やることがシンプルな方が高速だったりするのはよくあることですし、 パフォーマンスチューニングの余地が大きいはずのRubyが 他の言語より遅かったりして、 「お前が言うか」というようなレベルなのは恥ずかしいですが (YARVが改善してくれるに違いない)。
この点においてLispってのはやや特殊で、 中身が相当見えるのに、繁雑さはマクロで隠蔽できるという特徴があります。 それはそれですばらしいことですが、 マクロはマクロで、(私にとって)イヤな点があるので、ねぇ。
つい先日リリースされたPrototype.js 1.5の新機能について。
なんかますますRubyに似てきてる。succとか$wとか。
っていうか、この間書きおわった日経Linux 2007年3月号(2/8売り)の 原稿でPrototype.js 1.4について解説したばっかりだったんだけどなあ。 脱稿直後にリリースがあってげんなり。
一般的に思われているのとは異なり、PHPはとても愛されている言語だ、と思う。
なにしろ、私がたまにPHPの良くない点を指摘すると、 たちまちホットエントリになる。またコメント欄にたくさんの反論をいただく。 びっくりだ。
それだけPHPという言語を愛している人やら、 PHPという言語の欠点を公に指摘されると自分自身がけなされたと感じる人が多い、 ということなのだろう。それはそれですばらしい。
しかし、一方で「指摘はもっともだ」というような声も散見される。 言語としての評価は分かれるということなのだろうか。
しかし、PHP使いの反論は、その多くがどうにも噛み合わない。 今後のためにも*1ちょっと分析して記録しておこうと思う。
たぶん、ここのPHPをHSPとかに置き換えても同じことが成立すると思う。
これが一番多い。たとえば、
えーと、幻を読むのは止めていただきたい。そんなこと書いてないじゃん。
どうやら、私はRubyという言語設計者なので 「他の言語を馬鹿にし、自分の言語を宣伝したくてうずうずしてる」という 脳内イメージが形成されているらしい。
が、もう15年も付き合っていて、必要なだけは十分に世間に知れ渡っているRubyを 今さら宣伝しても、私にはなんにもうれしくない。
「人は自分が持つであろう意図と動機を他人に見いだすのだ」と以前聞いたことがある。 とすると、これらの批判をする人たちはもし「自分の言語」を持ったとしたら 全力で他の言語をけなし、自分の言語を持ち上げるのだろうか。 というか、PHPが彼らにとっての「自分の言語」なのか、もしかして。やれやれ。
私は言語オタクとして、さまざまな言語の良いと思うところは良い、悪いところは悪いという 印象を自分の日記に記録する。公開しているんで読みたい人は読み、参考にできると思う人は 参考にする、それで良いと思う。
私がPHPを「イケてない言語」と発言しても、 たかがひとりのプログラマにそう言われただけじゃないか。 それでPHPユーザーが負け犬認定されるわけでもなし、 「そういうところもあるよね」と笑い飛ばせば良いと思う。
そうじゃない？
言語を比較するためには他の言語についてのある程度の知識が必要だろう。 Perlを知らずしてスクリプト言語を深く語るのは難しいし、 Lispの知識なくRubyを深く語ることは難しい。 Pythonは？ うーん、PythonにはPythonの知識だよね(笑)
たとえばPHPしか知らないとしたら、PHPの欠点を指摘されると自分のやり方全体が 否定されたと感じるのではないだろうか。
なんとなく、他の言語も知っているが諸般の事情でPHPを使う、 という人は「批判はわかる」と言っているような気がする。 たとえば「Rauru Blog >> 悪いのはPHP自体じゃないかもしれないけど」とか。例に出して悪いけど。
もちろん、セキュリティホール作りこむ人はどの言語でも作りこむ、ってのは真実ぢゃろう。しかし何と言うかだな、PHP には、そういう人を呼び寄せる(あるいは居付かせる)何かがある、んぢゃなかろうかね。 似たような話として、perl で use strict しない 文化圏 にもそういう何かがあるという気はしてる。
弾さんの 「PHPなめんな」と「(Perl|Python|Ruby)をなめんな」の違い でも指摘されているように 私のPHP批判に怒っている人はあまり外のことを知らないで怒っているような気がするな。
もちろん例外はあるだろうけど。
たとえば「どの言語でも安全でないプログラムは書ける」とかは正論だ。誰も否定できない。 正しいことを断言すると気分は良いだろう。また正論で反論するってことは 相手を間違い認定するのと同義なので、ますます「勝った」感が強くなる。
でも、ちょっと待って？ 反論している相手(この場合は私)は 本当にそんな正論で論破されるようなことを主張しているの？
この場合だと、たとえば「PHPでは安全なプログラムは書けないが、Rubyなら書ける」とか 私が主張していたらこの反論は有効だ。でも、私はそんなこと言ってないよね。
私が書いたのは「Webアプリケーションをちゃんと書くのは難しいから、 Webアプリ向け言語に初心者に優しいという宣伝文句を使うのは良くない」ということである。 ここについては、別にRubyがいいとかなんにも書いてないよね。 また、「どの言語でも安全でないプログラムが書ける」ということと対立もしない。
ついでに言うと「どの言語でも安全でないプログラムが書ける」ということと、 「どの言語でも安全なプログラムを書くのは同じくらい難しい」とは まったく違う。でも、このふたつが同じことのような印象を与えがちだよね。 これって詭弁だと思う。
ここからはRubyの宣伝にもなっちゃうんでエントリを換えよう。
*1 今後もPHPの欠点を指摘するつもりなのか
最初に繰り返して明言しておくが、 どんな言語だろうとなにも考えないで完全に安全なWebアプリケーションは書けない。 が、脆弱性を作りにくい言語(およびフレームワーク)機能というのはありえる。 たとえば
安全なメモリ管理
Cのような生のメモリ領域を使い、実行時の範囲チェックを行わない言語では 容易にバッファオーバーフローが起きる。RubyやPHPのように言語自体がメモリ管理を 行う場合(バグがない限り)安全。
パラメタ処理などの抽象化
ミスによる脆弱性を起こしがちな、 環境変数や標準入力からデータを切り出してくる処理やクッキー処理を手動で行わない。
テンプレートシステムによる出力
インジェクションなどの原因となる生の文字列操作でHTMLを構築することをできるだけ避ける。
ORマッパーによるデータベースアクセス
インジェクションの原因となる生の文字列操作でSQLを構築することを避ける。
データフロー追跡
RubyやPerlでは外部から入力された文字列にtaint(汚染)と呼ばれるマークがつく。 taintされた文字列から加工された文字列にもtaintがつく。 これをチェックすることで外部からの入力をチェック(サニタイズ)しないまま 危険な操作(ファイル名にする、systemを呼び出す、HTML/SQLに埋めこむ、など)を 禁止することができる。
落とし穴の多寡
たとえば、バイナリセーフ関数かそうじゃないかの違いのような 「落とし穴」に対して開発者が無関心かどうかは、最終的なプログラムの安全性に 影響する。言語ユーザが気をつけなくちゃいけないことも増えるしね。
もちろん、PHPでも各種フレームワークなどを最大限活用することで、 上のような機能を揃えることもできるだろう。そもそも「できない」って言ってるわけじゃない。 でも、CGI向け各種機能がビルトインされていて
htmlspecialchars($_GET['text']);
とかを普通にやっちゃう(しかも、それがゆえに初心者に優しいとかされてる)環境で 安全なソフトウェアを書くのは、他の言語に比べて大変困難であろう。
なんか間違ってる？