/home/pochi/ChangeLog / 2006-09-15

■ LL 飲み会で Haskell の洗脳をされる [飲み会]

山下さんに Haskell の洗脳をされる。
数年前に机を並べてたときには、全然 Haskell を
使う気にならなかったんだけどなあ。
ちょっとしたワンライナーは Ruby とか Perl を使ってたけど、
Haskell を使ってみるかなあ、という気がしてきたよ。

以下、洗脳の要点。

1. 開発環境

弱いと思ってたけど、そんなことはない。
Eclipse のプラグインなんてものもあるらしい。
スウエーデンの大学(Chalmers大学？)では、
Haskell に強力に取り組んでて支援ツールを
いっぱい出している。


2. 実行環境

いちいちコンパイルして実行しなきゃいけないんじゃ、
かったるいよな〜、それに速度も遅いんじゃない、
と思ったらそれも誤解。
インタプリタがあるので、Lisp や Python のように
使うことができる。
遅いっていうのも、最近文字列処理とかで、
高速なライブラリができたので、むしろ速いかも、と。


3. 実用性

使う場面がそもそもない、と思ってたけど、
ネットワークオペレーションや LL 言語で良く使う、
フィルター的なプログラムを書くには実は向いてるかも。
パターンマッチには、正規表現を使うのが一般的だけど、
BNF記法でマッチしたほうが楽なケースもある。
Hakell は BNF記法をそのまま書くだけで、
フィルターが書けちゃう。
正規表現は括弧のネストに弱いけど、BNF記法は、
そういう弱点はないし。
ログの解析、通信モジュールなんかを書くには、
実は向いてるような気がしてきた。
ネットワークで使うストリーミング文字列なんてのは、
単なる無限リストなわけで、それをリストを扱うように
頭から処理できる、というのは他の言語より強力かも。
他の言語だと、読みこんでパースして、とか
やんなきゃいけないわけで。


4. プログラミングのしやすさ

一般的な言語でプログラムを書くときには、
ループや変数の概念を駆使するのが基本。
でも普通の人がその概念を理解するのは意外と難しい。

でも世の中の問題は、再帰や継続のような考え方をするほうが、
実は楽なことが多い。
一般的なプログラマは、再帰が必要な問題は、
頭の中でループに変形させてからプログラムを書くけど、
Haskell だと問題をそのままプログラムに書けて楽。
Haskell は楽すぎて他の言語が使えなくなっちゃう。

※そう言ってる人は、本当に他の言語が使えないので、
  非常に説得力があった ;-p


5. 保守性

Haskell を使える人の絶対数が少ないので、
保守に困るんじゃないかと思ってたけど、
最近は若手に流行っているらしい。
たしかに Haskell の人ってみんな若い。
前途は明るい気がたしかにするなあ。

※ Kahua はおっさんばっかり。なんとかしようね。


とりあえず、アサマシ、と。

ふつうの Haskell プログラミング ふつうのプログラマのための関数型言語入門
入門Haskell - はじめて学ぶ関数型言語

ついでに過去の日記の Haskell 関連のネタリスト。

○Haskell勉強用
Haskell の勧め --> [2004-04-08-3]

なぜ関数プログラミングは重要か --> [2005-10-30-5]
山下さんの翻訳。

Haskellを使った関数型プログラミング --> [2006-09-03-4]
IBM Developerworks の記事

結城浩の Haskell 日記 --> [2006-05-31-1]
結城浩さんによる Haskell 勉強日記


○Haskellのネタ

Haskell 診断 --> [2005-12-07-4]
Haskell に向いている人はこういう人だ、というネタ。

関数型言語による脳への悪影響 --> [2005-03-03-5]
Lisp とか Haskell を使うとバカになるよ、という話。
ゲーム脳流行ってたからね。

他の言語処理系を書く、というネタ。
Perl6 のコンパイラ Pugs は Haskell で書かれている --> [2005-03-09-1]
Haskell で書かれた Ruby インタプリタ、RType --> [2005-09-16-7]

プログラミングコンテストで Haskell が優勝 --> [2005-09-28-7]
Haskell がいつも強いんだよね。

Haskellのクイックソートは格好良いけど遅い --> [2006-06-17-4]
データ構造を考えてアルゴリズムを考えよう、という話。

○その他、Haskell に似た言語

超特急 1時間でわかる ML 超入門 --> [2005-10-30-3]
並列関数型言語 Erlang のネタ --> [2006-03-27-2]

■ LL RING 反省会 [LL2006]

九段下にて。
アンケート結果を参考に。

デブ用(XL)のTシャツがすごく余った。
アンケートでサイズを聞いてるんだけどなあ。

結論: デブはアンケートに答える

やっぱりコンピュータ業界からデブが減ってる気がするんだよなあ。
六本木界隈の住人が増えてきて、お洒落でリアルな女の子と
同じ空気を吸う人が多くなったせいかのう。

■ Gmail の誤スパム判定を回避する [Google]

http://at-aka.blogspot.com/2006/09/gmail.html

間違って SPAM と判定されちゃうような場合には、
差出人を Contacts List つまりホワイトリストに登録しとけばOK。

■ ジャンプ打ち切り大全 [漫画]

http://jump.heavy.jp/jb.htm

週間少年ジャンプでは、読者アンケートで人気が低いと、
連載打ち切りになっちゃうんだよね。
そういう連載1年以内で終わっちゃった漫画の一覧。

ふと wikipedia を読んでみたら面白すぎ。

Wikipedia - 週間少年ジャンプ

他の雑誌や新聞の解説も軒並面白いな。
朝日新聞とか、やっぱり保護の対象になってるし ;-p

■ もうグーグルでなくてもいいんじゃないか [Google]

http://japan.cnet.com/column/somethingnew/story/0,2000067121,20234707,00.htm?ref=rss

Google だけ、っていう人は少数派な気がする。
でも Google を全然使ってない人も少数派よね。

■ なぜシステム担当者はいつも不機嫌なのか？ [ネタ][仕事]

http://metalsty.seesaa.net/article/23689358.html

システム担当者です。

まあ考え方だよね。

・社内SEは「クレーム担当」である。
...
・いきおい、社内SEというのは「常にネガティブな話ばかり訊く担当」に
  なってしまう。

偽善者のふりができてお得、だと思えば苦にならないよ。
話を聞いてあげる、というのは対女の子でも必要なスキルだから、
そのための修行だ、と思う手もあるな。
クレームは楽しまないとね。
「いつも大変だね、おやつをあげよう」と言われるようになったら勝ち。

・彼らはめったに進化しない。
  いつまで経っても、レベルの低いクレームしか言ってこない。

楽に対応できるから、ちゃんとチケット管理をしてると
楽にたくさん仕事をした気分になれてお得。
ちなみに程度の低いクレームはいろいろな意味でとても大事。
程度の低いクレームが聞こえなくなったら、
信頼を失なってる証拠なのでかなりまずい。

・おじさんたちは口を揃えて「近頃の若い者は、
  パソコンばかりやって仕事をしない」と言う。

こういうおじさんはそもそも仕事のやり方を把握してないので、
仕事のやり方を教えてください、と言って、
教えを請うふりをしながら、本人に仕事の棚卸しをさせると吉。
よっぽど頭が悪くなければ自分で気付く。
おいしいご飯が食べられるかもしれないぞ。

・そして多くの企業では経営者もまた、その「彼ら」の一人である。

経営者はリソース配分が仕事なので、仲良くしないとね♪
リソースが確保できないと運用できないのさー。
仕事をこなすのに必要なことはちゃんとやらないと。

・社内システムやネットワークが動くのは
  「当たり前」であって、それが止まれば
  「システム担当の責任」である。

責任範囲のことで問題があったら、そりゃ責任はあるよね。
責任範囲を明確にしとく、っていうのは仕事をする上では、
あたりまえのことだったりもする。
プロジェクトで、目的、使えるリソース、期間、を定義するように、
運用においては SLA っぽいものを作って説明しとかなきゃ。

それと障害はある意味チャンス。
お金をかけてないから、なかなか復旧しないんですよねえ、
と経営陣にアピールできるしね。

システム担当の仕事をするのであれば

- 障害を楽しむゆとり
- 無駄話を許容する心

が必要かな、と思うね。

もちろん

- 尊敬される程度の技術力
- 仕事に対する責任感
- 複数の改善策を見つけらる広い視野と柔軟な思考

は持ってるという前提ね。