PHP/HTML/CSS/JS/Flash → C#/Java/Ruby → C/C++ な話題を見ると、時代はかわったんだなぁとか思います。その順番で学ぼうとすると、応用→基礎な流れになり、どんどん派手さが無くなるので、自宅勉強だと長続きしないんじゃないか? と余計な心配も
読んでいて、ふと、こんな事を思いついた。
N88BASIC → C → アセンブリ な話題を見ると、いやはや時代は変わったものですて。その順番にて計算機を学ぼうとすると、応用→基礎な流れになり、どんどん派手さがなくなるので、フローチャートが書けなくなるのではないか? と余計な心配も致しますわい。
第一、ワシらの若い頃は、コンピューターを自作して、トグルスイッチでメモリ番地と値を指定して入力したか、あるいはパンチカードに穴を開けたものじゃて。パンチカードを物理的に切り貼りするから、パッチ(Patch)というんじゃ。最近の若い奴らは、キーボードと文字を表示するディスプレイで入力しよる。いやはや、恵まれすぎているのう。そんな軟弱な入力装置では、コンピューターの本質的な動きが分からないではないか。
バベッジ&エイダ「コンピューター? 「計算をする人」とはどういう意味だ。それは我々の言うところの、階差機関のことか?」
パスカル「おまえらのたどっている道は、オレが300百年前に、すでに通過した場所だマヌケ。」
エジプトのパピルス「最近の若い者は・・・・・・・」
今も昔も、そんなに変わっていないだろう。例えば、遠い将来に、ASCIIや、Shift-JIS、UTF-8、UTF-16といった、マルチバイト文字エンコーディングが絶滅して、過去の資産としても価値がなくなったとしよう。皆、UTF-32、あるいは、未来の規格で文字をエンコードしているとする。そういう未来において、「昔はマルチバイト文字が主流であり、一文字が何バイトか、実際に解釈するまで分からなかった。今の若者は、そういった泥臭いアルゴリズムを知らない。それでは文字列処理の本質が理解出来ないだろう」、などと言ったところで、誰がまともに相手をするというのか。ただのジジイの昔語りではないか。
あるいは、こんな話もある。
「仰天もののディスケット」にはちっとも仰天しないという話 - やねうらお-よっちゃんイカを食べながら、しばし休息しよう。
例えば、SHARPのX1シリーズはクリーン設計のため、BIOS/ROMに相当するものがなかったのです。それゆえ、IPL(=Initial Program Loader≒boot loader)がテープメディア or FDDからプログラムを読み込んだあとは、自力で(BIOSの力を借りずに)floopyにアクセスする必要がありました。
市販のソフトを出すならば、途中loadするタイプのゲームは、かならずFDDアクセスルーチンは自前で持っておく必要がありました。
つまり、当時の商用ソフトを出している誰もが、FDCにアクセスして、floopyを回転させ、seekして、index holeを検出して、1セクタ読み出す/書き出すというプログラムを書いたわけです。
この話をひいて、現代のJavascriptプログラマに、「昔はBIOSに頼らずに、フロッピーぐらい自前で読み書きしたものだ」などと講釈を垂れても、一体誰か能く聞くというのか。
Unicodeだってそうだ。たしか、PHPか何かの言語で、UTF-16化を、メモリの消費量が増えるというワケの分からない理由で断念したと聞く。これは大方、コケイジョンの無知と無理解とに基づくものであろう。第一、UTF-8では、ほとんどのCJK文字は、3バイトを消費する。我々日本人にとっては、UTF-16が、現時点で、最も現実的にメモリ消費量の少ない文字エンコードなのだ。
私などは、さらに一歩を進めて、UTF-32でエンコードすべきだと考えている。UTF-32ならば、サロゲートペアの心配すらない。たしか、UTF-32であっても、異字体セレクタというものが存在した気がするが、それは、まあ、知らなかったことにしておく。世の中は常に最良の選択が行われるわけではない。
マイ・コンピュータをつくる―組み立てのテクニック (1977年) (ブルーバックス)
3 comments:
異体字セレクタを知らなかったことにするだけで済むと思ってるなら文字コードをナメてるとしか言いようがありません。まあwchar_tの1つ=1文字ということになってるC/C++の規格そのものが文字コードをナメてるんだけど。
文字というのは、過去数千年の歴史があるので、まあ、難しいものですね。
結局、UTF-32エンコーディングでも、固定幅文字が実現できないとすれば、まあ、wchar_tは文字コードをナメていると言えます。
しかし、C++の規格の制定作業が行われていたあの当時、何か具体的な文字のエンコーディング規格に言及するのは、不可能でした。
まだ、Unicodeも、うまくいくかどうか未知数でした。
とすれば、charに加えて、もうひとつ実装依存なwchar_tという型を導入するのは、あの当時の精一杯の努力だったと思いますよ。
> PHPか何かの言語で、UTF-16化を、メモリの消費量が増えるというワケの分か
> らない理由で断念したと聞く。これは大方、コケイジョンの無知と無理解と
> に基づくものであろう。
いや、これはちゃんと技術的根拠のある話ですよ。
もし PHP が PHPの世界だけで閉じていれば UTF-16 という選択肢もあったかも
しれません。しかし、実際にはそうではないのです。http では UTF-8 が
通ることは期待できても UTF-16 は期待できませんし、UNIX系 OS のシステム
コール・インターフェースも、マルチバイトのインターフェースはあっても
wchar_t や UTF-16 のインターフェースはありません。UNIX 系 OS 上の
ライブラリも、マルチバイトかあるいは wchar_t の API です。UNIX 上では
wchar_t は 4バイトが一般的なので、wchar_t は UTF-16 とは確実に異なる
表現です。テキストファイルの表現としても、UNIX 上では UTF-16 は非常に
マイナーです。
結局、もし UTF-16 を採用すると、UNIX系OS上の PHP実装では、外の世界との
ありとあらゆるインターフェースで変換が入ることになり、かえって効率が
落ちるでしょう。
Post a Comment