最初は初心者? いえいえ,最初は村人ですよ

惨劇を暴くのは誰?

恐怖の条件付け

(略)

2つ目は、「あるアメリカの夫婦のできごと」のお話です。

結婚も間もない若い夫婦が、新しいオーブンでローストビーフを作ろうとしていました。妻は肉の両端を5センチほど切り落としました。夫は料理に詳しいという人ではありませんでしたが、これを見ていて「どうして両端を切り落とすのか」と妻にたずねました。妻は「母が、いつもこうしてローストビーフを作っていたからよ」と答えました。知的で鋭い夫はその説明をうのみにしようとはせず、義理の母に電話をかけて同じ質問をしました。すると妻の母は「それは家のオーブンが小さくて、そうしないと肉がオーブンに入らなかったからですよ」と答えました。大きなオーブンがあるのに、自動的に肉の両端を切り落とすのは無意味な事だったのです。

(略)

C# 言語設計におけるミス

  • 言語設計で後悔していること
    • anonymous method で yield が使えないこと
    • void の扱い
    • Equals の扱い
    • null の扱い
      • Ruby の nil はすばらしい
    • Tuple を入れるとしてもパターンマッチの文法をどうするかの良い解決法が見つからない

なぜ Word 2007 の「貼り付け」ボタンはあれほど大きいのか


The Story of the Ribbon - Jensen Harris: An Office User Interface Blog - Site Home - MSDN Blogs』のムービーに答えがある.

操作方法を観察した結果,人々がどのように「貼り付け」を行っているかが明らかになった.3255378 回のサンプルのうち,約半数の「貼り付け」はキーボードショートカットによって行われる一方で,残りの半分はマウスによって行われていた.

The Old New Things

1.1 シャットダウンを実行するのに[スタート]ボタンをクリックするのはなぜか

(略)

ユーザビリティテストで大きな難関として常に立ちはだかったのは、ユーザーがコンピュータの電源を入れ、コンピュータの前に座ったまま、次に何をすればよいのか確信が持てないことだった。

そこで、システムメニューの名前を「スタート」に変えることを誰かが思い付いた。そうすれば、「ここをクリックすればよい」ことがわかる。この簡単な変更によって、ユーザビリティテストの結果は劇的に改善された。何かを実行したいときに何をクリックすればよいかが一瞬にしてわかったからである。

ではなぜ[スタート]メニューに「シャットダウン」があるのだろうか。

ユーザーにコンピュータをシャットダウンするように言うと、彼らは[スタート]ボタンをクリックした。結局のところ、シャットダウンするにも、それをどこかで始める必要があるからだ。

1.2 Windowsに「エキスパートモード」がないのはなぜか

次のようなことを求める声がよくある。

[パフォーマンス]タブなどに、[初級]から[上級]までの範囲のスライダバーが必要ではないか。最上級レベルでは、すべての高度な設定がオンになり、初級レベルでは、初心者向けのすべての設定がオンになる。中間レベルでは、設定を徐々に有効にできる。

Windows 95よりも前からこのようなことを実現しようとしているが、うまくいかない。

それがうまくいかないのは、ページファイルとコーンフレークの箱の区別もつかないユーザーが、Excelをちょっとかじっただけで、自分は上級ユーザーだと位置付けるからだ。彼らはばかではないし、実際に上級ユーザーである。私たちが求めているようなスキルを彼らが持っていないだけだ。

それから、初心者を笑いものにする前に、1つ付け加えておくと、いわゆる上級ユーザーといえども、すべてを知っているわけではない。筆者はGUIプログラミングについてはかなり詳しいほうだが、ディスクのパーティション分割のことはあまり知らないし、Active Desktopについてはまったくの無知である。筆者はエキスパートだろうか。ハードドライブをフォーマットする必要がある場合、意味不明なオプションだらけのダイアログボックスなんて見たくない。ただハードドライブをフォーマットしたいだけである。

現実には、ある分野でエキスパートであっても、おそらくほかの分野ではエキスパートではない。それはひとくくりにできるようなことではない。

2.10 正確さを気にしなければコラムを書くのがずっと簡単になる

風説コラムを書くことのすばらしさは、それが正しくなくてもよいことだ。たとえ間違っていたとしても「リリース前にMicrosoftが変更したから」と言えば済むし、誰も間違いだとは言えない。被害者なき犯罪である。唯一の被害者はMicrosoftだ。

(略)

4.3 タスクバーの時計が秒を表示しないのはなぜか

初期のベータバージョンでは、タスクバーの時計は秒を表示し、一部の時計のようにコロンを点滅させていた。だが、それを削除しなければならなかった。

なぜ?

コロンを点滅させながら時間を更新し続けると、ベンチマークがひどい数字をたたき出すからだ。

(略)

18.2 [スタート]メニューのピンリストにプログラムからアクセスできないのはなぜか

苦労して失敗から学んだためだ。

(略)

18.6 CDを焼き終わった後にエクスプローラがCDを取り出すのはなぜか

便利だからでもあるが、誤動作するハードウェアに対処するためでもある。

(略)

19.1 インポートを解決できない場合にWin32がモジュールの読み込みに失敗するのはなぜか

逆の方法を試してみたら、はるかにひどい結果になったから。

(略)

19.2 構造体のサイズが厳しくチェックされるのはなぜか

(略)

「だが、以前のバージョンのオペレーティングシステムは、自らが期待する以上のサイズを受け入れるべきだ。期待する以上に大きな値は、新しいバージョンのプログラムの構造体であることを意味し、理解しない部分は単に無視すべきである。」

実際にそれを試してみたが、うまくいかなかった。

(略)

19.14 デスクトップを無効にできるのはなぜか

単にWindowsオペレーティングシステムの設計理念の歴史によるものだ。

(略)

コンピュータプログラミングの概念・技法・モデル

コンピュータプログラミングの概念・技法・モデル(IT Architect' Archiveクラシックモダン・コンピューティング6) (IT Architects’Archive CLASSIC MODER)(長いので今後の日記ではガウディ本と記す)を読み始めましたが、面白いですね。

「この本の目的」から引用

科学的基盤を導入しようと色々努力しても、プログラミングはまず間違いなく、小手先仕事として教えられることになる。普通、1つ(か、ほんの少し)のプログラミング言語(例えば、Javaとそれを補うHaskell、Scheme、またはProlog)の枠の中で教えられる。選ばれた言語に含まれる歴史的偶然が基礎概念とあまりにも密接にないまぜになっていて分離することが出来ない。ツールと概念がごちゃごちゃになっている。それに輪をかけて、オブジェクト指向、論理型、関数型等の「パラダイム(paradigm)」と呼ばれる、プログラミングの異なる見方に基づく、考え方の異なる流派がはびこっている。流派それぞれが独自の科学を持つ。1つの学問としてのプログラミングの統一性は失われた。このようなプログラミングの教え方は、いろいろな架橋の流派があるのに似ている。ある流派は木の橋の掛け方を教え、別の流派は鉄の橋の掛け方を教え、というように、どちらの流派で学んだ者も木や鉄の制約を橋そのものの制約と思いこみ、木と鉄を一緒に使うことは思いも寄らないであろう。その結果として、プログラミングの設計が貧弱であるという憂き目を見る。

(略)

Javaの並列性は使い方が複雑で、計算資源を浪費する。こうした難点から、Javaを教わったプログラマは並列性そのものが複雑で資源浪費的な概念であると思い込む。プログラム仕様は難点を避けて、しばしばゆがんだ形で設計される。しかし、これは並列性そのものの難点では決してない。

(略)

プログラマは並列性を正しく教えてもらえば並列性を制約とは考えずにシステムの仕様を定め、プログラムするであろう。

思いて学ばざれば則ち殆うし

あるところに同じようなことを(ほとんど成り行きで)書いたのですが、重要な問題のような気がしてきたので、こっちにも書いてみる。

一般に、関数型言語やプログラミング言語(および計算機科学、ないし任意の専門)についての情報は、

  1. 一般書・一般誌、Webやメーリングリストやブログ
  2. 教科書・専門書
  3. 論文
  4. 口頭での議論(学会発表や質疑応答、グループのミーティング、部屋での会話)

などで交換されます。

で、一般に情報の「ディープさ」は上から下へ行くほど濃くなると思うのです(少なくとも僕の専門分野ではそう)。そのごく一部である1.だけ(しかも日本語onlyで)「勉強」していろいろと議論するのは、(何もしないよりは良いのかもしれませんが)非常に危険です。その危険をちゃんと意識していればno problemですが。「高速道路」の話と同じことかも。

(略)

Welcome to Hatena-mura

こうして見ると,はてな村という表現が実に相応しく見えてくる.村人間での意見交換と情報拡散,意見醸成は,惨劇の起きる村に必須な舞台装置.情報が伝わるからこそ惨劇が起きる!

村人 A でも何かを成し遂げる方法

  • 自分が村人であることを自覚する
    • これからのネット社会,みんな最初は村人.
    • ん? 実は村人じゃなくて当事者? だったら死亡フラグに注意して下さい.お願いだから重要な事実はさっさと記録に残して下さい.それだけが某社の願いです(多分).
  • 村のしきたりの由来を知っている人はだれ?
    • 当事者は答えを知っている.ただし当事者の数はとても少ない.
    • 必然ならば考えていけばいつか分かる.でも偶然は聞かなければまずわからない.
  • 村人を観察する
    • そして観察することを観察する.
    • この村は嘘つき村ではない.しかし,村人が絶対に正解できないたぐいの質問というのがある.彼らは与えられた情報の中で理性的に判断するため,結果的にみな同じ方向に間違う.自分も村人なので,このルールからは逃れられない.
    • 村人みんなが思う「いい考え」を実現した人がちっとも現れない? それなら恐らく昔誰かがそれを実現しようとして命を落としている.どこかに罠がある.
    • 「聞けば分かる」は半分正解で半分不正解.当事者に聞いて分かるのは真実.ランダムな村人に聞いて分かるのは村人の世界観.
    • 電波バリ3受信型殺人に気をつける.
  • 思い切って当事者になる
    • 思い切って幕間の会話に加わってみる.Sound Only.
    • その世界での1日は,村での1年に相当するかも.
    • ただし死亡フラグには注意.重要なセリフをしゃべり終えるまで死んじゃダメ,絶対.

宿題

  • id:amachang のようなメンタリティを持った人工知能が開発されると人類はどうなるか?
    1. 繁栄しました.
    2. 衰退しました.
    3. この余白はそれを書くには狭すぎる
  • プログラマ人口に対する最適な id:amachang の人数を求めよ.「id:amachang 数問題」*1

でてきた本

Windowsプログラミングの極意 歴史から学ぶ実践的Windowsプログラミング! コンピュータプログラミングの概念・技法・モデル(IT Architect' Archiveクラシックモダン・コンピューティング6) (IT Architects’Archive CLASSIC MODER)

*1:ネタにしてすみません.激しく尊敬してます.