ruby-dev メーリングリストで行なわれている、nil.to_sを""にするべきか、"nil"にするべきかの議論について。

nil(やnull)をどこでも使える言語は大変だな、と思った。
堅苦しいことを言うと""が本当に必要なら""を使えばいい。
そこをnilで代用した上にnil.to_sの結果に依存したプログラムを書いてしまうから変なことになる。
#そんな堅苦しいRubyはいやだけど。

他にもnilやnullを濫用してしまうとぬるぽが起きるし、nilやnullにエラーやその他特別な意味を与えると拡張できないしで、nilやnullというのはあるのが当たり前な普遍的なものという訳ではない。

Haskellにはnilやnullは無くて、そのようなものを使いたい場合は明示的に特別な型でラップしてやらなければならない。
つまり、String型はnilにならない文字列を表して、Maybe Stringはnilになりうる文字列を表す。
こうすることによって、nilの濫用が避けられる。逆に、他の言語だとnilやnullを使って簡単に表せることがちょっとだけめんどうになることもある。

他の言語を見ても、nullになりうる型とnullにならない型を区別する言語もある。
Niceとか、最近のだとSpec#もそうらしい。
#他にもたくさんあった気がするけど思い出せない……。

livedoor clip始めました。始めたのは大分前だけど。
livedoor clipのマイクリップ

コメントやタグ名の長さ制限がちょっと短かすぎる気もする。

あとタグにエイリアス付けられるようにしたい。タグでブックマークを検索するときに完全一致でしか検索できないので、自分はともかく他の人に検索されやすくするためにはカタカナ表記とアルファベット表記と日本語訳表記のタグを付けるとかしなくちゃいけないからめんどう。
エイリアスというよりはタグにタグを付けられるようにすればいいのか。

そういうことを考えていくと、やっぱりRDFのようなトリプレットによる表現とかもっと一般のn項述語を使いたくなる。そうすると扱いづらくなっちゃうというのはわかるけど。

タグって結局単項述語だから表現力は弱い。
だからタグシステムはいまいち手放しで受け入れられない。表現力と使いやすさのバランスを取っているとも言えるんだけどね。

なぜ拡張はバンドルされないのか(註: リンク先はMozilla Foundationなどの公式見解ではない)

Firefoxなどに拡張がバンドルされないのは、責任持ってサポートできないから、という話。

これを読んで、第三者が作った非公式な野良コンテンツに依存しているという点で、Web 2.0的だと思った。
#ただし、特別なことのように見えるのはMozilla Corporationの商品として見るからであって、もともとフリーソフトはそんなものだといえばそうかも。

それで、こういうところにできる隙間をSOURCENEXTみたいなところが上手く埋めるんだろうな。

メイリオのサンプル

メイリオは、低い解像度で小さい文字のときは、美しさよりも明瞭さを優先しているっぽい。
例えば1行目「目」とか「美」とかの字を見てみると、横線がピクセルグリット上に来るようにヒントが付けてあって線がはっきりしているが、その代りに横線の間隔が一定じゃなくなってしまっている。

その一方で縦線にはヒントが付いてないらしくて、例えばデザインの「ザ」の文字は「ン」に比べて太くなっているように見える。これはClear Typeの設定のせいかもしれない。あと、サンプル画像はClear Typeの設定のせいかうちのディスプレイが悪いのか、例えば「ノミ」という字などで少しエイリアシングが見える。

サンプルテキストを打ち直したもの。その1
サンプルテキストを打ち直したもの。その2

メイリオサンプルテキストのみかちゃん-Pでのスクリーンショットその1。LinuxでGnomeでFirefoxでSubpixel Smoothing有効。
メイリオサンプルテキストのみかちゃん-Pでのスクリーンショットその2。LinuxでGnomeでFirefoxでSubpixel Smoothing有効。

メイリオサンプルテキストのMS Pゴシックでのスクリーンショットその1。Windows XPでIllustrator CS2でアンチエイリアシングのみ有効。
メイリオサンプルテキストのMS Pゴシックでのスクリーンショットその2。Windows XPでIllustrator CS2でアンチエイリアシングのみ有効。

メイリオサンプルテキストの小塚ゴシックRでのスクリーンショットその1。Windows XPでIllustrator CS2でアンチエイリアシングのみ有効。
メイリオサンプルテキストの小塚ゴシックRでのスクリーンショットその2。Windows XPでIllustrator CS2でアンチエイリアシングのみ有効。

誰かMac持ってる人、ヒラギノで取ったスクリーンショット希望。
他にもいろんなフォント持ってる人もスクリーンショット希望。

次世代Windowsシェル「Windows PowerShell」を試す（前編）
Windows PowerShell(コードネームMonad)いいな。これだけのためにWindowsに乗り換えそうになるだけの魅力がある。

スクリプト言語がしょぼいというかsh + Perlなのはまあ目をつぶろう。

現在私がLinuxを使っている理由は、なんだかんだいって最終的にはInput subsystemが簡単にいじれておもしろいしこれ無しでは生きられない身体になってしまったという点。あとパッケージマネージャー。
#Input Subsystemとは、USBやPS/2などの低水準なドライバと、ユーザーの使うプログラムの橋渡しをするLinuxカーネルの一部。
#ユーザーモードドライバが簡単に書ける構造なので、キーボードの無変換を押しながらトラックボールを動かすとスクロールイベントが発生するようにする、とかいうのが簡単に書ける。
#詳しくは、Input subsystemに関する書きかけのドキュメントを参照。

Vistaではユーザーモードドライバが簡単に書けるとかいう噂も聞くのでもしそれが使いやすいものならばWindowsに移行するかも。

そうじゃなかったら、RubyとかHaskellとかでWindows PowerShellみたいなの作ったらいいのかな。

前に言っていたグラフィカルなコマンドラインインターフェースだけど、実装してる人がいた。
CUI (Composite User Interface)
XMLをパイプしたり、SVGを表示したりとかはしてないけど、アイデアは似た感じっぽい。

ただ、私の考えてたのは出力をグラフィカルにする方向がメインで操作はキーボード主体だったけど(一応簡単な操作ぐらいは考えてたけど)、こちらのは表示されたのを積極的に操作できるようにするみたい。操作すると対応するコマンドが入力される。

こういうのをちゃんと実装できるのってすごい。

slashcodeが変更されている。
more (トピック名) stories
だったのが
他の (トピック名) トピックの記事
に変更されている。
とりあえずお疲れさまです。

#しかしもっと抜本的な改善はまだか。WebAPIとか。

Haskellでの繰り返しを書くときのパターンに関するメモ。

高階関数:

map f xs

リストを作ってそれにmapやfilterなどの高階関数を使うパターン。たいていはこれを使う。

再帰関数:

foo [] = []
foo (x:xs) = bar (buz x) (foo xs)

再帰関数を手で書くパターン。これでしか書けなかったりこれで書いた方が書きやすい場合がある。

継続:

hoge x cont1 cont2 = if hage x then cont1 (funi x) else cont2 (puni x)

継続を明示的に渡す方法。非常に強力だがわかりづらくなりやすい。継続Monadや、より特化したMonadを使った方がいい場合もある。

モナド:

runFooMonad do ...

モナドを使った記法。モナドの種類に応じてさまざまな処理を書ける。whileループも書こうと思えば次のように書ける:

while :: (Monad m) => m Bool -> m () -> m ()
while cond body = do
                  c <- cond
                  if c
                  then body >> while cond body
                  else return ()
foo = while (liftM (5 >) get)
       (
         put =<< liftM (1 +) get
       )

Haskellで式を書くときのパターンに関するメモ。

結論: いろんな書き方ができるって素晴しい。

結論先行型:

foo x y = if c then t else e
  where
  c = ...
  t = ...
  e = ...

文章を書くときに先に結論を書いて、詳細を後で書くのに似ている。パラメータx, yをc, t, eから参照できる。外の名前空間を汚さない。いくらでもネストできるけど、めんどいのであまりネストさせない。

古典的関数型:

f x = g3 "abc" $ g2 x $ g1 "def"

関数型での古典的な書き方。最終的な返り値の型がわかりやすい。結論先行型ともある意味似ているし、後述するパイプライン型ともある意味似ている。

ボトムアップ型:

bar x y = let x' = preprocess x
              y' = preprocess y
          in buz x' y'

値に対して先に前処理をしておくときなどに使う。命令言語でのスタイルに近く、処理の流れが見えやすい。MonadやArrowのdo記法に近い。

パイプライン型:

pipe :: a -> (a -> b) -> b
pipe = flip ($)
-- pipe x f = f x

mpipe :: (Monad m) => m a -> (a -> b) -> m b
mpipe = flip liftM

mmpipe :: (Monad m) => m a -> m (a -> b) -> m b
mmpipe = flip ap

hoge x = p1 x
         `pipe` p2
         `pipe` p3

UNIXのパイプのような方式。do記法を使わないMonadやArrowに近い。多くのオブジェクト指向言語の記法とも近い。

それぞれの場面で使いやすいものを使うのが良い。

BumpTopという、アイコンを物理シミュレートされた空間に浮かせるというデモを見付けた。via みんな仲良しのつもり
まとめたりできる。小さくするとくしゃくしゃになるのがアレゲ。
これを使ってるとフォースが使えるような錯覚に陥いりそう。