2011-12-30

最近のゲームのグラフィックに思う

グラフィックは、ゲームの面白さの本質ではない。しかし、やはりグラフィックは重要である。私が始めた遊んだPCゲームは、Mafiaであった。Mafiaは、当時としては素晴らしいグラフィックであり、私のGeForce 4 Ti4200で快適に動作した。

今から思うと、惜しいことをしたものだ。私はもっと早くからPCゲームに目覚めているべきだったのだ。DoomやWolfenstein 3DやDuke Nukem 3Dなどといった往年の名作ゲームが、今となっては楽しめない。もし当時、これらのゲームに触れていれば、楽しめたはずなのだ。しかし、私の最初のPCゲームはMafiaだったので、それより以前の時代のゲームを楽しめないのだ。これは実に残念なことだと思う。私はThe Elder Scrollsシリーズが好きだが、ArenaやDaggerfallは楽しめない。どちらも、今、公式に無料で提供されているゲームである。また、DOSBoxのようなx86上で動くMS-DOSエミュレーターを使えば、当時とほぼ変わらずに遊べるゲームである。それなのに楽しめない。実に惜しい。

ともかく、最近のゲームのグラフィックの流行は、スクリーンスペースのポストプロセスだろう。なにしろ、どんなシーンでも負荷が予測できる範囲なので、化石並の低スペックなコンソールでも使いやすいのだ。

SSAO(Screen Space Ambient Occlusion)

SSAOは最も有名であろうと思う。Crysis以降、多くのゲームはSSAOを採用した。nVidiaなどは、ドライバー側でSSAOを適用する機能までリリースしたのだ。また、DirectXのラッパーDLLをかませて、既存のゲームにSSAOをかける手法も開発されてきた。Depth Bufferの各ピクセルと、周囲のピクセルの差を比較して、それに応じてやや黒くするポストプロセスである。もちろん、いくらスクリーンスペースと入っても、大まじめに実装しようとするとパフォーマンス上厳しいので、大胆な手抜き方法を使う。見た目に分かりやすい結果としては、面と面が角度をつけて重なり合っているような部分が黒くなる。面白いことに、この効果は、実にうまく人間の脳を騙してくれる。SSAOを古いゲームに適用してみると、急にグラフィックの品質が大幅に向上したように感じる。

ただし、最近は、以前程SSAOが喧伝されなくなっている。代わりに、SSAOっぽい影をテクスチャに最初から書き込んでおく手法もみられる。

ポストプロセスによるアンチエリアス

具体的な名称としては、nVidiaの考案したFXAAが一番有名だが、Crysis 2で使われているSMAA: Enhanced Subpixel Morphological Antialiasingもなかなか面白い。基本的な考え方はどれも同じで、ジャギーをごまかすフィルターである。

そもそも、アンチエリアスの一番分かりやすい目的は、縁のギザギザ、つまりジャギーを目立たなくするというものである。最初に実装されたAAの手法は、目的の解像度より高い解像度で描画して、しかる後に目的の解像度までダウンスケールするというものである。これは原始的だが、最も効果的な方法である。問題は、パフォーマンスが最悪だということだ。今の最新のCPUをつかって、大昔のゲームがやっと動くというほど、パフォーマンス上の問題がある。近代的なゲームに使うことはできない。次に、MSAAというものが実装された。これは、頂点処理だけ高解像度で行い、ピクセルに落としこむ際には、目的の解像度で行うというものである。すくなくとも、ジャギーはだいぶ解消できる。問題は、これも最近のゲームに使うには、ややパフォーマンス上問題がある。

結局、やっていることはジャギーの低減なのだ。ジャギーは縁に発生する。静止画の縁を判定する方法は、大昔から研究されている。だったら、縁を判定して、その部分だけ賢くぼかせば、ジャギーはごまかせるではないか。ということで、FXAAなどのアンチエイリアスは、縁を判定して賢くぼかすピクセルシェーダーのコードで実装されている。

Screen Space Global Illumination、あるいはReal-time Local Reflection

Unreal Engine 3のSamaritanデモで、この技術が披露されている。

また、Crysis 2にDirectX 11パッチを当てると、Real-time Local Reflectionと称して、この技法が使われる。

これも、スクリーンスペースによる反射の実装である。水たまり、テーブル、壁などに、周囲の風景が写り込んでいる。

何にしても、化石スペックのコンソールが足を引っ張りすぎている。テッセレーションを活用したゲームはほとんどない。もっとも、テッセレーションは、その可能性あふれると裏腹に、普通に使っても、それほど見た目にはインパクトがない地味な機能なので、仕方がないのかもしれない。それに、ほとんどのゲームでまともに使っていないので、GPUベンダーもあまり力を入れていないのだと思う。ただし、将来に期待できる。個人的には、Normal MappingやBump Mappingには全然感動できないので、Parallax mappingやDisplacement mappingがもっと使われてほしいものだ。

変わり種としては、Rageが上げられる。伝説のプログラマーJohn Carmackは常に変わったことをする人である。ただし、常に主流の技法からは外れているのだ。今回、Carmackがこだわったのは、テクスチャーだ。Rageでは、使い回しのないテクスチャーを実現している。もちろん、テクスチャーの構築には、デカールを使い回しているが、テクスチャ自体はユニークである。Rageのグラフィックは、序盤の廃墟がすばらしい。ただし、ユニークなテクスチャーは、デザイナーにかなりの負担を強いるらしい。プレイ動画をみても、中盤以降はマップの構成が雑になっているし、ついには長いマップ作成を諦めて、狭い部屋に閉じ込めて、周囲から延々と沸く雑魚敵を相手に戦うような演出でごまかしている。残念なことだ。もう一つ残念なことに、テクスチャーを使いまわさなかったせいで、あんなに短いのに、DVD三枚ほどの容量を必要としている。もちろん、PCならばいまどき20GB程度のサイズは問題にならないが、博物館に陳列されるレベルの低スペックな現行コンソールではかなり問題になる。そして、今時Bump Mappingすらないのだ。まあ、個人的にBump Mappingは価値がわからないのでどうでもいいのだが、やはりないと寂しい物がある。Rageは色々と惜しいゲームであった。

2011-12-29

マリオカート7が劣化していた

たまたま、3DSのマリオカート7に触れる機会があったので、遊んでみたのだが、全然面白くなかった。レースゲームなのに疾走感がまるでなかった。

まずグラフィックが糞だ。加速時にFOVを狭めたり、ブラーをかけたりするなど、レースゲームならではの表現手法は、もう考案され尽くしているはずなのに、なぜこの2011年で、こんなにもしょぼい表現なのだろう。それに、マップが無駄に広い気がする。何故こんなに広いのだろうか。こんなに道が広くては、コースアウトして溝に落ちるとかダートに突っ込んで減速するといったスリルを味わえない。ただ惰性で操作しているだけで完走できるヌルい作りになってしまっている。こんなゲームのどこが面白いというのか。

結局、マリオカートというゲームは、スーパーマリオカートでその可能性を示し、マリオカート64で完成されたゲームなのだろう。これ以上何を付け足しても蛇足というものだ。マリオカート7をやるくらいなら、スーパーマリオカートやマリオカート64をやったほうが、よっぽど面白いはずだ。

なぜこうなってしまったのだろう。今や、ポータブルゲーム機ですら、ニンテンドー64をはるかに上回るスペックを持っているのだ。それなのに、なぜ当時よりつまらない劣化続編しか作れないのだろうか。そして不思議なことに、ゲーム市場は、当時よりはるかに大きく、売上本数も増えていることだ。これは一体どういうことだろう。世の中はクソゲーを望んでいるのだろうか。

2011-12-28

Intel、ネットワーク越しに電源を入れる特許を取得

Intel Receives Network-Power-On Patent

Intelが、ネットワーク越しに電源を入れる特許を取得したらしい。はて、そんなのは自明ではないのだろうか。すくなくとも、この特許が出願された2007年以前にも、そんな装置は山ほどあったと思うのだが。

2011-12-27

鬼を笑わせる

今年も残り少なくなってきたところで、鬼を笑わせるような未来予測をしてみたい。ところが、どうも今は、さっぱり希望がでてこない。というのも、PCの進化がどんどん遅くなっているようなきがするのだ。

たとえば、CPUの処理能力は、ここ数年、驚くほどの向上はない。少し向上はしているものの、その向上が目にみえて実感できないのだ。もはや、我々はMP3のエンコード速度を気にする必要はない。ゲームなど、もはやCPU依存ではなく、GPU依存になっている。動画のエンコードでは多少の実感ができるが、やはり一般的とは言いがたい。

GPUはCPUよりまだ希望がある。といっても、今のPCゲームは、低スペックなコンソールに足を引っ張られて、その性能はあまり意味がない。GPGPU(GPUによる汎用コンピューティング)は、あまりにも適用可能な範囲が限定的で、やはり一般人が直接その恩恵に与ることはない。

HDDの容量なんてもはや誰も気にしないし。SSDは値段が下がる程度の予測しかできない。

もうPCの世界からみると、ハードウェアの進化は止まっているも同然なのだ。

ただし、これがスマートフォンになると、かなり未来は明るい。スマートフォンのハードウェアは、年々進化している。もうしばらくすれば、グラフィック性能が現行コンソールに追いつくだろう。その時、果たしてゲームコンソール、すなわちゲーム専用機は、生き残れるだろうか。今より少しグラフィック性能を上げただけでは、果たして差別化出来るだろうか。十分なグラフィック性能をもったスマートフォンを誰もが持っている世界では、ゲーム専用機など無意味である。実はPCすら危うい。もし、ディスプレイとの接続がワイヤレスになれば、果たしてPCは生き残れるのか。

もちろん、無線によるディスプレイ接続は、帯域的にまだ現実的ではないが、いずれ実現されると考えている。鬼が一番笑いそうなのはここだろうか。

ただし、スマートフォンでひとつ気になるのは、自由が全くないということである。PCならば、どのハードウェアを使うか、どのOSを使うか、どのネットワークを使うか、ということは、自由である。ソフトウェアも、様々な配布形態がある。ところが、スマートフォンでは、こうは行かない。ハードウェアとOSは固定されており、ネットワーク提供者も、大抵固定されている。ソフトウェアは統一された唯一の中央マーケットから入手しなければならない。しかも、このマーケットでは、ソフトウェアには事前に検閲が行われているし、遠隔操作によるユーザー側のスマートフォンのソフトウェアの消去も可能なのだ。これはどういうことだ? 今年は1984年か?

PCならば、ハードウェアには様々な標準規格がある。しかし、スマートフォンにはそんなものはない。ハードウェアとOSがセットになったAppleはさておき、androidさえ、ハードウェアの仕様はころころ変わるので、昔のハードウェアに最新のandroid OSを入れるということが困難である。

さらに、特許の問題がある。スマートフォンの世界では、私のコモンセンスで考えるに、自明であるようなアイディアにまで、特許が与えられている。特許はアイディアに与えられるものだっただろうか。ユーザーの利便性と普及を考えれば、機能やデザインを統一するのは理にかなっている。キーボード配列やマウスは、信号は規格化されているし、レイアウトも規格化されている。スマートフォンにはこれがない。みなてんでバラバラに実装し、それぞれ独自発明であるとして特許を取得し、市場原理に則った競争をせずに、特許裁判に明け暮れている。

もし当時、キーボードのレイアウトやマウスの形状、またはその信号方式に、今のように激しく特許を主張し、各社ともてんでバラバラに実装していたとしたら、今日のPCの興隆はあっただろうか。

これをもってこれをおもうに、あと10年ほどは、PCのスマートフォンに対する優位性は揺るがないであろう。PCがはるかに優れているためではなく、スマートフォンが足の引っ張り合いで自爆しているためである。したがって、私は今、スマートフォンについて何か学ぶ必要は一切ないと結論できる。この不自由と特許の問題が解決されてから学んでも遅くはないだろう。

SOPAガキ

Lauren Weinstein's Blog: "SOPA Lad" (The SOPA Song) - With Apologies to Gilbert and Sullivan

またLauren Weinsteinさんか。この人、本当にGilbert and Sullivanが好きなんだな。

元ネタはこれ、When I was a Lad.

2011-12-22

ブログのデザインを変えた

そろそろ、昔のテンプレートでは管理画面がまともに機能しなくなってきたので、仕方なく新しいテンプレートを使うことにした。HTMLの修正による変更はしたものかどうか悩んでいる。

2011-12-21

Winny開発者の金子勇、無罪

著作権侵害を幇助したとの疑いをかけられていたWinny開発者の47氏(最初に2chに開発宣言をしたレス番が47であった)こと金子勇が、無罪になった。当然である。ソフトウェアを開発、公開しただけで犯罪になってはたまらない。

ただし、Winnyはその仕組みからして、問題がある。ネットワーク内にたった一人の著作権侵害ノードがあるだけで、全員が推定著作権侵害になってしまうのだ。

Winnyの機能に、中継というものがある。これは、ファイルをアップロードするノードとダウンロードするノードの間にたってデータを横から横へ流す、いわばプロキシとなる機能である。この中継機能は、ユーザー外としていないデータまで中継する可能性がある。さらに、Winnyはキャッシュという仕組みによって、中継されたデータを保持し、その後も送信可能な状態におく。これが問題となる。

もし、中継機能がなければ、すなわち自分が明示的にダウンロードを選択したデータのみ、アップロードすることになる。これは、取得と公衆送信に、著作権上問題のないデータであれば、全く問題ない。ただし、中継という機能によって、意図しない著作権侵害かもしれないデータをダウンロード、アップロードしてしまう。つまり、Winnyネットワーク上にひとつでも悪意あるノードがいて、その著作権上問題となるデータをダウンロードしようという別のノードがいれば、自分が中継する可能性がある。よって、Winnyネットワーク内にひとつでも悪意あるノードがあれば、全ノードが推定有罪になってしまう。Winnyネットワークへは誰でも参加できるので、当然問題となる。

当時取るべきだった方法は、この問題を認識して、修正するように働きかけることだったのだ。それを、著作権侵害幇助などというどう考えてもおかしい理由で逮捕、起訴して、無罪判決まで七年もかける。問題のソフトウェアは修正されないまま放置されている。Winnyネットワークは中央管理サーバーを持たないので、全世界に核による絨毯爆撃でもしないかぎり、止められはしないというのに。これだから日本からはイノベーションは生まれない。

とはいえ、もし当時逮捕がなかったとしても、Winnyプロトコルが標準規格になるのは無理だっただろう。本当に普及させたいならば、まず仕様を文章で公開し、リファレンス実装をオープンソースで公開すべきだったのだ。まあ、あの当時はまだこの分野の夜明けのようなものだったので、似たようなプロトコルが乱立した。今となっては、Winnyプロトコルは、古びた時代遅れのプロトコルと言わざるを得ない。そもそも、ファイル共有自体に、新鮮な面白みもない。あの当時と比べて、ハードウェアははるかに進化した。ファイル共有程度であれば、別にP2Pを用いなくたっていいのだ。Dropboxのようなサービスが、当時よりはるかに安価で提供されている。もっとも、日本ではオンラインストレージは違法だというトンデモ判決がでているのだが。

では、今注目すべき技術は何かというと、やはりNamecoinだろう。合衆国でSOPAが議論されている今、中央管理のDNSへの信頼性が揺らいでいる。本来、名前解決のサービスに検閲や規制などがあってはならないのだ。名前解決というのは、著作権侵害や犯罪とは何の関係もないからだ。Namecoinは、ドメイン名の名前解決を、Bitcoinと同じ方法で行うものである。すなわち、P2Pで中央管理サーバーを持たず、信頼性が計算力により保証されたシステムである。

2011-12-05

Safari for Windowsの日本語版の使用許諾書がひどい

Safari for Windowsをインストールしようとして、使用許諾書を読んだところ、ひどい誤訳だらけで、何の意味もなしていないことを発見した。

たとえば、以下のような文面がある。

重要な通知: このソフトウェアがマテリアルを複製するための範囲において、使用することができます。

これを素直に解釈すると、ユーザーである私は、このソフトウェアであるSafariを使って、自由にマテリアル(?)を複製して良い、と読める。

さっぱり理解出来ないので、英語版のライセンスを読んだところ、以下のようになっていた。

IMPORTANT NOTE: To the extent that this software may be used to reproduce materials, it is licensed to you only for reproduction of non-copyrighted materials, materials in which you own the copyright, or materials you are authorized or legally permitted to reproduce.

これは分かりやすい。この文章の意図は、「このソフトウェアは、著作物を複製する可能性がある」と警告しているのだ。翻訳では、文章の途中でぶった切ってしまっているので、訳のわからないものになっているのだ。一体どこの馬の骨が、materialをマテリアルと翻訳して、しかも具体的な定義を与えないことが、いいアイディアだと考えたのだろうか。英語におけるmaterialは改めて定義する必要がない法律用語であったとしても、日本語における「マテリアル」は、そうではない。

しかし、最も問題なのは、以下の文章だ。

2.許諾された使用方法およびその制限
A. 本契約の規定に従い、お客様は、一回につき一台のApple商標が付されたコンピュータにAppleソフトウェアを1部インストールし、使用するための限定的な非独占的ライセンスを付与されます。

Apple商標が付されたコンピュータ? それはつまり、Appleが販売しているコンピューターのことであろう。しかし、このAppleソフトウェアは、Safari for Windowsである。私のコンピューターは、Appleが販売しているコンピューターではない。とすると、私はSafariの使用許諾の条件を満たしていないことになる。この条件を満たすユーザーとは、Boot CampでWindowsを使っているユーザーに限定されてしまう。

ちなみに、原文では以下のようになっている。

2. Permitted License Uses and Restrictions.
A. Subject to the terms and conditions of this License you are granted a limited non-exclusive license to install and use one copy of the Apple Software on each computer owned or controlled by you.

Apple商標が付されたコンピューターなどという文面はない。

2011-11-26

JavaScriptの難読化におすすめのサービス

aaencode - Encode any JavaScript program to Japanese style emoticons (^_^)

alert("Hello, JavaScript")

という何の変哲もないJavaScriptのコードが、

゚ω゚ノ= /`m´)ノ ~┻━┻   //*´∇`*/ ['_']; o=(゚ー゚)  =_=3; c=(゚Θ゚) =(゚ー゚)-(゚ー゚); (゚Д゚) =(゚Θ゚)= (o^_^o)/ (o^_^o);(゚Д゚)={゚Θ゚: '_' ,゚ω゚ノ : ((゚ω゚ノ==3) +'_') [゚Θ゚] ,゚ー゚ノ :(゚ω゚ノ+ '_')[o^_^o -(゚Θ゚)] ,゚Д゚ノ:((゚ー゚==3) +'_')[゚ー゚] }; (゚Д゚) [゚Θ゚] =((゚ω゚ノ==3) +'_') [c^_^o];(゚Д゚) ['c'] = ((゚Д゚)+'_') [ (゚ー゚)+(゚ー゚)-(゚Θ゚) ];(゚Д゚) ['o'] = ((゚Д゚)+'_') [゚Θ゚];(゚o゚)=(゚Д゚) ['c']+(゚Д゚) ['o']+(゚ω゚ノ +'_')[゚Θ゚]+ ((゚ω゚ノ==3) +'_') [゚ー゚] + ((゚Д゚) +'_') [(゚ー゚)+(゚ー゚)]+ ((゚ー゚==3) +'_') [゚Θ゚]+((゚ー゚==3) +'_') [(゚ー゚) - (゚Θ゚)]+(゚Д゚) ['c']+((゚Д゚)+'_') [(゚ー゚)+(゚ー゚)]+ (゚Д゚) ['o']+((゚ー゚==3) +'_') [゚Θ゚];(゚Д゚) ['_'] =(o^_^o) [゚o゚] [゚o゚];(゚ε゚)=((゚ー゚==3) +'_') [゚Θ゚]+ (゚Д゚) .゚Д゚ノ+((゚Д゚)+'_') [(゚ー゚) + (゚ー゚)]+((゚ー゚==3) +'_') [o^_^o -゚Θ゚]+((゚ー゚==3) +'_') [゚Θ゚]+ (゚ω゚ノ +'_') [゚Θ゚]; (゚ー゚)+=(゚Θ゚); (゚Д゚)[゚ε゚]='\\'; (゚Д゚).゚Θ゚ノ=(゚Д゚+ ゚ー゚)[o^_^o -(゚Θ゚)];(o゚ー゚o)=(゚ω゚ノ +'_')[c^_^o];(゚Д゚) [゚o゚]='\"';(゚Д゚) ['_'] ( (゚Д゚) ['_'] (゚ε゚+(゚Д゚)[゚o゚]+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ (゚Θ゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ ((゚ー゚) + (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+((゚ー゚) + (゚Θ゚))+ (c^_^o)+ (゚Д゚)[゚ε゚]+(゚ー゚)+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚Θ゚)+ (c^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ ((゚ー゚) + (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ ((゚ー゚) + (o^_^o))+ (゚Д゚)[゚ε゚]+((゚ー゚) + (゚Θ゚))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚ー゚)+ (c^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚Θ゚)+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ (゚Θ゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ ((o^_^o) +(o^_^o))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ (゚Θ゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) - (゚Θ゚))+ (o^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ (゚ー゚)+ (o^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((゚ー゚) + (゚Θ゚))+ (゚Θ゚)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ (c^_^o)+ (゚Д゚)[゚ε゚]+(゚Θ゚)+ ((o^_^o) +(o^_^o))+ (゚ー゚)+ (゚Д゚)[゚ε゚]+(゚ー゚)+ ((o^_^o) - (゚Θ゚))+ (゚Д゚)[゚ε゚]+((゚ー゚) + (゚Θ゚))+ (゚Θ゚)+ (゚Д゚)[゚o゚]) (゚Θ゚)) ('_');

という、訳のわからないコードに変換される。

2011-11-22

2011-11-19

信じられん

この工作精度はすごい。

2011-11-17

Windowsに日本の歴史的な年号を追加する方法

Extending the Windows Japanese Calendar Era information. - I'm not a Klingon

Windows 7/8ならば、レジストリに追加することで、日本の歴史的な年号を追加することができる。

もっとも、年号などいいかげんに滅びるべきである。我々はある時間を起点として線形にインクリメントされていく年号を採用すべきなのだ。年号に対する個人的な反対運動として、私は今年が平成何年であるかを覚えるのをやめている。

しかし、英語の月は数字を使っていないので、日本語と英語に関して言えば、日本が致命傷で引き分けといえるだろう。

2011-11-10

Skyrimのデザインについて思う

Skyrimの発売まで、間近になっている。まだ発売されていないとはいえ、Skyrimの内容については、事前の発表でだいたい明らかになっている。それをまとめているWikiも存在する。

Skyrim:Skyrim - UESPWiki

この情報を元に、Skyrimについて考察しようと思う。

Skyrimは、明らかに複雑性を減らす努力をしている。たとえば、Oblivionでは、八つの基本能力、Strength, Endurance, Intelligence, Willpower, Agility, Speed, Personality, Luckがあった。Health, Magicka, Fatigueなどは、これらの能力とレベルアップによる加算によって計算される従属的な能力であった。さらに、剣の威力は、剣自体の強さが、基本能力StrengthとLuck、スキルBladeによって修正された値であった。だいぶ複雑である。

Skyrimでは、この仕組が、だいぶ単純化されている。Skyrimにおける基本能力は三つ、Health, Magicka, Staminaだけである。もうStrengthやLuckは存在しないので、剣の威力は、単にOne-Handedによって修正されるだけである。

私は、この複雑性を下げることが、快適なゲームプレイにつながると思っている。かつてのゲームは、もっと複雑だったのだ。たとえば、Daggerfallでは、走る、泳ぐ、壁を登る、ジャンプするなどといった動作にそれぞれ独立したスキルが存在したし、避けるだとかクリティカルだとかいうスキルもあったし、ある種の敵と友好的になれるスキルもあった。これは、当時はハードの制約で、複雑性を誇れるものが、結局これぐらいしかなかったのである。

今や、ハードは素晴らしく進化した。リアルタイムなシェーダーによる3Dレンダリング、プロシージャルアニメーション、フルボイスは、全く珍しくない。とすれば、複雑性は、このような数値で実現する必要はないのだ。もっと別方法でいくらでも実現できる。

たとえば、MorrowindにあったMark/RecallやLevitationは、存在しない。これはべつに、技術上の問題ではない、自由にワープできたり空を飛べたりすると、ゲーム制作が非常に制限される。あらゆるダンジョンやらクエストは、ワープや飛行の存在を前提に設計しなければならない。聞説、Morrowindでは多くのクエストのアイディアが、「オゥイェア、そんなのレビテーションで切り抜けりゃいいじゃんHAHAHA」などというスタッフのツッコミによって、断念せざるを得なかったらしい。

興味深い話

The assault on Los Alamos National Laboratory: A drama in three acts

まあ、一言で言うなら、お役所仕事。

2011-11-08

うおおおお!

Twitter / @Flast_RO: キターーーーーーー喜べ野郎ども!!!!
Bug 45114 – implement C++0x alias-declaration

キタ━━━━(゚∀゚)━━━━!!

どうやら、Template Aliasまで含んでいるらしい。

JoystickAPIが欲しい

JoystickAPI - MozillaWiki

これは是非とも欲しい機能だ。これさえあれば、もうゲームのプラットフォームはブラウザだけで完結できることになる。

TPPへの反対を表明する

The complete Feb 10, 2011 text of the US proposal for the TPP IPR chapter | Knowledge Ecology International

5. Each Party shall provide that, where the term of protection of a work (including a photographic work), performance, or phonogram is to be calculated:

  • (a) on the basis of the life of a natural person, the term shall be not less than the life of the author and 70 years after the author’s death; and

  • (b) on a basis other than the life of a natural person, the term shall be:

    • (i) not less than 95 years from the end of the calendar year of the first authorized publication of the work, performance, or phonogram, or

    • (ii) failing such authorized publication within 25 years from the creation of the work, performance, or phonogram, not less than 120 years from the end of the calendar year of the creation of the work, performance, or phonogram.

アメリカの壊れた著作権法を押し付けられるいわれはない。これ以上著作権の保護期間を延ばす必要はない。今保護期間が延びるということは、将来も延びる可能性があるということだ。つまりそれは、著作権は永続するも同義である。

結局、戦前の死後30年の保護期間は、妥当だったはずだ。

2011-11-03

Skyrimがやりたい

Skyrimがやりたいが、やれない。

Skyrimがそろそろ発売される。もっとも、日本では12月まで待たなければならない。Bethesda公式ブログで11.11.11ワールドワイドなどと宣っているが、真っ赤な嘘である。

Skyrimは是非ともプレイしたいゲームだ。しかし、残念ながら、今プレイするわけにはいかない。金がないのだ。Skyrim自体はSteamで$59.99だが、Skyrimをプレイするためには、新しいGPUが必要である。まあ、GTX560あたりを買うと考えても、やはりしめてニ万はかかるであろう。

金のないだけが問題ではない。Skyrimはキリのないゲームである。まともに遊ぼうとすると、恐らく一年ほど飽きがこないであろう。当然、C++本の執筆にも差し支える。他の凡ゲーならば、せいぜい十数時間もあれば飽きてしまうから、まあ、息抜きに遊んでも、特に問題はない。ただし、Skyrimだけは別物なのだ。疑うことなく約束された神ゲーである。

まあ、どうせBethesdaのことだから、見切り発車で発売してバグだらけ、パッチに半年は待たなければならないだろうし、DLCもいくつか出るだろうし、MODも揃ってから遊んだほうが便利だが、やはり神ゲーを遊べないのはつらい。

思えば、今年は大作が多かった。それにもかかわらず、去年と今年は、一切ゲームをしていない。もちろん、すべて遊ぶ価値のないクソゲーだったからだ。もっとも、実際にプレイしたわけではなく、レビューやプレイ動画を見ての感想だから、所詮は動画評論家のそしりを免れないが、それでも、みているだけでつまらなそうなゲームは、実際つまらないに違いない。

まずBulletstormだ。これは、Trailerを見ると、面白そうだった。それに、Duty Callsというパロディゲームをマーケティング用に出したのも興味深かった。

ただし、実際のゲームは振るわなかった。つまらない単調な一本道ゲームだった。しかも、最後は続編を匂わせるクリフハンガーで終わるという、真につまらないゲームだった。

お次はCrysis 2だ。いや、Crysis 2に限って言えば、クソゲーというほどひどかったわけではない。ただ、どこにでもあるような平凡なゲームだったのだ。グラフィックはそれなりによかったが、戦略のカケラもない一本道ゲームだった。まあ、戦略はあった。Cloakで殆どの敵はやり過ごせるのだから。これまた、クリフハンガー的な終わり方をするプロットだった。まあ、確かにブランドは大事だが、露骨にクリフハンガーにしても面白いわけがない。思うに、Crysis 2はゲームなどではなく、CryEngine 3の技術デモだったのではあるまいか。それぐらい、ゲームらしくないゲームだった。

さて、いよいよDuke Nukem Foreverだ。最も、最近の若いもんはDuke Nukemもしらんじゃろうが、かつては伝説のゲームだったのじゃて。DNFが発売されてしまったのは、真に残念なことだった。夢は夢として、いつまでも夢見ていたほうが幸せなのだ。現実は常に夢よりクソである。Duke Nukem Foreverは、5年前に発売したならば、まあ、そこそこなゲームだったに違いない。クソゲーなことには変わりないが、まあ当時の水準ならば、普通以下程度の評価は得られたに違いない。今となっては・・・いや、よそう。もう何も言うまい。

Rageである。Rageも長い間開発していたゲームだった。Doom 3は真っ暗なゲームだった。私が思うに、Doom 3は全ピクセルに黒をアルファブレンドすれば、もっとも効率よく実装できたのではあるまいか。それぐらい暗かった。それはさておき、伝説のゲーム開発会社idと、伝説のゲームプログラマーJohn Carmackの送る最新ゲームRageは、非常に期待されていた。思うに、我々はRageを過剰に期待しすぎていたのではないだろうか。それも無理はない。何しろ、2008年のE3におけるTrailerが、今から見ると詐欺臭いほどのクオリティだったからだ。

これをみれば、過剰に期待するのも当然である。結果は散々だった。メガテクスチャーは20GBもの容量を使い、しかも視点を動かすだけで貼り遅れるという散々な出来であった。しかもボケボケで見るに耐えない。オープンワールドでもないのに、無駄に車や移動といった要素がある。聞説、FPS部分はよくできていたらしい。もっとも、頻繁に移動しなければならないが苦痛だったらしいが。それでも、プレイ時間はたったの十数時間と聞く。プロットなどあってないようなもの。エンディングもエンディングのようには感じられない。何もかもが中途半端なのだ。クリフハンガーですらないのだ。ひょっとしたら、もうこれ以上収集がつかなくなり、とりあえず開発資金を回収しようと、無理やり出荷したのではあるまいか。実際、開発に相当の金がかかっているはずである。最後はBethesdaに身売りまでしたのだから。

こうしてみると、今年は遊ぶべきゲームが一切なかったのだ。Skyrimは約束された神ゲーなので大丈夫だろうとは思う。遊べないのが本当に残念だ。

実は、今年はまだ、もう一本、大作(?)が控えている。Postal 3である。Postal 3も、DNFやRageに引けを取らないほど長く開発されているゲームである。何しろ土台がSourceエンジンなのだ。前作のPostal 2が神ゲーであったことは、議論の余地がない。しかし、長年の延期の末に、ようやくだして、果たして面白いものかどうか。その辺は疑問である。

2011-10-30

Dartにおける代入可能について

まず最初に英語で書いてから日本に訳すという方法で書いてみた。何か違いが出るだろうか。

Dartはoptional typeを採用している。ある変数に代入できない型を代入しようとした場合、静的型警告が発せられる。ただし、プロダクションモードで実行された場合は、実行に何の影響も及ぼさない。

int x = "hello" ; // static type warning

では、代入可能とは一体何か。どのように定義されているのか。13.4 Interface Typesで定義されている。

型Tが型Sに代入可能である場合、すなわち、s = t でtの型がTでありsの型がSである場合というのは、

  • TはSである。

    int s = 0 ;
    

    これは当然だ。.

  • Tはnullである。

    int s1 = null ;
    

    nullは、⊥という特別な型を持っている。これは、どんな型にも代入可能である。

  • TかS、あるいはその両方がDynamicであるとき。

    void main()
    {
        var s1 = 0 ; 
        s1 = 0.0 ; 
        s1 = "hello" ;
    
        var d = 0 ;
        double s2 = d ;
    }
    

    動的型intを持つdを静的型doubleを持つs2に代入しているが、これは代入可能である。したがって、static type warningは発せられない。確かに、実行時には型の不一致を起こすが、それは実行時にしか分からないので、静的警告は発しようがない。

  • SとTがジェネリック型I<...>であり、Tの型パラメーターが、それぞれSの対応する型パラメーターに代入可能な時。

    void main()
    {
        List<int> = <int>[] ;
        List<num> = <int>[] ;
        List = [ ] ; // List<Dynamic>
    }
    

Assignable in Dart

Dart use the optional type. When you assigned to a variable and it isn't assignable, a static type warning is issued. If the code is executed under the production mode, it doesn't affect run time behavior.

int x = "hello" ; // static type warning

So, what exactly is assignable? How is it defined? It's defined in 13.4 Interface Types.

A type T may be assigned to a type S, that is s = t where the type of t is T and the type of s is S, if

  • T is S

    int s = 0 ;
    

    This is obvious.

  • T is null

    int s1 = null ;
    

    null has the special type ⊥. It can be assigned to any type.

  • T or S(or both) are Dynamic.

    void main()
    {
        var s1 = 0 ; 
        s1 = 0.0 ; 
        s1 = "hello" ;
    
        var d = 0 ;
        double s2 = d ;
    }
    

    Notice assigning d(dynamic type of int) to s2(static type of double) is not a static type warning although it is incorrect in run-time. This is because it's assignable. If either T or S are Dynamic, it can't be determined in compile time. So it makes sense.

  • if S and T is a generic type of I<...> and T's type parameters are assignable to S's corresponding type parameters.

    void main()
    {
        List<int> = <int>[] ;
        List<num> = <int>[] ;
        List = [ ] ; // List<Dynamic>
    }
    

2011-10-28

What is it like buying a PC game in Japan?

Today, I saw kotaku used an interesting metaphor to describe what is it like buying a PC game.
If Haruki Murakami's New Book Were Sold Like a Video Game

I think buying a PC game from Japan is also interesting to write about. Even without the metapher.

It started in January...

January
I've heard a famous game developer will release a new game in June. Wow that's too soon. I must pre-order it immediately. But I wonder where to buy it. And the most important thing is, is there a Japanese translation available?

February
It appears the game requires Steam activation. So the package means nothing. I don't need some junk toys they'll include in the package. I wonder who want that crap. I can't understand what Americans are thinking. Anyway, I pre-order it in so called Steam. It allows me to download a game. That's nice. The Japanese Steam listed it up and allows me to pre-order. So it should work. And I've heard they'll release console version of this game in Japan. So naturally, PC version must have Japanese translation.

March
They announced that Japanese translation will be released in August. Well, that's okay. I guess translation need some time. I've also heard they even translate the voice. That's fine. Perhaps I should try English version while waiting. It's completely incomprehensible for me. But who needs story in game anyway? This is not a dull linear JRPG. That's why I'll buy it. I'm so sick of crappy JRPG. Look at the world. Think globally. I can look up words from dictionary if I have to. I'll enjoy the combat in the English version. Then, I'll enjoy the story later in the Japanese version.

April
What Steam? What do you mean I can't buy it from the current location? I am Japanese and sure I live in Japan. Yes I know this is the English version. I want to play regardless and I'm willing to pay. Why don't you let me buy it? Don't you want my goddamn money? This is stupid. I can't understand it. I don't care how much you charge me. I've read from the online forum that we can bypass that check by using what they call it VPN or whatever. I don't know how that works. Also, there are pirates as usual. But I'm not one of them. Besides, I don't know how to pirate a game.

June
At last. The English version is released. I think some people who used VPN will write something in forum. I should better check it... What? Not only they play it today, But they play it in Japanese? How could that even be possible? Well, come to think of it, console game will be released in a few days. So technically, translation works must have been finished already. So what is the point of delay? Why do I have to wait two months!

July
Wow. This is hilarious. They said Steam deleted Japanese translation from their disks. Apparently, It wasn't supposed to be released. But why. Just release the Japanese version already. I don't want to wait any more. Also, why do they allowed to delete files in our disks? I don't understand.

August
What is this? What the FUCK is this? They said they'll delay the release until next year. No. Seriously. That can't be possible. I have enough of this Steam.

2011-10-22

Dartがダウンキャストに警告を出さない理由

Dartでは、ダウンキャストには警告を発しない。

class S { }
class T extends S { }

void main()
{
    S s = new T() ; // アップキャスト
    T t = new S() ; // ダウンキャスト
}

この例では、静的型Tの変数tに対して、静的型Sで、実際の型もSのインスタンスを束縛させているが、これは警告を発しない。アップキャストに警告を発しないというのは自然だが、ダウンキャストに警告を発しないというのは、オブジェクト指向に馴染みのない人からすれば、不思議に思われるかも知れない。現にこの場合、実際の型はTではないのだから、この場合に限っていえば、エラーである。しかし、これは正しい挙動である。では、なぜ警告を発しないのか。

なぜならば、規格に明確に書かれている挙動だからである(13.4 Interface Types)。クラスは暗黙のインターフェースを持つので、この項目はクラスにも適用される。

規格で定義されているとしても、理由はなぜか。それは、Dartの型システムは、ほぼ確実に間違いであろうと思われるコードを見つけるためにあるからだ。間違いである可能性があっても、正当なコードである可能性もあるコードに対しては、警告を発しない。

ダウンキャストは、オブジェクト指向言語ならば、当然行うことである。

class S { }
class T extends S { }

void main()
{
    S s = new T() ; // アップキャスト
    T t = s ; // ダウンキャスト
}

これは、正しいコードである。変数sに束縛されているインスタンスの型は、まぎれもなくTである。したがって、このダウンキャストは正しい。もしこのコードに警告が発せられるとするならば、それは誤りである。このコードに警告を発するようでは、プログラマーは警告というものを信用しなくなってしまう。警告というのは、ほぼ確実に誤りである場合にのみ発せられるべきなのだ。

SとかTなどのやや抽象的な話ではわかりにくい人もいるかも知れない。もっと具体的な話をしよう。Dartではすべてのクラスは暗黙にObjectのサブクラスである。以下のコードは当然動くべきである。

void main()
{
    Object obj = "hello" ;
    String str = obj ; 
}

明らかに、このコードは正しいコードである。

2011-10-21

Bitcoinについて

Coding Horror: Multiple Video Cardsが、Bitcoinのお陰で中古GPUを格安で手に入れられたと書いていたので、Bitcoinの歴史と現状をまとめて見ることにした。

そもそも、諸君はBitcoinを知っているだろうか。いや、知らなくても無理はない。日本では、あまり有名ではないように思う。だから、まずBitcoinとは何かという説明をしようと思う。

Bitcoinとは、演算保証によって信頼を得ている貨幣である。およそ、貨幣というものが広く一般に使われるには、貨幣に対する何らかの信頼が必要である。たとえば、貨幣が金と交換できる保証であるとか、国による保証などといった、信頼が必要である。そのような強い保証のない貨幣は、広く信頼を得ることができず、一般に普及することはない。

Bitcoinは、P2P技術によって実装されたオンライン上の仮想貨幣である。すべての貨幣のやり取りはP2Pによる演算で処理され、個々の貨幣のやり取りは匿名で行うことができる。と、こう書いただけでは、信用のカケラも存在しない貨幣のように思われる。金と交換できず、国家の保証もない貨幣が、どうして信頼できるというのか。だいたい、どうやって偽造を防ぐのだ。それは、演算力である。

Bitcoinを得るには、演算をする必要がある。それも、かなりの演算が必要である。Bitcoinの貨幣のやり取りをP2P上で信頼できるほどに処理するには、暗号を使わなければならない。この暗号処理には、かなりの演算力を必要とする。Bitcoinを得るには、オンライン上でのbitcoinのやり取りに必要な演算の一部を負担する必要がある。すると、Bitcoinを不正に入手するというのは、つまりは暗号を解読するということである。それには、Bitcoinを普通の方法で得るより、はるかに高い演算力を必要とする。このため、Bitcoinの偽造は割にあわないということになる。ただし、誰かがSHA256の画期的な脆弱性を発見した場合は、この限りではない。Bitcoinネットワークを攻撃するには、Bitcoinネットワーク全体の演算力を上回る演算力が必要である。その演算力は、現在のBitcoinネットワークの規模から考えて、現実的ではない。

つまり、Bitcoinの信頼は、演算力とSHA256の暗号強度に依存しているといえる。金銀に交換することはできず、国家の保証もないとはいえ、不正ができないという点で、信頼を得ているのである。

Bitcoinの他の利点としては、国家の影響を受けないということと、プライバシーを守れるということである。国家が貨幣を管理していると、意図的に貨幣の価値を上下させられる可能性がある。Bitcoinの価値は、ユーザーが決定する。そのような中央の権威の影響は受けない。プライバシーというのは、貨幣の動きを特定されないということである。これは、ともすれば麻薬取引などの違法な売買や、脱税などの金銭の動きにも使われがちであるが、それは、別にBitcoinに限った話ではなく、金銀や紙幣でも同じなので、Bitcoin特有の問題というわけでもない。

では、Bitcoinの作者は誰か。これが、どうも怪しいのだ。もちろん、記録は残っている。2008年にSatoshi Nakamotoと名乗る自称日本人によって、Bitcoinの理論と仕様を説明する論文が発表された。最初の実装も、彼によって書かれた。しかし、彼は一言も日本語を発していないし、実装にも日本語は一切使われていない。彼の2010年以降の消息は不明である。彼のメールアドレスは、無料のメールサービスを利用しており、すべての接続は、Tor経由で行われていた。つまり、彼はありとあらゆる方法を使って、匿名性を保つ努力をしていたのである。日本人を自称したのも、事によると、正体を隠すための方便だったのかもしれないとまで言われている。

なんにせよ、Bitcoinの仕組み自体には、未だに脆弱性が見つかっていないし、Bitcoinで使う有名な暗号、SHA256も、未だに画期的な脆弱性は見つかっていない。

さて、Bitcoinは不正が難しいので、最低限の信頼性を備えていることは分かった。Bitcoinの仕様はすべて公開されており、オリジナルの実装以外にも、いくつかの別の実装がでてきた。とくに興味深いのは、演算にGPUを利用した実装である。GPUはCPUほど汎用的ではないが、うまく使えば、CPU以上の演算力を発揮できる。このため、Bitcoin mining(Bitcoin炭鉱業)と呼ばれる、いわばゴールドラッシュのような現象が起きた。高価なGPUが、Bitcoinを稼ぐために多数売れたのである。

Bitcoinはその期待によって、現実の貨幣(例えば米ドル)と交換する所が現れた。その交換レートが高かったので、高価なGPUと電気代を差し引いても、利益が出せたのである。

しかし、ゴールドラッシュが長く続くわけがない。Bitcoinはその多大な期待によって、実価値以上に高い交換レートで、現実の貨幣と交換されてきた。今や、そのバブルがはじけて、Bitcoinの現実貨幣に対する交換レートは暴落し、Bitcoin炭鉱業は以前ほど儲からなくなってしまった。国家や中央銀行のように、貨幣の価値を一定に保つ権威が存在しないのだから、これは当然である。ゴールドラッシュで儲けたのは、シャベルとツルハシを売っていた者であるというのはよく言ったものだ。ハイエンドGPUが山ほど売れたのだ。

そのため、ハイエンドGPUが中古市場に溢れ、冒頭でも言ったように、Jeff Atwoodとかのゲーマーがその恩恵を受けている。

もちろん、これはBitcoinの為替が適正なレートに下がっただけであり、Bitcoinの暗号自体は、未だに破られていない。

Bitcoinの合法性であるが、独自通貨の発行が合法かどうかということにかかっている。これは、国ごとに違うので、なんとも言えない。ただし、オンラインでの売買の興隆をみれば、独自通貨の発行自体は、将来的には大抵の国で合法になる方向に動くだろう。さもなければ、ゲームやPaypalのようなサービスが成り立たない。

私自身はBitcoinには興味がなかったのだが、知り合いに、Bitcoinの仕組みに共感し、自分でも実装を書き、ハイエンドGPUでせっせと掘っている人物がいるので、近況を聞いてみた。彼は、単に技術的な好奇心のためにやっているのであって、小遣い程度の金には興味がなく、したがって、最近のBitcoinと現実貨幣の交換レートの暴落は気にしていないらしい。

私はふと、このBitcoinが、一時期のP2P技術を利用したファイル共有に対する期待に似ているのではないかと思った。あの当時、P2P技術を利用したファイル共有には、なにかゴールドラッシュのような期待があった。確かに、現時点では違法かもしれないが、それは法律が現実に追いついていないだけであって、将来的には素晴らしい可能性を秘めているのではないかという期待があった。

現実としては、法律は一向に変わらず、P2P技術は、Skypeを始めとする通信、ソフトウェアのアップデートの配布などの、裏方技術には使われているが、表立って存在を意識するほどではなくなってしまった。Bitcoinも同じような過剰の期待に押されていたのではないだろうか。

このような意見を、かの知り合いにぶつけてみたところ、彼はこれを認めた。曰く、「たしかに、そういう過剰な期待があるのかもしれない」と。「Bitcoinに触発された後発の仕様もいくつか出ている。Bitcoinは、実際の価値はさておき、コンセプトとして一定の価値があることは確かだろう」とも言っていた。

国家に左右されない貨幣が主流になる時代は来るのだろうか。

アイドック株式会社、紙書籍と電子書籍の抱き合わせ商法を発表

デジタル著作権管理(DRM)ならキーリング|愛読者カード運営代行サービス「i 読(あいどく)」提供開始!!
i読…愛読者カード運営代行サービス
via : これで自炊は不要? 愛読者カード返送者にのみ電子書籍を配信する「i読」 -INTERNET Watch

レコードをカセットテープに録音する? おいおい、何言ってやんでぇ。そんなのオイラの目の黒いうちゃぁ許しちゃおけねぇよ。レコード針やターンテーブルの生産会社が潰れちまうだろうがよ。代わりにこれ、レコードを買うと録音したカセットテープをプレゼント。あ、ほら、もう録音なんてする必要がねぇってもんだ。これにて一件落着。あっぱれあっぱれ。

DTP? よしてくれよ、写植職人が路頭に迷うぞ。最低限でもだな、今の写植と同じ仕組みでなければな。もちろん操作方法も同じだ。

活版印刷? おいおい、版木職人を飢え死にさせる気か? まあ仕方がないから、版木本を買えば、活字本もおまけしてやろうじゃないかい。

版木? そんなの許しちゃおけねぇ。真の書というものはよく手書く者によって写されるべきなんだよ。このままだと、写本職人が失業するだろうがよ。そこでこれ、写本を買うともれなく版木本をプレゼント。

紙? おいおいバカ言っちゃいけねぇや。日常の文章は木簡や竹簡に書いて、高級な文章は絹に書くのが常識だろうがよ。紙なんていう最近できたもんに字なんか書けるかってんだ。

字? おまえなぁ、生きておる智慧が、字などという死物に書きとどめられるはずがない。絵にならまだしも画けようが。それより口伝の続きじゃ。さて我がご先祖は~、怨敵をことごとく討ち平らげ~、この地に来たりて安住し~。さあ覚えるんじゃ。

2011-10-19

Dartで誤って無限ループに陥るコード

Dartは非常にシンプルな言語であるが、恐らく初心者が、誤って無限ループに陥ると思われる箇所がいくつかある。

ファクトリーコンストラクター

class X
{
    factory X() =>  new X() ; // 無限ループ
} 

void main()
{
    X x = new X() ;
}

このコードは、無限ループに陥る。なぜならば、new X()というのは、ファクトリーコンストラクターXを呼び出す式である。これは、つまり自分自身を再帰呼び出ししていることになる。結果として、無限ループになる。

正しいファクトリーコンストラクターの書き方は、別のコンストラクターを呼び出すものである。

class X
{
    X.internal() { }
    factory X() => new X.internal() ;
}

クラスのゲッターとセッター

クラスのゲッターとセッターは、クラスの変数への簡単な読み書きを提供するための特殊なメソッドである。これは、暗黙に生成される。

class X
{
    int val = 0 ;
// 以下のようなゲッターとセッターが暗黙的に生成される
    // int get val() => val ;
    // void set val( int value ) { val = value ; }
}

void main()
{
    X x = new X() ;
    x.val ; // ゲッター呼び出し
    x.val = 0 ; // セッター呼び出し
}

ご覧のように、セッターとゲッターは関数であるが、特別な文法で呼び出すことができるのだ。

サブクラスでは、この暗黙のゲッターとセッターをオーバーライドすることができる。つまり、ゲッターとセッターで、なにか複雑な処理を行うこともできるのだ。

class X { int val = 0 ; }
class Y extends X
{
    int get val() => val ; // 無限ループ
}

これは無限ループとなる。なぜか。考えてみて欲しい、クラスYのスコープにおけるvalとは何なのか。それは、もちろんYのスコープで宣言されているvalである。つまり、Yのゲッター関数valということになる。これは、自分自身の再帰呼び出しである。つまり、無限ループになる。

正しいサブクラスによるゲッターとセッターのオーバーライドは、スーパークラスのゲッターとセッターを呼び出すものである。

class X { int val = 0 ; }
class Y extends X
{
    int get val() => super.val ;
 
}

これで、再帰呼び出しは起こらない。

ちなみにいうと、ゲッターとセッターはトップレベル関数でも使える。

int _val = 0 ;

int get val()
{
    print("このままでは菌類が死滅してしまう") ;
    return _val ;
}

void set val( int value )
{
    print("勉強でも仕事でも 楽しんでやったものが、一番自分の力になるものさ。") ;
    _val = value ;
}

void main()
{
    int x = val ;
    val = 1 ;
}

ChromeがText-to-Speech APIを提供

Chromium Blog: New Text-to-Speech API for Chrome extensions

Chromeがエクステンション向けにText-to-Speech APIを提供するらしい。これは面白そうだ。

2011-10-18

Dartの興味深い機能

named parameterとnamed argument

void f( int x, [ int y = 0, int z = 0 ] ) { }

void main()
{
    f( 0 ) ; // f( 0, 0, 0 )
    f( 0, 1 ) ; // f( 0, 1, 0 ) 
    f( 0, z : 1 ) ; // f( 0, 0, 1 ) 
}

まあ、コードを読めば一目瞭然の機能だろう。省略可能なのは、named parameterだけである。名前を指定できるのも、named parameterだけである。normalFormalParameterは省略も名前指定もできない。

noSuchMethod

class X
{
    void noSuchMethod( String function_name, List args )
    {
        print("$function_name") ;
        for ( var elem in args )
        { print("$elem") ; }
    }
}

void main()
{
    X x = new X() ;
    // 関数名と実引数が表示される
    x.f() ; 
    x.hoge(1,2,3,4,5) ;
    x.fuga("All base is belong to us.")
}

これは解説が必要だろう。もし、クラスからメソッド名のlookupに失敗した場合、そのクラスからnoSuchMethodという名前のインスタンスメソッドが探され、第一引数としてメソッド名を、第二引数として、実引数のリストを渡し、呼び出されるのだ。もし、noSuchMethodという名前のインスタンスメソッドがなければ、NoSuchMethodExceptionが投げられる。

ということはだ、noSuchMethodというインスタンスメソッドを定義していれば、あたかもoperator .を定義したかのように振る舞うのだ。もちろん、実際にはoperator .はないし、メソッド呼び出しにしか適用できないが、DSLオタクは歓喜するだろう。

typedef

typedef int func_type(int) ;

void f( func_type func )
{
    int x = func( 0 ) ;
}
main()
{
    f( (int x) => x + 1 ) ;
}

typedefは、静的型の別名を定義するための構文である。現在のところ、関数の静的型の別名を定義することしかできない。

これはなぜかというと、関数は、具体的な静的型を直接に指定するのは面倒なのだ。こんなふうになってしまう。

void f( int func(int) ) { }

インターフェースFunctionはあるが、あまりにアバウトすぎる。だから、厳密な静的型を意味する識別子を定義するために、このtypedefが存在する。

べつに、これを使う必要はない。たとえば、varで受けても問題ない。DartはOptional Typeを採用しているからだ。静的型は実行時には、ほとんど意味がない。

量子浮遊

こいつは最高にクールだ。

2011-10-17

さっそくDartの規格上のバグを発見

私の唯一誇れる能力は、読解力である。そのため、私がプログラミング言語の規格を読むのを好むのは、自然なことである。このたび、Dartの規格上のバグを発見した。なかなか笑えるので紹介する。もちろん、実装者にとっては洒落にならないが。

以下のコードは、現行ドラフトの文面に従うと、well-formedなDartコードである。

main()
{
    a : { break a ; }
    b : { continue b ; }
}

なぜかというと、現行のDartのドラフト規格は、ラベル付きのbreak文とcontinue文は、label文の中に入ることができるとされている。ラベル文には、文を書ける。また、ブロック文も文である。よって、Label : { } はwell-formedなDartコードであり、その中でbreakやcontinueを使うのもwell-formedである・・・はずだ。

傑作だったのは、現行の実装が、このコードを実際にコンパイルできてしまうということだ。break文の方は、期待通りに動いた。つまり、

a : { print("before") ; break a ; print("after") ; }

は、beforeを出力する。

continue文の方は、コンパイルは通るが、実行時に、不思議なエラーを吐いて強制終了してしまう。もし規格通りに動いていたならば、無限ループになったはずだ。

この件はすでにバグ報告済みである。

DartのFlorian Loitschとのチャット

IRCのチャットで興味深かったチャットの断片をいくつか。

ezoe: 単項マイナス演算子をユーザー定義するにはnegateを使わないといけないのはちょっと驚きだね。
floitsch:何か代案でも?
ezoe:いや、別に不満ってわけでもないけど、理解するのに戸惑ったし、パースでも早くなるのかな?
floitsch:-は二項演算子にすでに取られてるからね。
floitsch:もちろん、引数の数を見て判断することもできるけど、それは他ではやってない処理だから、"operator negate"を導入することにした。
ezoe:なるほど、つまり例外的なルールを作りたくなかったのか。

ezoe:そういえば~/演算子ってのもあるけど、他の言語でこの演算子を使ってるのは知らないな。
floitsch:多分ないよ。
floitsch:切り捨ての除算が欲しかったんだ。
TheSheep://?みたいな?
floitsch:そうそれ。
floitsch:それも考えたんだけど、すぐ却下した。
TheSheep:他の言語でも使ってるよ。
TheSheep:特にpythonとかw
ezoe:一行コメントみたいだね。
TheSheep:あ!
floitsch:ほらね
floitsch:他の言語で、/や//以外で、切り捨て除算の演算子があるなら、教えてほしい。

ezoe:ふーむ、>>>演算子もあるね。
floitsch:イエス
floitsch:僕が推したやつだよ。
ezoe:どのコアライブラリが何のために使ってるの?
floitsch:なにも。
ezoe:えーと、まあ、ユーザー宣言可能な演算子が増えるってのはいいことだけど、でもコアライブラリすら使ってないんじゃ・・・
floitsch:>>>はunsigned shiftを意味する。
ezoe:>>は?
floitsch:signed shift
floitsch:そもそも、無限の精度をもった整数のunsignedな値って何さ?
floitsch:だから、コアライブラリでは>>>を定義していないんだ。

TheSheep:dartのintってjavascriptではどの型に対応するの? number?
floitsch:そう、JSのnumberさ。
TheSheep:それ固定精度じゃないじゃん。
floitsch:まあ、JSにコンパイルされたらdoubleさ。
floitsch:もちろん、それに起因する驚くべき挙動もそのままさ。
ezoe:なんだって?
floitsch:すべてのdartの数値は、JSのdoubleにコンパイルされる。
TheSheep:JSで動くツケさ。
floitsch:その通り
ezoe:そんなの整数じゃない・・・DartCが特別なコードを生成して多長演算をしてくれるかと思ってたのに。
floitsch:そりゃ遅すぎる。
TheSheep:そりゃ「遅い」
floitsch:そんなに悪くはないよ。
floitsch:ほとんどの数値は32bit以下だからね。
floitsch:それ以上が必要な場合は、開発者は分かるはずだ(Javaのlongとか)
ezoe:dart VMは任意の精度の数値を提供しているの?
floitsch:イエス

(末尾再帰最適化の話がでた後で)
ezoe:ファクトリーコンストラクターから同じコンストラクターをnew経由で呼び出してしまったことがある。俺は何を期待してたんだっていうw
floitsch:はは、結果を長く待たずに済んだことを祈るよ。
ezoe:でも、初心者は同じ間違いをすると思うんだ。
floitsch:直接の再帰呼び出しは、簡単に判定できるはずさ。
floitsch:IDEによって補足されて警告が出せるようになるといいかも。
ezoe:そうなってほしいな。うっかり書くこともありえると思う。

DartCではDartの数値をJavascriptのNumberにそのまま割り当てているとは驚きだった。JavascriptのNumberは、御存知の通り、内部的には浮動小数点数なのだ。まあ、大抵の場合は、その精度が気になることはないとはいえ、まさか規格で無限精度と定められているものを無視するとは。まあ、JSへのコンパイルは、移行措置のようなものなので、その程度の実装でも困らないのだろう。それより、数値計算の遅くなってしまうほうが問題だ。

ファクトリコンストラクターの条は、私がファクトリーコンストラクターを試したときに遭遇したうっかり間違いである。とりあえず、手っ取り早くファクトリーの文法を確かめようとして、以下のように書いてしまった

class X
{
    factory X()
    {
        return new X() ; // 再帰による無限ループ
    }
}

ファクトリークラスからは、別のコンストラクターを呼びださなければならない。

class X
{
    X.detail() { }
    factory X()
    {
        return new X.detail() ; // ファクトリーではないコンストラクターを呼び出す
    }
}

main()
{
    X x = new X() ; // ユーザーコードからはX.detailを使う必要はない

}

2011-10-16

数学を学ぶべきなんだろうか

Dartの規格に、次のような文がある。

The static type of null is ⊥.

The decision to use ⊥ instead of Null allows null to be assigned everywhere without complaint by the static checker.

現行のドラフト規格にはbeがニ連続するtypoあり。

この⊥が何を意味するのか分からなかった。しかたがないので、IRCで人に聞いた。

私:この⊥ってやつはなんだ?
人:"bottom"
私:bottom? 何かプログラミングか数学の用語なのか?
人:lattice theoryから来てる。
人:top(本当は特別な文字があるけど)ってのがすべての上にたつ汎用的な存在で、たとえばObjectだね。
人:bottomは何よりも特殊な存在なんだ。
私:つまり、bottomであるnullからみれば、すべての型はスーパークラスのようなものだということか。
人:そういうこと。

ちなみに、topの記号は⊤で、UnicodeではU+22A4である。⊥はU+22A5である。

なぜか、昔から数学はさっぱり理解できなかった。高校生の時、理系クラスに進もうとしたら、親に反対された。特に普段、勉強しろとも言わない親ではあったが、子供の勉強を反対するというのも奇妙だ。その時の言葉が印象に残っている。

「あんたに数学は無理よ。私達にだってできなかったんだから」

まるで、なにか遺伝的、先天的に数学ができないかような物言いだったのである。私の両親はそれなりに高学歴である。これは一体どういうことか。

親の案の定、私は数学をさっぱり理解できず、高校時代は、古文、漢文、英文を読んで過ごした。なぜか、私の親と同じ道をたどっているのである。

思えば、私も変な子供だったものだ。何故か昔から読書が好きだったし、小学生の頃には、すでに古事記や論語や徒然草などを読んでいた。もちろん、これは親がそのような本を家に置いていたし、「論語のどこそこ 」とか、「徒然草の第何段」といった会話が成立するほどの教養を持っていたからということもあるのだろうが、やはり不思議なことだ。何か、遺伝的なものがあるのだろうか。

今だって、私の感じるプログラミングの面白さとは、コードを書くのではなく、プログラミング言語の文法を理解することなのだ。何故こうなってしまったのだろう。

2011-10-15

DartのOptional Typeについて

Dartの素晴らしさがまだ分からない無知無識の者が、Dartの型システムについて深刻な誤解をしている。ここでは、Dartの型システムであるOptional Typeについて、ひとつ解説をする。これを読めば、Dartの如何に大昔のJavascriptより優れているかが、一目瞭然であろう。

強い静的な型付けは、C++のような、ほとんどを静的に決定する言語では非常に便利である。しかし、動的な言語では、むしろ邪魔にさえ感じる。

Dartの型システムは、Optionalである。型を明示的に書こうが書くまいが、自由である。

変数には、型を指定してもしなくてもよい。

var x = 0 ;
int x = 0 ;

関数の引数には、型を指定してもしなくてもよい。

int f( int x ) => x ;
f( x ) => x ;

ジェネリックのタイプパラメーターには、型を指定してもしなくても良い。

List<int> l = <int>[ 1, 2, 3 ] ;
List l = [ 1, 2, 3 ] ;

異なる型を代入することもできる。

int x = "肩のうしろの2本のツノのまんなかにあるトサカの下のウロコの右" ; // static type warning

これでは、型の意味が無いではないかと思う者もいるだろう。それは、Dartにおける型の目的を理解していないからである。Dartにおける型システムは、最適化のためにあるのではないのだ。ツールを助けるためにあるのだ。

まず、Dartの変数について一言説明しておかなければならない。Dartの変数とは、「メモリー上のストレージの場所を示す」ものである。これは、Javascriptのような言語に親しい物には、馴染み深い概念である。そのような言語に馴染みのないものには、とりあえず、ポインターだと考えておけばよい。もちろん、ポインターは、実際には異なる概念である。ポインターとは、やはり、メモリー上のストレージの場所を指し示す、すなわち「アドレス」を格納するために必要なだけのサイズのストレージであって、Dartの変数ではない。DartやJavascriptのような言語では、変数はすべてメモリー上のストレージへの参照であり、その参照を格納するストレージを意識することはない。

Dartにおける変数とは、内部的には、単にオブジェクトへの参照なのだから、型という仕組みがなかったとしても、不思議ではない。たとえば、DartやJavascriptでは、

var x = 0 ;
x = 1.5 ;
x = "肩のうしろの2本のゴボウのまんなかにあるスネ毛の下のロココ調の右" ;

このようなことができる。Dartにおける「代入」とは、単に変数が参照する場所を変えているだけである。変数自体は、固定されたストレージを持たないのだ。もちろん、実装上はストレージを持つが、それはユーザー側からは隠されている。

しかし、Javascriptのように、ソースコード上では、変数が型情報を持たないとすると、少々厄介である。

たとえば、ある変数はある型だと想定して使っているのに、うっかりと別の型を代入してしまったばかりに、型が変わってしまう。もちろん、コンパイルエラーどころか、警告すら出せないので、このバグを探すのは非常に難しい。プログラマーは、自分の目でバグを探さなければならないだろう。

Dartにおける型とは、言わばannotationなのだ。

int x = 0 ;
x = 1 ; // OK
x = 1.5 ; // Static type warning.

このように、型が合わない場合、コンパイル時に警告を出すことができる。そのため、プログラマーは目でコードを探す必要がなくなる。

現代では、IDEによるコード支援が盛んである。例えば、識別子を補完したり、メソッド名を補完したりしてくれるのは、非常に便利である。ところが、Javascriptのように型がないと、これは少し難しい。

var x = "肩ぐるまして後ろ向きに乗り2本のゴボウを持った歌舞伎顔の男" ;
x. // ←ここに注目

xという識別子に続いて、ドットを使っているのに注目してもらいたい。賢いIDEならば、ドットを打った時点で、プログラマーはメソッドを呼び出したいのだと解釈し、メソッドの一覧を表示してくれることだろう。ただし、この場合、xの型を静的に求めるのは難しい。

上記のような二例であれば、静的な解析でも可能である。ところが、Javascriptには、不可能な場合もあるのだ。

function f( x )
{
    x. // xは何かって? (´・ω・`)知らんがな
}

これはどうしようもない例である。

Dartでは、型をannotationのように指定することができる。そのため、静的ツールは静的に型を決定することができる。

f( String x )
{
    x. // Dartならば、IDEによってメソッド名の一覧を表示可能(`・ω・´)シャキーン
}

文法上、型を書くことができるというのは、コメントで書くよりもずっと分かりやすい。

var x = 0 ; // type of x suppose to be int. 
int x = 0 ; // horay! no comment is needed!

しかし、実行時に型が一致しなくても、エラーとはならない。つまり、実行を続けることができるのだ。ただし、警告は出るので、バグを見つけることができる。もし、型を固定したくなければ、varを使うこともできる。自由である!

2011-10-14

Dennis Ritchieに関する良記事

Rob Pike - Google+ - I just heard that, after a long illness, Dennis Ritchie…

氏の死去を始めて公にしたページ。

Dennis Ritchie, 70, Dies, Programming Trailblazer - NYTimes.com

NY Timesの記事。個人的な経歴もまとまっていて、なかなかの良記事。

Dennis Ritchie « Sutter's Mill

Herb SutterによるRitchieの回顧。Ritchieは、それまで不可能だと言われていた、portableでefficientな言語を発明した男である。

Interview with Dennis Ritchie, Bjarne Stroustrup, James Gosling

Herb SutterによるRitchieへのインタビュー。Ritchieは、ほとんどインタビューを受けない男であったので、貴重である。

2011-10-13

何故Dartが史上最高の言語なのか

史上最高にして、恐らく今世紀最高となるプログラミング言語は、Dartである。DartはC++以外の既存のプログラミング言語のほとんどを駆逐する事ができる潜在性能を持っている。これからの真のプログラマーは、C++とDartという二大言語に加え、目的に応じて、アセンブリやシェーダーなどの専用言語を学ぶことになるだろう。

Dartの美しさを理解出来ない近眼者が、愚にもつかぬ批判をしている。恐らく、彼らは規格書が読めないのであろう。曰く、「Javaのパクリ」、曰く、「目新しい新機能がない」。Javaのパクリという阿呆は、Javaのような聳え立つ糞の信者なのだろう。ただJavaと同じようなキーワードや文法を使っているからといって、それがJavaのパクリであるとは片腹痛い。Dartからみれば、Javaなど歯牙にもかけぬ愚物である。目新しい機能がないという批判もあたらぬ。およそ斬新な新機能というのは、人目を引くのは確かだが、一般に普及しがたいものである。

Dartは、すでにその価値を証明されている機能を、ごく自然に提供している言語である。いや、重要なのはむしろ、提供していないモノにこそある。Dartは、他の言語にあるような、不必要なクソを提供していない。例えば、パースが難しかったり、時間がかかるようなcontext sensitiveな文法はないし、複雑怪奇な暗黙の型変換も存在しない。この点において、改行が終端記号とみなされるJavascriptは、近い将来にDartの後塵を拝する事になるであろう。

Dartの主目的である、Javascriptの置き換えという目的には、ソースコードのコンパイルを高速に行えることがまず第一である。それには、パースが難しかったり、文脈に依存して意味が変わったりするような文法を、極力避けるべきである。Dartはこの点において、特に優れている。

例えば、Dartでは、二項マイナス演算子と、単項マイナス演算子をオーバーロードすることができる。二項マイナス演算子のオーバーロードには、おなじみの、-という記号を使えばいいのだが、単項マイナス演算子のオーバーロードには、negateというキーワードを使用する必要がある。

class C
{
    C operator - ( C other ) => this ; // binary minus
    C operator negate () => this ; // unary minus
}

main()
{
    C c = new C() ;

    c - c ; // binary minus
    -c ; // unary minus
}

これは恐らく、パースを高速にするためであろう。operator -と読み込んだならば、その時点で、それは二項マイナス演算子のオーバーロードであると決定できる。

例えば、Dartには正規表現ライブラリがあるが、正規表現リテラルは存在しない。これも、パースを高速に行うためであろう。そのかわりに、DartにはRaw String LiteralやMultiline string が存在する。

// Raw string literal
@"\n\r\f" ; 

// Multiline string
"""もんちゃらへっぴー
もけもけさー""" ;

まだ書きたいことは様々あるのだが、ともかくDartの規格書をすべて読んでしまわないことには、詳しい説明をすることができない。Dartを批判する前に、まず規格書を読んでみるべきである。今の実装はまだ不完全で、バグも多い。言語を実装によって判断するのは愚か者のすることである。とにかく重要なことは、Dartは今世紀最高のプログラミング言語であり、輝かしい未来が約束されているということだ。

デニス・リッチー逝去

Rob Pike - Google+ - I just heard that, after a long illness, Dennis Ritchie…

Steve Jobsより、こっちの方が大ニュースだ。しかし、リッチーは世界に多大な影響を与えたにも関わらず、あまり表にでない人物であった。もしリッチーがいなければ、今日のプログラミング言語は、かなり別の文法を使っていたかもしれない。

2011-10-12

Dartすごい。マジすごい。美しい

Dart : Structured web programming

というわけで、Dartが発表されてからこのかた、Dartの規格を読んでいたのだが、これはすごい。マジですごい。ヤバイほどすごい。美しすぎる。

私が多少なりともかじっている言語は、C++とJavascriptとアセンブリである。私は、もうこれ以上、学びたいと思う新言語が出てくるとは思っていなかった。たしかに、C#はWindowsでアプリを作るには面白そうだし、PythonやらRubyやらは、かなり人気だ。しかし、これらの言語を学びたいとは思わなかった。昔、Schmeに興味を持ち、SICPを買った。しかし、未だ綺麗なまま、本棚の中に眠っている。Haskellに興味を示したこともあったが、やはり最初の感動が覚めると、学ぶ気にはならなかった。つまりは、わざわざ学ぶほどの魅力がなかったのだ。しかしどうやら、私は間違っていたようだ。Dartが来た。

Dartは美しい言語である。規格書を読むと、その美しさが一目瞭然である。従来のどの言語にもない完璧なまでの美しさを備えている。

Dart Programming Language Speci cation

まず、規格書が短い。現在のドラフトは、たったの78ページしかない。この規格書は、コア言語だけを定義している。この短さには理由がある。Dartのコア言語は、美しいほどにシンプルだからである。

たとえば、Dartには、暗黙の型変換が、boolean conversion以外に存在しない。Javascriptのように、改行が文脈によっては終端記号と解されるような仕様もない。この美しい言語を設計したのは神ではなかろうか。よくぞここまで思い切ったものだ。

ときくと、そんな厳格な言語がWebのクライアント言語として使えるはずがないと思う人もいるかもしれない。実は、暗黙の型変換のチェックは、コンパイルエラーとはならない。静的型警告(static type warning)が発せられるだけで、コンパイルには影響を及ぼさない。たとえば、

void main
{
    int x = 0.1 ; // static type warning
    print("${x}") ;
}

これは、静的型警告を出すが、コンパイルや実行には、何の影響もない。もちろん、出力も、0.1である。これは、あたかもvar x = 0.1 ;と書いたかのように振る舞う。

記述は厳格に、実行は寛容にというのが、過去に成功したWeb上でのクライアント言語に共通する理由である。HTML然り、Javascript然り。Dartはこの点からみても、失敗する余地はない。

コア言語側には、組み込み型というものがない。intやdoubleといった基本的な型でさえも、ライブラリである。

そして重要なことに、DartはJavascriptの代替として、Chromeに組み込まれることが決定している。もちろん、DOMも使える。

とにかく、Dartは信じられないほどに美しい言語だ。早くこの言語でプログラミングがしたい。Dartが使えるようになれば、Javascriptなどは即座に絶滅してしまうだろう。

おいおい、オメーのブラウザ、Dartも使えねーのかよ。さっさとDartが使えるブラウザーにしろよ。

下駄の鼻緒が切れた

「下駄の鼻緒が切れると縁起が悪い」という迷信があるが、あれは迷信などではなく、事実である。

私はここ二年ほど、下駄を愛用している。何故いまどき下駄なのかと不振に思う人もいるだろう。これは、特に下駄を履くことによる不利益がないからである。

まず、下駄の値段は数千円であり、通常の安い靴と何ら変わりない。私の使用頻度では、下駄は一年ほど使えるので、この点においても、安物の靴と何ら変わりない。走るのではなく、長距離を行くのでもなければ、靴と比較した場合の不利益がほとんどないと言って差し支えない。

唯一の不利益といえば、下駄を履くと足が汚れるので、玄関先で足を洗ってから上がらなければならないことぐらいだ。歌舞伎や昔の時代劇などで、家に上がる前に、足を拭く動作がみられるのも、このためである。

ところで、今朝、下駄を履いて歩いていると、突然、下駄の鼻緒が切れた。見ると、下駄の歯があまりにも擦り切れていて、鼻緒をかけている縄が地面に接触するようになったため、次第に縄がすり切れていき、とうとう切れたらしい。以前の下駄は、そうなるまえに下駄の歯が完全にすり切れてしまったので、鼻緒が切れる前に買い換えたのだった。

当然、その場で思い当たったのは、「下駄の鼻緒が切れると縁起が悪い」という迷信である。今日、私は、この迷信が、実は事実であるということを身を持って思いしらされた。

下駄の鼻緒が切れたせいで、その下駄を履いて歩けなくなってしまったのだ。仕方なく、私は下駄を脱ぎ、裸足で歩いて帰らざるをえなかった。この不便は、下駄の鼻緒が切れたという事象によってもたらされたものである。下駄の鼻緒が切れたという直接的な理由で不便を被ったのだから、「下駄の鼻緒が切れると縁起が悪い」という迷信は、実は正しいと言える。

2011-10-07

欧陽修の未発見の書簡、発見さる

日本で宋・欧陽修の書簡…中国で「盗んだ」、「韓国でなくて幸い」 2011/10/06(木) 17:38:42 [サーチナ]

九州大大学院比較社会文化研究院の東英寿教授は3日、宋代の政治家で詩人・文筆家として知られる欧陽修の書簡96篇を発見したと発表した。中国でも同ニュースは報じられた。かつては「13世紀に鎌倉幕府が設立した金沢文庫が収蔵していたもの」と紹介されたが、「日本が中国から盗んだものだ」などのコメントが寄せられた。「発見されたのが韓国でなくて幸いだった」との書き込みもある。

天理大学付属天理図書館が所蔵していた1191-96年に編纂(へんさん)された欧陽修全集「欧陽文忠公集」に、これまで知られていなかった欧陽修の書簡96篇が掲載されていた。同「公集」は木版による原刻本。中国国家図書館や日本の宮内庁も所蔵しているが、天理図書館所蔵の原刻本は、編纂作業が終わってから、抜け落ちていた書簡を追加した版であるとみられる。

環球網などの記事は「(日本側が古い時代に)中国で購入し、13世紀に鎌倉幕府が設立した金沢文庫が収蔵していたもの」「日本では国宝に指定」などと紹介したが、コメント欄には「日本が戦争中に中国から盗んだものだ」、「中国の文化財だ」などの書き込みが相次いだ。

「幸いなことに、(発見場所は)韓国でなかった」などと主張する書き込みも多い。「『欧陽修は韓国人だった』とされてしまう可能性が100%」だからという。

どうせ中国にあっても度重なる革命や、記憶に新しい文化大革命で焚書されてるだろうに。それにしても、このニュースは自己言及的である。なにしろ、あの欧陽修である。あの日本刀歌をつくった欧陽修である。

徐福行時書未焚
逸書百篇今尚存
令厳不許伝中国
擧世無人識古文

2011-10-06

スティーブ・ジョブズ死亡

Apple - Remembering Steve Jobs

Apple社はヴィジョンとクリエイティビティあふれる天才を失い、世界は驚嘆すべき男を失った。幸運にも彼を知り、ともに仕事をした者は、最良の友であり師でもある人物を失った。スティーブは彼以外に成し遂げられぬ会社を後にして旅立った。彼の魂は、Apple社に生き続けるであろう、永遠に。

スティーブ・ジョブズ:自分の立ち上げた会社をクビになったが、後に買収しなおした、世界一カリスマのあった男。すい臓がんにより2011年に没す。享年五十六歳。

非staticデータメンバーの初期化子

今月にビルドされたgcc4.7で対応していることを確認。

struct S
{
    int member = 123 ;
    S() = default ;
    S( int value ) : member(value) { }
} ;


int main()
{
    S s1 ; // s.member == 123
    S s2(456) ; // s.member == 456
}

なお、非staticデータメンバーの宣言にauto specifierを使うことはできない。これは、auto specifierが、ブロック、名前空間スコープ、for文の初期化句にしか使われてはならないとされているためである。

struct S
{
    auto member = 0 ; // error
} ;

ちなみに言っておくと、staticデータメンバーにはauto specifierを使うことができる。これは、staticデータメンバーが、実は名前空間スコープであるからだ。staticデータメンバーは、クラス定義の中に書かなければならないとか、クラス名による修飾をしなければならないなどの制約はあるが、名前空間スコープに属する名前である。

struct S
{
    static auto const member = 0 ; // OK, type is determined to be "const int"
} ;

もちろん、staticデータメンバーに初期化子が許されているのは、constなリテラル型だけであるので、autoがそれ以外の型に推定された場合は、エラーとなる。

struct S
{
    static auto member = 0 ; // Error, the type of static member is not const literal type.
} ;

ちなみに、gccには七ヶ月前、上記のコードを通してしまうバグがあったが、バグレポートを送ったところ、現在では修正されている。

2011-10-03

花粉症?

ここしばらく、体はだるくないし熱もないが、謎のくしゃみと鼻水と目のかゆみに悩まされている。一日中というわけではなく、起きた直後がひどいように思われる。

さて、思いつく病気は花粉症だが、果たして。

2011-10-01

火の用心に効果はあるのか

毎年この時期になると、拍子木をやかましく打ち鳴らして「火の用心、火の用心」と叫ぶ集団が出現する。果たして、あれはなにか意味があるのだろうか。あれを聞いたことで、用心を心がける人間が、果たして存在するのだろうか。近所迷惑だとは思わないのか。

目の前に火鉢や囲炉裏がある時代は知らず、現代では、常に火を灯している場面は、少なくなっている。

たとえば、電子機器や配線からの発火は、少なくとも発火するまでは、火は存在しない。それに、発火するまで事前の兆候がなく、またコレといった対策も取りづらい問題である。

そもそも、現代の火災の原因の最上位は、「放火」である。

参考:総務省消防庁

放火は、いくら個人が用心しようとも防ぎようがない。ある人間が火をつけようと考えたならば、その手段を手に入れるのは、この日本ではたやすいことであるからだ。

次いで、「たばこ」が原因としてあげられる。これは、用心できる種類の原因である。

ということは、あの集団は「火の用心、火の用心」と叫ぶよりも、「禁煙、禁煙」と叫んだほうが効果的ではないだろうか。

それにしても日本は、廃品回収といい、古紙回収といい、騒音に対する規制が緩いように思われる。

ついさっきも、家の前を「火の用心」と叫びつつ通過する集団がいたので、このような疑問をぶつけてみた。彼らの言い分は、実に不思議である。

私「何故このようなことをしているのか、近所迷惑だとは思わないのか」
翁「町内会で決まっている。学校からも要請がある」
私「それで何の疑問も抱かずやっているのか」
翁「そうだ」
私「誰が決めたのか」
翁「町内会の代表である私が決めて、私がやっている」
私「自分で決めて自分でやっているのか」
翁「町内会で誰も反対しなかった」
私「そもそも、効果があるのか」
翁「ついこの間もこの近所で火事があって云々」
私「それで効果はあるのか」
翁「これを聞いて用心する人が少しでもいればそれでいい」
集団「この人頭おかしいんやわ、ほっといていこいこ」

集団は、なおも質問しようとする私を、「頭がおかしい」と言い捨て、過ぎ去っていった。この翁は、いつも家の前でタバコを吸っている翁である。ために、公道が煙たくてしょうがない。火災の原因No.2の喫煙者が火の用心を叫ぶのは不思議だ。

2011-09-30

今年のイグ・ノーベル賞の日本人受賞者は8人

まず、名誉ある受賞から、今井真(滋賀医科大学講師)、漆畑直樹、種村秀輝(シームス)、田島幸信(香りマーケティング協会理事長)、後藤秀晃、溝口浩一郎(エア・ウォーター防災)、村上純一(琵琶湖病院)の七名の者は、イグノーベル化学賞を受賞した。これは、眠っている人を起こすのに最適な空気中のわさび濃度を発見したためである。これは、火災などの警報器で、聴覚障害者を起こすのに使われる技術である。

不名誉な受賞は、麻原彰晃とその他大勢の終末予言者、世界は1997年に終わると予想し、数学的予想と計算には注意すべきだと、世界に知らしめたことをもって、イグ・ノーベル数学賞を受賞した。

2011-09-27

クッキーモンスター

「オ゛ー、ミ゛ー ラ゛フ゛ ク゛ッキ゛ー オ゛ー イ゛ェア゛」
~都道府県ドメインについて、クッキーモンスター

「ちょっと待てや」
~都道府県ドメインについて、高木 浩光

高木浩光@自宅の日記 - JPRSに対する都道府県型JPドメイン名新設に係る公開質問

以下は素人丸出しの説明である。

cookieは、今日のWebサイトにとって、非常に重要であると同時に、プライバシー、セキュリティ上、気を付けなければならない機能でもある。あるWebサイトによって設定されたcookieが、全く別のWebサイトによって読み込まれることがあってはならない。このため、cookieにはsame origin policyがある。異なるドメイン間では、基本的にcookieを共有できないのだ。example.comで設定されたcookieは、example.orgからは読み込むことはできない。

ところで、今私がexample.comというドメインを取得し、Webサイトを運営したいとする。この場合、第三レベル以降のドメインは、自由に名付けることができる。自作の音楽は、music.example.comで公開し、ブログはblog.example.comで公開するとしよう。この二つのドメインは、異なるものであるから、cookieは共有できない。しかし、このドメインは、どちらもexample.com下にあるものであり、私の所有するドメインであり、私の運営するWebサイトである。したがって、このふたつのドメイン間でcookieを共有できたとしても、セキュリティ上の問題にはならない。

そこで登場するのが、super cookieである。このcookieは名前の通りスーパーなクッキーなので一部ドメインを指定しないことができる。たとえば、.example.comを指定すれば、music.example.com、blog.example.comまた他のあらゆる、「任意.example.com」で共有することができる。

しかし、もしこのスーパーなcookieを、.comに対して指定すればどうなるだろうか。この場合、私の所有するexample.comだけではなく、トップレベルドメインがcomでさえあれば、どのドメインからでもスーパークッキーの読み書きができる。これはまずい。

もちろん、問題はcomだけではない。トップレベルドメインはもっとたくさんある。では、トップレベルドメインに対するスーパークッキーを禁止すれば、問題は解決するのだろうか。

例えば、example.co.jpは、co.jpまでがパブリックなサフィックスである。トップレベルドメインの禁止だけでは、この問題を解決できない。

問題の解決方法とは、パブリックなサフィックスのリストを作成し、スーパークッキーの指定が、そのリストに該当するときは、使用を禁止することである。これは、クソなサイトからユーザーを守るためにも、ブラウザー側で対処する必要がある。

今、都道府県のサブドメインを導入するということは、日本全国の47都道府県の分だけ、パブリックサフィックスが相当に増えることになる。もし市町村も導入ということになれば、1722市町村。もちろん、これはブラウザーをアップデートすることで対処しなければならない。誰がやるというのか。アップデートされないブラウザーはどうしようもない。

明らかに、極東の小国は非常に重要なので、時にはこんな乱暴も許されるのだろう。

2011-09-26

GCC 4.7で非staticデータメンバーに初期化子が使えるようになったらしいが

C++0x Support in GCC - GNU Project - Free Software Foundation (FSF)

なんと、Non-static data member initializersがGCC 4.7で実装されているという。早速試してみようと、昨日ビルドされたばかりのgccのバイナリを落とした。さっそく試してみたが、sorry, unimplementedと表示される。何故だろう。

struct X
{
    int member = 0 ;
} ;

2011-09-25

説経

今日は気分転換に、本物の日本語を読むことにした。私の言う本物の日本語とは、数百年前に書かれて、今なお読まれている文章のことである。まだ書いた当人の生きているような新しい文章は玉石混淆であり、しかもほぼすべて石である。数百年前以前に書かれて、今なお読まれている文章は、名文の可能性が高い。路傍の石の中から玉を拾うより、世間から何百年も玉だと言われ続けている石の中から玉を探すほうが簡単である。ちょうどブックオフで、新潮日本古典集成の説教集が投げ売られていたので、それを読むことにした。

今からたったの400年ほど前、日本には説経説き、または説経者と呼ばれる下層階級の芸人がいた。彼らは当時、三十三間堂の境内で、大きな傘をかざし、ササラと呼ばれる、竹で作った、こすりあわせて音を鳴らす原始的な楽器を擦り鳴らしながら、地蔵や仏像の由来を往来の人々に説き聞かせ、おひねりを得ていたのである。

三十三間堂の近くに住む者として、これがどうにも実感がわかない。今の三十三間堂は、決して無料見はさせじとばかりに周りを厳しく塀で取り囲み、たった一箇所の入り口から、拝観料を払って入る、まあなんとも近代的で罰当たりな商業施設である。地獄で銅の湯を飲ませられることは、まず間違いあるまい。それが、かつては人通りの激しい往来であり、しかもこのような所謂「ササラ乞食」の商売の場所であったとは。今の四条大橋のような雰囲気だったのだろうか。

さて、恐らく説経の中で一番有名な話は、「さんせう太夫」であろう。これは、森鴎外の「山椒大夫」という小説のためである。しかし、実際に説経のさんせう太夫を読んでみると、森鴎外の作品は、単なる劣化コピーに過ぎないことが分かる。もちろん、当時の説経説きと森鴎外とでは、力の入れどころが違うというのもあるが、原典はさすがに強烈である。安寿は凄惨な拷問によって焼き殺されるし、返り咲いたつし王丸がさんせう太夫に行う報いも、やはり残酷な処刑である。また、誓文の文句も興味深い。

2011-09-23

スライム冒険記が面白い

コンビニでは、懐かしのマンガを再録したペーパーブックが売られている。今日、ふと売り場を見ると、興味深い本が売られていた。スライム冒険記である。

スライム冒険記とは、かねこ統によって描かれ、当時のVジャンプで連載されていた、ドラクエの世界観を元にしたギャグマンガである。灼熱炎が吐けるボケキャラのスライムのスラきちと、ツッコミ役の山賊ウルフのウルフ、その他のドラクエにおなじみのモンスター達が、なんとなく勇者を目指す物語である。

作風は、随所に鳥山明へのオマージュが感じられる。

なんとなく、ドラクエ4コママンガ劇場を読み返したい気分になった。思えば、ドラクエ4コマからは、かなり良質なマンガが生まれた。衛藤ヒロユキしかり、柴田亜美しかり。思えば、エニックスは、ゲームだけではなく、出版事業でも、結構新しいことをしていたのだな。今は見る影もないが。

しかし、どうも今、ドラクエ4コママンガ劇場は売られていないようだ。中古を手に入れるしかないのだが、近所のブックオフには見当たらない。クレカさえあれば、アマゾンの中古市場から買えるのだが。

早いところ執筆を終わらせて、まじめに働かなければなるまい。

2011-09-21

日本語の限界を感じる

C++の参考書を書くのがつらい。どうも、日本語という言語の限界を感じる。

日本語で技術書を書くのは、苦痛極まりない。どんなにわかりやすく言葉を選ぼうと、結局やっていることは、英語の翻訳でしかない。それならば、最初から英語で書けばいいではないか。明治になってから、医学はドイツ語から翻訳されたオランダ語ではなく、元のドイツ語で学んだように、プログラミングも英語で学ぶべきなのだ。確かに、一般人は翻訳で学んだが、専門家たる医者は原語で学んだのだ。専門家であるプログラマーも原語で学ぶべきである。

実際のところ、今や、もはや参考書というもの自体が時代遅れなのではないかと思う。何故ならば、誰もが一次ソースたる規格書を読むことが出来るからだ。まあ、C++はISOの規格なので、規格書は無料ではない。とはいえ、たったの352スイスフランだ。クソの役にも立たぬ参考書を何冊も買うより、規格書を買ったほうがいい。

むしろ、今の時代に日本語のプログラミングの参考書を出しても、害悪でしかないのではないかと思い始めている。日本語の資料がなければ、まともにプログラミングを学びたいものは、自然と英語を学ぶようになるはずだ。かつて私は、プログラミングを学ぼうとしたが、まともな日本語の参考書がなかったので、まず英語から学ぶことにした。この2011年になっても、まともな日本語の参考書が存在せず、世間一般に良書とされている日本語の参考書は、すべて英語からの翻訳(それもかなりひどい翻訳)であるという事実からしても、私の取った戦略は正しかったといえる。

とすれば、日本語の参考書をこれ以上増やしても、害悪でしかない。

結局、今の私は、自分自身が全く必要としていない、それどころかむしろ、害悪であるとまで考えるような参考書を書いているわけだ。道理でつらいわけだ。

追記:確かに、352スイスフランは、個人で買うにはちょっと高い。恐らく来年頃には、ANSIから数十ドル程度の値段で、規格書が買えるようになるはずだ。