(恐怖のプログラムネタ) VT100
2008年01月02日21:34
僕は今 TELNETサーバーというものを作っている。 TELNETサーバーっていうのは、今のインターネットでなくてはならないサーバーだ。 これが無かったら、全てはない。 そんな超基幹サーバーだ。 TELNETというのは 40年近くも前に定義された古いプロトコル(通信規約)で、ほとんど最古のプロトコルと言ってもいいものだ。 長い年月を経て研磨されて完成されており、シンプルでありながら非常に高性能だ。 しかし、誰もが必要としている超重要プロトコルでありながら、あまりに目の前にありすぎて忘れ去られているプロトコルともいえる。
普通はみんなそういう物は作らない。 だけど、そういうものを敢えて作ってみると色々わかることがあるだろうな、と思ったので作り始めた。 というか 探してみたら意外と誰も作っていなかったし、まぁ自分で作ってもシンプルだからそんなに大変じゃないだろうと思っていたのもある。 でも実際に組み始めたらとても難航した。 久しぶりに行き詰まった。 散々悩んだ挙句、そもそもやり方が間違っている事に気がつき、一週間分の作業を全部捨てる必要に迫られるという大失態をやらかしてしまった。 何故こんなに完成されシンプルでお手軽なのに、いろいろな人がTELNETを再利用したがらないのかだんだんわかってきた。
僕がパッと気がついたことのひとつに、カーソルの動きの互換性の低さがある。
説明を始める前に ... そもそもTELNETというものを見たことがあるだろうか。
telnet://towel.blinkenlights.nl/
黒い画面に文字が出てくるだけのソフトだ。 昔はこれを使ってコンピューターを操作した。 これは今のWindowsのような グラフィカルなインターフェースがメジャーになる以前の キャラクターユーザーインターフェースと呼ばれていたものだ。 絵は一切なし。 全ては文字で指定する世界。 ややこしい記号が並んでいるので面食らうけども、GUIで操作するのとくらべて曖昧さが無くて、むしろ CUIで作業したほうが効率が良いくらいである。 クラシックだなぁ... と思うなかれ、今でも現役でバリバリ使われている。 特に mixi の様なインターネットサーバーを管理する時は必須のソフトだ。
実はこのTELNET、元々「テレタイプ」と呼ばれるものだったらしい。 テレタイプにはキーボードがついており、キーを押すとどのキーが押されたのかをデータに変換しネットワークを通じて送信、受信したサーバーはプリンタにポチと一文字印刷... そういう極めて原始的な機械から始まったようだ。 こうして TELNETは進化を始めた。
http://ja.wikipedia.org/wiki/%E3%83%86%E3%83%AC%E3%82%BF%E3%82%A4%E3%83%97%E7%AB%AF%E6%9C%AB
このプリンタは、時代と共にテレビになってしまった。 キーボードを押すと、地球の裏側にあるテレビに一文字表示 ... しかしそれでは打った人が見えないので意味がないかもしれない。 しかし、この機構を遠隔地にあるサーバーの管理に使えないか、と考えた人がきっといたんだと思う。 逆転の発想で、テレビは地球の裏側ではなくキーボードの隣に置いておくことにした。 キーボードを押すと、地球の裏側においてあるサーバーに一文字送信。 サーバーはその一文字をそのまま送り返し、ユーザーの面前にあるテレビに一文字表示する。 これは革命的だった。 これによって、プログラマはいちいちサーバーが置いてある建物まではるばる出かけていく必要が無くなったのだ。
この発想の切り替えには素晴らしいものがあると僕はおもう。 さすがアメリカ人。 こうやって40年以上前に出来たソフトが今でも使われているというのは、考えてみれば驚異だ。
◇
というわけで、これは遠隔操作のメモ帳の様なソフトだ。 だから、メモ帳の様にカーソルというものがある。 キーボードを押すと、このカーソルの位置に文字が表示されるようになっている。 でもユーザーが見ているカーソルの位置と、サーバーが思っているカーソルの位置が違っていると正しく表示されない。 これは「福笑い」のようなものだ。 サーバーは正しく目鼻の位置を置いているつもりなんだけど、肝心の顔の位置が全然思っている場所と違ってしまえばメチャメチャな顔になってしまう。 この福笑いの再来の様な状況が発生する。
普通は、このカーソルの位置が狂うなんてことは、ないだろう... と思うのだけど、これが狂うのだ。 TELNETは 40年の年月のうちに、今では考えられないような信じられないような使われ方をしてきており、その間にその信じられないような使われ方をするなかで、プログラマが目先のことだけを考えた勝手な独自機能を追加をしているのだ。 こういう独自機能は、あとあと長い年月にわたって後続のプログラマを苦しめ続ける。
僕が気がついたのは、画面の右端でキーを押したときの動作だ。 このとき普通なら、カーソルは左端に自動的に移動するだろうと思うのだけど、これが移動しないのだ。 次の一文字を押した時初めて次の行に移動する。 カーソルの位置は同じなのだけど、次に入力される文字の場所には2種類あることになる。
この動作がとても曖昧だ。 だって、最後の一文字を入力して←キーを押した時カーソルはどこに移動すればいいの? その答えは、プログラマによって違うわけで、実際今利用されているターミナルソフトでも実に千差万別の実装がされている。 要するに、今から新しく作るプログラムは、この画面右端で折り返す動作に依存しないようにプログラムを組まなければならない。 これがとても面倒だ。
僕はさっと現状で利用されているラインエディタ(BASH/KSH/ZSH/VIM程度)が取っているこの問題の対応を調査してみたが、実に色々な方法をつかってこの問題を回避していることがわかった。
僕は思うんだけど、この問題さえなければ、TELNETはもっといろいろな人に再利用されていると思う。 手軽でポータブルな遠隔操作ツールとして今でもどんどん再利用されていたのではないだろうか。 しかし、この問題があるために、TELNET用のプログラムを作り変えるのは容易ではないのだ。
もちろん色々な人がこの困難を解決しようとがんばっている。 実はこの問題を解決するTERMCAPやCURSESという有名なプログラムがあるのだけど、これら自体もとても複雑なソフトで手軽には作り変えられない。 使い方もカンタンではない。
僕は思うのだけど、TELNETは、この問題さえなければここまでは事態が悪化しなくてもすんだはずではないだろうか。 恐らくこの問題を修正しようとするのではなく、新しい技術を使ってさっさと新たに作り直してしまえば1年もかからずしてもっと良いプロトコルが出来ると思う。 でも誰もそれをやらない。 しちめんどくさいカーソルの問題と共に生きている。 それが新たなプログラマの侵入を阻んでいる。
歪んだものの上に物を作るとそれも歪む。 これは基本中の基本中だと思う。
だけど、繰り返し繰り返し行われている。
全てを捨てて新しく作り変える勇気。
◇
こうやって長期にわたって偶発的に発展してきたTELNETプロトコル。 だけど、僕はもう寿命なのかなと思っている。
TELNETプロトコルの上には SHELLと呼ばれる巨大な一枚岩が乗っかっている。 更にこの上に今のUNIX文化を形成しているあらゆるプログラムが乗っかっている。 TELNETプロトコルがいかにまずくてもTELNETを捨てるという事は、これら全てを捨てるということであり、大変な勇気が居る... というかもうほとんど無理なんだと思う。
しかし 世の中はユニコードの時代だ。 ユニコードが通らないというのは、とても不便な事だが、これらのUNIXソフトとユニコードはかなり相性が悪い。 もちろん一時に比べたらとてもよくなってはいるけど...。
アメリカには文字が26個しかない。 だからデータが1byteあれば、それは必ず一文字だった。 そういう文化だった。 日本人はそこにもう一バイト追加した。 2バイトであれば、必ず2文字の幅で表示されるという、PC-9801が築き上げた巨大な文化をそこに形成した。 そこでも1byteは1文字という暗黙の了解があった。 しかし、今、その前提は根本から崩れている。
ユニコード化によって日本の文字はほとんどの場合 1文字3byte になってしまった。 今受け取った1byteが 何文字の幅なのかを知る方法がなくなってしまったのだ。 これはとても厄介な問題だ。 僕の大好きなタイ語にはもっと困難な問題がある。 タイ文字は 複合文字と言って複数の文字が組み合わさって一文字になるようになっており、だから長さは可変長なのだ。 これじゃお手上げだ。
世界一国際センスのないアメリカ人に設計を任せたのが全ての間違いの始まりだと僕は思う※。 何故全ての組み合わせパターンそれぞれに一文字ずつ割り当てなかったのだろうか。 アホかと思う。 何故ユニコードを16ビットにしたのか。 アホか。 世界にはそんな少ない文字しかないと思ったのだろうか。 おかげでいまさら当然のごとく足りなくなって、16ビット文字と付け足した32ビット文字が混在してしまい更に輪をかけてややこしい事になっている。
※ まぁとはいえ、日本人は前例の無い事を絶対にやらないから、日本人には無理だとは思うけど。
最初に述べたように、元々TELNETというのは カーソルの移動に問題を抱えている。 それでもなくても元々複雑なのだ。 そこに更にUNICODEが加わると、一文字の幅が確定できなくなるという致命的な問題が加わる。 その複雑さは想像を絶するものになる。
歪んだものの上に歪んだものを乗せると相乗効果的にひずんでいく...。
BASHと呼ばれるソフトがある。 話では UNICODEの対応が済んでいるのだそうだ。 ホントかなぁ... 僕が見ている限りだけど、多くのソフトは UNICODEを 元々使っていた Shift_JISとかEUCとかのコードに戻して表示できるようにしただけの様に見える。つまり、UNICODEとはいえ、表示できる言語は1個だけなのだ。 ( 実はこの問題はUNICODE対応が比較的まともな JAVAも持っている。 僕は英語環境のWindowsを使っているけど、Javaの日本語の表示はあまり正しくない。 表示できないわけではないのだけど... 。 表示位置が微妙に変だ。)
たとえ苦労の末ようやっと UNICODE対応が完了したとしても、これに新しく機能を追加するのは、もう絶望的に困難である様な気がする。
こういう風な状況に陥ったプロジェクトのソフトウェア開発の速度というのはとても遅くなる。
ちょっとしたヒラメキを瞬発力的に実現する、ということが無理になっていく。
つまりソフトウェアは劇的に変化する力を失うのだ。
僕は、そういう現象が起こった頃が、目安としてのソフトウェアの寿命というものなのではないかな、と思う。
◇
他にも 押されたキーと送出するバイト列の対応にも、ターミナルによって大きな差があるようだ。 これもかなり厄介な問題だよな....。
http://www.ibb.net/~anne/keyboard.html
◇
とはいえ、いろいろな事をやらせようとさえしなければ、TELNETというのは とてもシンプルで使いやすいプロトコルだ。 ママチャリで雪山を登るようなことはしないのが一番だ。 もともと 1byte 1文字というのを大前提に作り始めた シンプルさが命のプロトコルに、一文字可変長バイト可変長表示幅のUNICODEなんか乗せても複雑さが増すばかりで疲れるだけだ。
それさえまもれば、TELNETは気軽な自転車の様に素敵な存在であり続けると思う。
─── ところで、こうやってシンプルさが命だった技術に安易にゴテゴテと機能が追加されてどんどんと見苦しさをましていくシステムを見るのは辛いものだが、今でもTELNET以上に過剰な機能を追加され見苦しさを増して破滅へと進んでいる技術がある。
それはHTMLだ。
HTMLは元々デザイン要素を含めないで文章構造を明示するというとてもシンプルな設計思想の下に生まれた ... しかし、その後どんどんと設計者が意図しなかった機能=デザインを指定するための機能が追加されていった... DynamicHTML とか AJAX とか言葉はいろいろかわったけど、ようするに、シンプルさが命だったHTMLにゴテゴテと機能が追加されて見苦しく複雑さを増していることには代わりがない。 最後には極まったように複雑になって、どうやっても機能を追加できなくなるだろう。 そうなったら終わりである。時代に対応しきれなくなり技術はそこで短い生涯を閉じる。
それは既に起こり始めている。
普通はみんなそういう物は作らない。 だけど、そういうものを敢えて作ってみると色々わかることがあるだろうな、と思ったので作り始めた。 というか 探してみたら意外と誰も作っていなかったし、まぁ自分で作ってもシンプルだからそんなに大変じゃないだろうと思っていたのもある。 でも実際に組み始めたらとても難航した。 久しぶりに行き詰まった。 散々悩んだ挙句、そもそもやり方が間違っている事に気がつき、一週間分の作業を全部捨てる必要に迫られるという大失態をやらかしてしまった。 何故こんなに完成されシンプルでお手軽なのに、いろいろな人がTELNETを再利用したがらないのかだんだんわかってきた。
僕がパッと気がついたことのひとつに、カーソルの動きの互換性の低さがある。
説明を始める前に ... そもそもTELNETというものを見たことがあるだろうか。
telnet://towel.blinkenlights.nl/
黒い画面に文字が出てくるだけのソフトだ。 昔はこれを使ってコンピューターを操作した。 これは今のWindowsのような グラフィカルなインターフェースがメジャーになる以前の キャラクターユーザーインターフェースと呼ばれていたものだ。 絵は一切なし。 全ては文字で指定する世界。 ややこしい記号が並んでいるので面食らうけども、GUIで操作するのとくらべて曖昧さが無くて、むしろ CUIで作業したほうが効率が良いくらいである。 クラシックだなぁ... と思うなかれ、今でも現役でバリバリ使われている。 特に mixi の様なインターネットサーバーを管理する時は必須のソフトだ。
実はこのTELNET、元々「テレタイプ」と呼ばれるものだったらしい。 テレタイプにはキーボードがついており、キーを押すとどのキーが押されたのかをデータに変換しネットワークを通じて送信、受信したサーバーはプリンタにポチと一文字印刷... そういう極めて原始的な機械から始まったようだ。 こうして TELNETは進化を始めた。
http://ja.wikipedia.org/wiki/%E3%83%86%E3%83%AC%E3%82%BF%E3%82%A4%E3%83%97%E7%AB%AF%E6%9C%AB
このプリンタは、時代と共にテレビになってしまった。 キーボードを押すと、地球の裏側にあるテレビに一文字表示 ... しかしそれでは打った人が見えないので意味がないかもしれない。 しかし、この機構を遠隔地にあるサーバーの管理に使えないか、と考えた人がきっといたんだと思う。 逆転の発想で、テレビは地球の裏側ではなくキーボードの隣に置いておくことにした。 キーボードを押すと、地球の裏側においてあるサーバーに一文字送信。 サーバーはその一文字をそのまま送り返し、ユーザーの面前にあるテレビに一文字表示する。 これは革命的だった。 これによって、プログラマはいちいちサーバーが置いてある建物まではるばる出かけていく必要が無くなったのだ。
この発想の切り替えには素晴らしいものがあると僕はおもう。 さすがアメリカ人。 こうやって40年以上前に出来たソフトが今でも使われているというのは、考えてみれば驚異だ。
◇
というわけで、これは遠隔操作のメモ帳の様なソフトだ。 だから、メモ帳の様にカーソルというものがある。 キーボードを押すと、このカーソルの位置に文字が表示されるようになっている。 でもユーザーが見ているカーソルの位置と、サーバーが思っているカーソルの位置が違っていると正しく表示されない。 これは「福笑い」のようなものだ。 サーバーは正しく目鼻の位置を置いているつもりなんだけど、肝心の顔の位置が全然思っている場所と違ってしまえばメチャメチャな顔になってしまう。 この福笑いの再来の様な状況が発生する。
普通は、このカーソルの位置が狂うなんてことは、ないだろう... と思うのだけど、これが狂うのだ。 TELNETは 40年の年月のうちに、今では考えられないような信じられないような使われ方をしてきており、その間にその信じられないような使われ方をするなかで、プログラマが目先のことだけを考えた勝手な独自機能を追加をしているのだ。 こういう独自機能は、あとあと長い年月にわたって後続のプログラマを苦しめ続ける。
僕が気がついたのは、画面の右端でキーを押したときの動作だ。 このとき普通なら、カーソルは左端に自動的に移動するだろうと思うのだけど、これが移動しないのだ。 次の一文字を押した時初めて次の行に移動する。 カーソルの位置は同じなのだけど、次に入力される文字の場所には2種類あることになる。
この動作がとても曖昧だ。 だって、最後の一文字を入力して←キーを押した時カーソルはどこに移動すればいいの? その答えは、プログラマによって違うわけで、実際今利用されているターミナルソフトでも実に千差万別の実装がされている。 要するに、今から新しく作るプログラムは、この画面右端で折り返す動作に依存しないようにプログラムを組まなければならない。 これがとても面倒だ。
僕はさっと現状で利用されているラインエディタ(BASH/KSH/ZSH/VIM程度)が取っているこの問題の対応を調査してみたが、実に色々な方法をつかってこの問題を回避していることがわかった。
僕は思うんだけど、この問題さえなければ、TELNETはもっといろいろな人に再利用されていると思う。 手軽でポータブルな遠隔操作ツールとして今でもどんどん再利用されていたのではないだろうか。 しかし、この問題があるために、TELNET用のプログラムを作り変えるのは容易ではないのだ。
もちろん色々な人がこの困難を解決しようとがんばっている。 実はこの問題を解決するTERMCAPやCURSESという有名なプログラムがあるのだけど、これら自体もとても複雑なソフトで手軽には作り変えられない。 使い方もカンタンではない。
僕は思うのだけど、TELNETは、この問題さえなければここまでは事態が悪化しなくてもすんだはずではないだろうか。 恐らくこの問題を修正しようとするのではなく、新しい技術を使ってさっさと新たに作り直してしまえば1年もかからずしてもっと良いプロトコルが出来ると思う。 でも誰もそれをやらない。 しちめんどくさいカーソルの問題と共に生きている。 それが新たなプログラマの侵入を阻んでいる。
歪んだものの上に物を作るとそれも歪む。 これは基本中の基本中だと思う。
だけど、繰り返し繰り返し行われている。
全てを捨てて新しく作り変える勇気。
◇
こうやって長期にわたって偶発的に発展してきたTELNETプロトコル。 だけど、僕はもう寿命なのかなと思っている。
TELNETプロトコルの上には SHELLと呼ばれる巨大な一枚岩が乗っかっている。 更にこの上に今のUNIX文化を形成しているあらゆるプログラムが乗っかっている。 TELNETプロトコルがいかにまずくてもTELNETを捨てるという事は、これら全てを捨てるということであり、大変な勇気が居る... というかもうほとんど無理なんだと思う。
しかし 世の中はユニコードの時代だ。 ユニコードが通らないというのは、とても不便な事だが、これらのUNIXソフトとユニコードはかなり相性が悪い。 もちろん一時に比べたらとてもよくなってはいるけど...。
アメリカには文字が26個しかない。 だからデータが1byteあれば、それは必ず一文字だった。 そういう文化だった。 日本人はそこにもう一バイト追加した。 2バイトであれば、必ず2文字の幅で表示されるという、PC-9801が築き上げた巨大な文化をそこに形成した。 そこでも1byteは1文字という暗黙の了解があった。 しかし、今、その前提は根本から崩れている。
ユニコード化によって日本の文字はほとんどの場合 1文字3byte になってしまった。 今受け取った1byteが 何文字の幅なのかを知る方法がなくなってしまったのだ。 これはとても厄介な問題だ。 僕の大好きなタイ語にはもっと困難な問題がある。 タイ文字は 複合文字と言って複数の文字が組み合わさって一文字になるようになっており、だから長さは可変長なのだ。 これじゃお手上げだ。
世界一国際センスのないアメリカ人に設計を任せたのが全ての間違いの始まりだと僕は思う※。 何故全ての組み合わせパターンそれぞれに一文字ずつ割り当てなかったのだろうか。 アホかと思う。 何故ユニコードを16ビットにしたのか。 アホか。 世界にはそんな少ない文字しかないと思ったのだろうか。 おかげでいまさら当然のごとく足りなくなって、16ビット文字と付け足した32ビット文字が混在してしまい更に輪をかけてややこしい事になっている。
※ まぁとはいえ、日本人は前例の無い事を絶対にやらないから、日本人には無理だとは思うけど。
最初に述べたように、元々TELNETというのは カーソルの移動に問題を抱えている。 それでもなくても元々複雑なのだ。 そこに更にUNICODEが加わると、一文字の幅が確定できなくなるという致命的な問題が加わる。 その複雑さは想像を絶するものになる。
歪んだものの上に歪んだものを乗せると相乗効果的にひずんでいく...。
BASHと呼ばれるソフトがある。 話では UNICODEの対応が済んでいるのだそうだ。 ホントかなぁ... 僕が見ている限りだけど、多くのソフトは UNICODEを 元々使っていた Shift_JISとかEUCとかのコードに戻して表示できるようにしただけの様に見える。つまり、UNICODEとはいえ、表示できる言語は1個だけなのだ。 ( 実はこの問題はUNICODE対応が比較的まともな JAVAも持っている。 僕は英語環境のWindowsを使っているけど、Javaの日本語の表示はあまり正しくない。 表示できないわけではないのだけど... 。 表示位置が微妙に変だ。)
たとえ苦労の末ようやっと UNICODE対応が完了したとしても、これに新しく機能を追加するのは、もう絶望的に困難である様な気がする。
こういう風な状況に陥ったプロジェクトのソフトウェア開発の速度というのはとても遅くなる。
ちょっとしたヒラメキを瞬発力的に実現する、ということが無理になっていく。
つまりソフトウェアは劇的に変化する力を失うのだ。
僕は、そういう現象が起こった頃が、目安としてのソフトウェアの寿命というものなのではないかな、と思う。
◇
他にも 押されたキーと送出するバイト列の対応にも、ターミナルによって大きな差があるようだ。 これもかなり厄介な問題だよな....。
http://www.ibb.net/~anne/keyboard.html
◇
とはいえ、いろいろな事をやらせようとさえしなければ、TELNETというのは とてもシンプルで使いやすいプロトコルだ。 ママチャリで雪山を登るようなことはしないのが一番だ。 もともと 1byte 1文字というのを大前提に作り始めた シンプルさが命のプロトコルに、一文字可変長バイト可変長表示幅のUNICODEなんか乗せても複雑さが増すばかりで疲れるだけだ。
それさえまもれば、TELNETは気軽な自転車の様に素敵な存在であり続けると思う。
─── ところで、こうやってシンプルさが命だった技術に安易にゴテゴテと機能が追加されてどんどんと見苦しさをましていくシステムを見るのは辛いものだが、今でもTELNET以上に過剰な機能を追加され見苦しさを増して破滅へと進んでいる技術がある。
それはHTMLだ。
HTMLは元々デザイン要素を含めないで文章構造を明示するというとてもシンプルな設計思想の下に生まれた ... しかし、その後どんどんと設計者が意図しなかった機能=デザインを指定するための機能が追加されていった... DynamicHTML とか AJAX とか言葉はいろいろかわったけど、ようするに、シンプルさが命だったHTMLにゴテゴテと機能が追加されて見苦しく複雑さを増していることには代わりがない。 最後には極まったように複雑になって、どうやっても機能を追加できなくなるだろう。 そうなったら終わりである。時代に対応しきれなくなり技術はそこで短い生涯を閉じる。
それは既に起こり始めている。
コメント一覧
這いよる謎の犬ピース 2008年01月02日 23:59
集中して読んでみました。
文字という、ソフトウェア上でよく使うものでそんな問題があったとは驚きです。
いろいろな文字データを扱えて、どんなソフトウェアやOSにも対応できるMVM(文字仮想マシーン)みたいなものがあったら・・・あぁ、どちらにしろ流通してるUNICODEの扱う文字データ量が変わらないとダメかぁ・・・
文字という、ソフトウェア上でよく使うものでそんな問題があったとは驚きです。
いろいろな文字データを扱えて、どんなソフトウェアやOSにも対応できるMVM(文字仮想マシーン)みたいなものがあったら・・・あぁ、どちらにしろ流通してるUNICODEの扱う文字データ量が変わらないとダメかぁ・・・