Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.CheapestOnlineUSpharmacy(2008-05-17 14:27)
2.Kir(2008-05-08 15:52)
3.Hero(2008-05-06 16:49)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
遅れはせながら、CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyanceの「XML とアフォーダンス」を題材に一つ話をしてみたい。「XMLとアフォーダンス」で書かれていることを（かなり乱暴に）まとめると、XMLによって記述され た データが人間に理解可能であるということを再評価しよう、ということ。例えば
XMLデータは、「オブジェクト」という抽象概念を理解できるプログラマーよりもはるかに大勢の人たちにとって、手に取ってみて理 解す ることのできるリアルなデータなのです。ダウンロードしてテキストエディタやブラウザで眺めてみることのできるデータなのです。
ということを言っているわけなんだけれども、「手にとって理解することのできる」ことを本当に徹底させようとするならば、いっそXML のタグも 「大勢の人たち」の母国語で書くと良いのではないか、と思うのだ。
■ XMLタグを英語以外で書くということ
下は「XML とアフォーダンス」での例だけれども
<Payment>
<Price>100</Price>
<Price>200</Price>
<Price>500</Price>
</Payment>
これを例えば日本語で
<支払>
<価格>100</価格>
<価格>200</価格>
<価格>500</価格>
<支払>
と書けば、「プログラマーではなくて、もっと桁違いに多い一般人に近い人たち」との距離はさらに縮まる、と僕は考えるわけ。
「でも"Payment"とか、"Price"って書いてあれば、ふつう英語のままでもたいていの人は分かるんじゃないの？」という疑 問を持ったアナタ、では次の例ではどうかな。
<BalanceSheet>
<Assets>
<CurrentAssets unit="MYen">150</CurrentAssets>
<NoncurrentAssets unit="MYen">200</NoncurrentAssets>
</Assets>
....
これは例えば日本語で書くと
<貸借対照表>
<資産の部>
<流動資産 単位="百万円">150</流動資産>
<固定資産 単位="百万円">200</固定資産>
</資産の部>
.....
となる。（会計の知識がちょびっと必要ではあるけれども）英語で書かれたものと比べて、日本人がこれを読もうとした場合の読みやすさは 段違いである、と言って良いと思う。このような用語がタグとなって100も200も登場するような文書があれば、その差はさらに開いていくはずだ。
ちなみに読み手の母国語（この場合は日本語）でXMLのタグを付けることに関して、他の人はどんなことを言っているかを確認しようと、xml-users メーリングリストのアーカイブを眺めてみたところこんな記述が見つかった。
名前を付けるなら:
1. 日本語がよい。例: <結論>
2. 次善はまっとうな英語。例: <conclusion>
3. 日本語のローマ字書きはよくない。例: <ketsuron>
4. そして最低なのは、番号。例: <R0073>。
([xml-users 1032] Re: 漢字を使おう)
これ、実はかなり古い時期(1999年)に投稿された記事なのだが、これに対する他のメーリングリスト参加者からの異論は出ておらず、 その後も日本語タグに関する記事がちらほらと出ているところからして、タグに日本語（≒英語以外の言語、といって良いか）を使うことの妥当性については、 それなりの合意が取れていると思っても良さそうである。
■ プログラミングはどうなる
XMLのタグを英語でなく、読み手の母国語、例えば日本語で書けば、「XML とアフォーダンス」で言われているような夢は（潜在的な利用者、つまりその母国語を使わないようなユーザの数と引き換えに）その実現 可能性を一気に増すことになる。
…が、これはXMLデータを処理するプログラムを作る側にとってもう一つ面白い（頭の痛い？）副作用を提供して くれることになりそうだ。つまり、基本的に英語ベースで書かれていたプログラムの世界に、それ以外の言葉（日本語）が本格的に攻め込んでくるきっかけにな りうる、ということ。
だってタグ名に「流動資産」と書いたら、プログラム中でそれに対応する変数名をいまさら"CurrentAssets"とか書きたくな いでしょ。英訳し直すタグが一つだけならばいいけれども、これが100個も200個もあったら最悪だ。"RyudouShisan"とかするのはなおさら ダメ。 上で引用した[xml-users 1032] Re: 漢字を使おうでも、「日本語のローマ字書きは良くない」とあるのに、XMLデータでダメなものがプログラムの中に 入ったらOKなんて理屈が立つはずもない。
「変数名に日本語を使うなんてどうかしてる」というのが、プログラミングの世界での今までの常識（暗黙の了 解）であったが、それが一気に崩れるということだ。さあどうする。
■ まとめ ― 二つの問い
上の話はそのままどこまでも展開していきそうだが、キリがないので今回は一旦まとめてしまおう。まずここまでの話を整理する：
でもって、上の仮定がもし正しいとした場合には、
という二つの問いが生まれることになる。どちらの問いも（少なくとも僕にとっては）面白いので、もうしばらくの間考えてみることにした い。
面白い考察をありがとうございました。
そうなんです。英数字タグという制約は、
１）プログラミング言語とのバインディングの都合
２）転じて、オフショアなどグローバル化する開発の都合
３）データが日本国外にも流通する可能性へと開いておきたい
という背景によって淘汰されてきたプラクティスに過ぎないんですよね。
このうち、１）に関しては（手前味噌ですが）ASTERIAのような新しいパラダイムのプログラミング言語（変数名に日本語が使えて、本格的なシステムで実際に日本語の変数が普通に使われている http://www.infoteria.com/jp/product/asteria/designer/index.jsp#fun_02 ）が色々と出てくることで、少しずつ敷居が下がってくるんじゃないかなと実感しています。
ただ、それも２）３）を考えると、やはり局所的に小さくつくるシステム向きで、どこかで英数字に切り替える、というロードマップが一般的になるのでしょうけど。
Non-Programmerへの裾野を広げるという目的に照らせば、それでいい（十分な役割を果たす）のだと思います。
コメントありがとうございます。真面目な答えを考えているうちに、いつの間にか上の２）３）の逆、つまり
「自分の国の言葉を使ったXMLタグの体系を使って非関税障壁を作るヒトやら国が現れる」
なんてことが起きはしないだろうか、などとヘンなことをつい考えてしまいました。
#「自国産業の振興のためにデータ形式を保護しよう！」とか言っている姿が目に浮かぶ
なんだかなぁ…とか思いつつ、実は既にどこかでやられていたりして。
昔PC-88VA2のBASICでプログラムを組んでいるときに、変数名に日本語が使えると分かり、全ての変数を日本語で書いたプログラムをI/Oに投稿したことがありましたｗ
FOR ループ１=0 TO 100
GOSUB キーボード処理
みたいな感じの。
分かりやすいかどうかはともかく、変数名を考える時間は大幅に減りますよね。
そういえば、かなり昔に「ぴゅう太」の日本語BASICってありましたよね…。おお、23年も前か。
http://ja.wikipedia.org/wiki/%E3%81%B4%E3%82%85%E3%81%86%E5%A4%AA
いや、もちろん、福盛さんの話は、言語の予約語および構文の非英語化じゃなくて、変数/定数/手続ラベルの非英語による記述なのは了解しているわけですが、つい:-)
しかし、読解性の向上ということであれば、KnuthのWEB的な手段というか、一つの変数に対して各国語のラベルをつけることにして(プログラム/データ内部に埋め込むのでもいいし、リソースのように外部ファイルで定義/annotateするのでもいいでしょうし)、それを処理系を通じて各国語のバージョンを生成する、という方法を取ってもいいのではないかと。書く方のコストは高くなっちゃいますが、1)〜3)と読解性の双方を満たすにはそうするしかなさそうな気がしますね。
この話は、プログラミングとデータ構築だけではなくて、上流工程の方がもっと必要とされる話ではないかと思います。日本だと、構造化設計技法において(や、あるいはオブジェクト指向的な設計技法においても)、データディクショナリを用いて、そのアプリケーションに関与するデータ項目(やロールや概念など)を、名前付けしてデータベース化する作業を分析・設計段階でおこないますが、その「名前」はたいてい、「英語表現」と「日本語表現」の二つを併記します。「英語表現」が下流において変数名や関数名として使用され、「日本語表現」は仕様書や設計書やプログラム中のコメントにおける語彙として使用されます。で、「母国語による表記」をやっちゃおうということは、当然、このデータディクショナリの二重表記も一つの言語に統一してしまえ、ということであり、仕様書や設計書で用いられている表現をそのまま下流に持っていってしまえ、ということになるわけですね。
「ぴゅう太」かぁ、懐かしい…昭和は遠くなりにけり、ですねぇ。
というのはとりあえず置いといて :-) 本題へ。
先のコメントで言われていた「プログラミング言語とのバインディングの都合」については、(実際には、いろいろと解決しなければならないところは残ってはいるものの)技術的にはなんとか目処が立ちつつある、というのが僕の見解です。となると、残る問題は
(a) 使う側にとっての容易性
(b) 作る側にとっての単純性
(c) (英語/日本語などの)言語圏をまたがった流通性
のうち、原理的には三つを同時に満たすことはできない、という点に集約されるのではないかと思います。今までは、(c)の流通性が(暗黙のうちに)必須であると仮定されていたため、(a)か(b)のどちらをとるか、というトレードオフがなされていたわけですが、今回の話のように(c)のしばりをゆるめると、新しいトレードオフが生まれる可能性がある、という点が重要だと考える次第です。
言い換えれば、以前は(a)と(b)という直線（一次元）上での選択だったのが、(c)を加えることによる三角形の平面（二次元）上での選択をとる余地が生まれる、ということになります。無論(c)の条件を外した場合のリスクをきちんと考えなければならない、という新たな課題は出ることになると思いますが、ちょうど良いバランスを狙って(c)を局所的に外し、(a)(b)が両立する可能性を狙うという選択肢は、状況によっては今後考慮してみる価値はあるのではないかと思います。
昔、2bytes文字をコンパイラがシンボルとして認識可能な文字列に変換するプリプロセッサを書いた事があります。で、それだけだとエラーメッセージがワケワカなので逆変換するポストプロセッサも。...かな漢字変換が面倒だったです。あと、当時はテキスト画面だったので漢字だと上下がくっついちゃっていまいち読みにくかったりします。今なら当時よりは使いやすくなっているのかも知れません。
えーと、日本語タグですが、変換ツールがあれば、あるいは処理系に辞書を食わせて別名として判断させれば没問題です。日本語プログラミングといえば、AppleScriptができました。でも日本語だと予約語が覚えられなかったり。
それぞれの国で 見る時 だけ母国語に変換すりゃいいんじゃないすか？
> それぞれの国で 見る時 だけ母国語に変換すりゃいいんじゃないすか？
純粋に技術的な観点で見るのならば正解だと思います。例えばXBRL(eXtensible Business Reporting Language, http://www.xbrl-jp.org/ )などは、まさにそのようなニーズ(と、それ以上の要求)に答えていますよね。
しかしながら、それを実現するには、変換のためのプログラム、そして変換のための(例えば英語→日本語の)辞書の両者が必要となるわけで。
「そんなプログラム、sedで5行あれば書ける」「そんなのperlで5行あれば…」
「そんなの(以下略)」
という意見も当然ながら出てきそうな気はしますが、そもそも変換プログラムを実行するための処理系(sedやらperlやらXSLTプロセッサやら)をユーザにインストールさせる必要があるねとか、さらに辞書を作るのは面倒な作業だし、わざわざ辞書を作ったからには一人で使うのはもったいないからなるべく多くの人に使ってもらいたいな、なんてところから、辞書の標準フォーマットを作ろう、作った辞書はがんばって流通させよう、とか、いつの間にか話が大きくなっていくのではないか、などど、いらぬ心配をしてしまう次第です。
少なくとも、本エントリの冒頭の引用文にあった「手にとって理解することのできるリアルなデータ」「ダウンロードしてテキストエディタやブラウザで眺めてみることのできるデータ」からはどんどん離れていくことになるのではないかと思います。最初に挙げたXBRLのようなものであれば、大掛かりな話になることに対する覚悟が最初から出来ている(ように見える)のでいいのですが、そこまでやる必要のない分野というのも結構ありそうな気がします。
さらに。
最初にこのエントリを書いたときには、はっきりと意識していなかったのですが、これはXMLによるデータのフォーマットを作る側にとって、より大きなインパクトを持つ話なのだと思います。「そもそも日本語で項目を考えているんだから、英語のタグ名なんていらねーよ」なんて人にとっては、(言語の変換のための)特別なインフラストラクチャを使うことなく、日本語で直接タグ名を定義できることで、かなり楽をすることが出来るのかもしれない、と(勝手に)想像しています。
…すっかり長くなってしまいましたが、とりあえずこんなあたりで。