M12i.

学術書・マンガ・アニメ・映画の消費活動とプログラミングについて

あらためてPHPの言語仕様をかじりかけ・・・

率直に言ってPHPRubyに次いでうんざりな言語なのだけど(Rubyに先んじてうんざりなのはVBScriptかな)、機会は機会として、久しぶりにPHPの公式リファレンスを読みかけた・・・が、すぐに挫折した。

たとえば、以下のような記述を読んで愕然としないユーザはいるのだろうか:

PHP マニュアル > 言語リファレンス > 型 > 文字列

string は、文字が連結されたものです。PHP では、 文字は 1 バイトと同じです。つまり、256 個の異なる文字を使用可能です。 これは、PHPUnicode をネイティブにサポートしていないことも意味します。 文字列型の詳細を参照ください。

注意: 文字列の最大長は 2GB (2147483647 バイト) です。

公平を期すために言うと、たしかにちょっと前までスクリプト言語の世界ではどの言語も状況は似たり寄ったりであった。

Pythonはバージョン3.0以前にはすくなくとも文字列リテラルとしてUnicode専用の構文を使わなくてはいけなかった。つまり len("あいうえお") は 15 で、len(u"あいうえお") は 5 だった。しかしいったんオブジェクトが生成されれば実行環境は非UnicodeUnicodeを自動変換していた。

ある意味でPHPより残念な話題として、Rubyは当初、その開発者の出身から想像されるところとは正反対に、標準ライブラリが文字列をあくまでASCIIとして扱う実装だったために、その対策としてユーザコミュニティが(Rubyの「柔軟性」を活用して)標準ライブラリを独自に拡張するという状態だった。

まあしかしそれやこれやも今は昔。PHPに話を戻すと前述のような仕様が2013年12月執筆のドキュメントに明記されている。これだけで、読者(私)のこころのどこかにぽっかり穴が開いてしまったのはしかたのないことではないか。mbstring関数群を見てうんざりしないプログラマは少々寛大に過ぎる。

その他、細かな点では「配列」がJavaScriptのそれのごとく「得体の知れない何か」(少なくとも名が体を示していない)であったり、TRUE|FALSEがなぜか大文字小文字を区別しなかったり、匿名関数・高階関数関連で似通っているのに異なる概念が次々導入された結果複雑な様相を呈していたり・・・。

そういうわけで数時間で挫折していまはPythonのリファレンスを読んでいる。