娘が「おばあちゃんに会いたい」と言うので昼食を両親と一緒に。 敬老の日なので、なのかな。
もっとも、母親にうっかり「おばあちゃん」なんて声をかけようものなら、
あんたのおばあちゃんじゃない
と怒られてしまうのだけど。まあ、今時の60代はあんまり年寄りに見えないよね。
私がまだほんの小さかった頃に祖母と写った写真があるのだが、 この写真の中の祖母はほんとうに「おばあちゃん」って感じだった。 が、今計算すると当時の祖母は今の母よりも若いことになる。 うーむ、白黒写真や和服のせいではないと思うのだが。
で、昼食はバイキング。焼肉、寿司、スパゲティ、ラーメン、うどん、etc. 今日は体重のことはあまり考えないでおこう。
昼食後は子供を連れて公園に。ひとしきり遊んだら、すっかり疲れてしまった。
原稿..(以下略、笑)
よそで議論するのもなんなので、こちらにもって来よう。
まず、shelarcyさんの意見:
またマクロを間違いなく使えるようになるのと、オブジェクト指向を身につけるとどちらが難しいでしょうか？ もしマクロを使いこなす難しさがほぼ同等あるいはオブジェクト指向より容易であるなら、今のところはマクロを普通の人が使う言語に組み込んでも構わないのではないでしょうか？
私に限って言えば、オブジェクト指向を身につけるのが難しいと思ったことはないが、 マクロを間違いなく使うのはいまだにできないので、 答えは明らかだろう。(笑)
もっとも、これはフェアな比較ではないと思う。 パラダイムと言語の一機能を同格にするべきではないからだ。
繰り返しになるが、私はLispのマクロをどうこうしようというわけではなく、 新しい言語を設計するとして、その言語にマクロを追加することについて ユーザビリティの観点からのトレードオフを明らかにしたいだけだ。
Lispマクロの利点については理解しているつもりだ。
しかし一方で、
という点がある。
だとすると、プログラムを書くフォーマットとして「S式＋マクロ」と「より普通の構文」の いずれかを選べと言われたら、私はマクロをあきらめて普通の構文を選ぶ。
と、ここでshelarcyさんはこう来る。
あと、もう少しツールの存在に目を向けても良いのではないでしょうか？ 例えば、初心者には絶対にマクロを使わせたくないというのであれば、設定をいじらなければマクロを使えないようにしたり、ライブラリをインストールする形でしか使えないようにするといったような障壁を置いたり、ある種のマクロをフィルタする仕組みを持っている処理系(きちんとした形でマクロを使えるようになるまでテスト以外でマクロが有効にならない……っていうのは流石に実現が難しいでしょうけど)、S式についても XML のエディタのようにソースはS式だけど表現上は別の記法でそのまま編集できるのモードとS式で表示・編集できるソースモードを切り替えて使うことのできるエディタなどを想定して、そういうものがあれば受け入れられるかどうかという議論がなされないと実質的なユーザビリティから乖離してしまう恐れがあります。もっとも、本当はテストした方がいいのですが。
おっしゃることはもっともだ。 私は言語屋なので言語そのものに強くこだわってしまう傾向があるのを見透かされている。 IDEとか嫌いだし。
ただ、過去の言語の歴史の中で「ソースはS式だけど表現上は別の記法で」というアプローチは それこそ星の数ほど行われてきたのだが、生き残ったものはほとんどないという事実は、 私に「言語はその記法が重要である」という原則を教えてくれているように思う。
マクロという問題に限定すると、やっぱりS式を隠してはマクロのパワーを損ねると思うので、 ここであげられたようなツールではマクロとユーザビリティの両立は難しいのではないだろうか。
で、マクロが役に立つケースのかなりの割合は、高階関数で実現できる。 Rubyでは限定された高階関数が呼びやすい文法(ブロック)を導入することで、 ある程度支援しているつもりだ。
だから、
Ruby はイテレータなどで工夫しているなと思うのですが、繰り返し以外の用途でイテレータを使っている例などを見ると、マクロっぽい使い方をしているように思えるのですが、...
というotaさんのツッコミは鋭い。
それからshiroさんは、
このプログラム片の外側で、near, far, lerpといったマクロやグローバルな束縛が定義されたとしても、このプログラムの意味は変わりません。
(中略)
しかし、予約語の場合、例えばnear, farという識別子が予約語に追加されたとたん、上のようなプログラムは破綻します
と予約語の増加とマクロを比較しての優位性を述べておられる。
このマクロの良い性質についてあまり意識していなかったので、教えていただいたのはありがたいのだが、 予約語が安易に増えるような言語はそもそもユーザビリティの観点からは最低だと思うので、 比較の対象にはならないのではないかと。
ただ、その前に述べておられる
プログラムの読みやすさ、書きやすさを決めるひとつの重要な属性は、あるプログラム片を目にしたときに、その意味に影響を与える範囲が限定され得るということ、したがってその範囲さえ見ていれば、プログラム全てに目を通さなくてもそのプログラム片の持つ意味が完全に理解できること、だと思います。
という意見には完全に同意する。今後もこの原則は心にとめて行きたい。
〆切について愚痴ばかり書いていたので、心配されていた方も、もしかしたらいらっしゃるかもしれませんが、 一応ちゃんと終わりそうです。
まだ、あとふたつほど残ってますが、これもなんとかなるでしょう(希望的観測)。
交渉の末、〆切は16日にしてもらったのだが、 進まない。今日の夕方の時点で半分くらいか。
しかもページ配分を間違えて、 HTTPとセッションの話だけで2/3くらい書いてしまった。 残りのページではWebアプリケーションフレームワークはまともな話ができそうにない。
どうしようか。まあ、適当にはしょって来月に回すしかないよな。
「開発日記」は最初書こうと思っていたことを、 なんかの拍子に度忘れしてしまって、悩んだ揚げ句「人狼BBS」について。 でも、雑誌が発売される頃には状況が変わってたりして。
で、「開発日記」を書いてしまってから、最初書こうと思っていたテーマを思い出した。 先月、さんざん苦労した「多言語化」の話を書こうと思ったんだ。 これも来月に回そうか。
昨年の夏に投稿した論文がやっと採択される。
しかし、お情けで採択してもらったので、修正の指示がかなり多く残っている。 〆切は今日。 やっぱ研究者には向いてないや。
でも、職業プログラマとしても(というか会社員として)かなり失格気味な私の生きる道は...？
自分で満足しているのは言語設計者の立場なんだが、 それって全然商売にならないしなあ。
冗談はともかく、忙しい。
こういう日に限って教会の用事が立て続いて、 日付が変わりそうなころにメールで論文を提出。
先に郵便で提出したハードコピーに間違いを見付けてしまい、 差し替えのハードコピーを明日送ることにする。ダメダメ。
U20プログラミングコンテストの結果がやっと発表になった。 正式決定するまでは箝口令が出ていたのだ。
受賞者のみなさん、おめでとうございます。
今年もなかなか面白いものが集まっていた。 というより、昨年よりもずっとレベルが高かった。 昨年よりも応募総数は減っていたようだが。
さて、もし時間を遡って今年の応募者にアドバイスできるとしたら、 「傾向と対策」は以下のようになるだろう。
ゲームは難しい。
今回の受賞者にもゲームが多いのだが、 実際にはそれ以上にゲームの応募は多い。 ライバルが多く、競争が激しいので難易度が高い上に、 審査員受けはそれほど良くない。
労力と受賞確率はさほど比例しない。
審査員はソースも読んでいるので、 「力業だな」とか「がんばってるな」とかは分かるのだが、 それは評価点のごく一部に過ぎない。 むしろ光るアイディアの方が評価される
優れたツールよりも独創的なアイディア
今回個人部門対象を受賞した「Aki黒板」は 黒板を再現するソフトというばかばかしくも独創的なアイディアが評価された。 たぶんこれは一番労力をかけたものでも、一番複雑なものでもないが、 似たものがない点が高く評価されたのだと思う。 もっとも大賞の選考の時には私は講演をしていたので伝聞なのだけど。
もっとも来年は審査員も変わるかもしれないし、同じことが当てはまるとは限らないのだが。
ある言語で頻繁に使われるデザインパターンは、他の言語ではパターンでさえない。 よって「デザインパターンは言語の弱さを示すサインである」という話。
確かにブロックを持つRubyではVisitorパターンや、Iteratorパターンは もはやパターンとは呼べないレベルだし、Observer、SingletonやDelegatorは ライブラリで対応できちゃう。
ということは、デザインパターンが頻出する言語は、「弱い言語」である、 ということであり。言語設計者はデザインパターンが頻出しない言語を目指すべき、ということ？
そうなのかも。とはいえ、「マクロが解答」というのも癪な話である。
Pythonを高速化する細々としたテクニック。 多くはRubyにも適用可能だ。
Hampton Catlinによって開発された新しいテンプレート言語。 「HTML Abstraction Markup Language」なのだそうだ。
!!!
%html
%head
%title Client Admin Site
%meta{"http-equiv"=>"Content-Type",
:content=>"text/html; charset=utf-8"}/
= stylesheet_link_tag 'tabbed'
= javascript_include_tag 'tabbed'
%body
#application
#header
.container
.statusbar
.logo
%strong Admin Interface
.menu= link_to 'logout',
:controller => 'account', :action => 'logout'
%br{:style=>"clear:both;"}/
.tabs
%ul.navigation
%li= link_to 'Member Approval', member_admin_url
%li= link_to 'User Management', user_admin_url,
:class => 'selected'
%li= link_to 'Pages', page_admin_url
%li= link_to 'Reports', reports_url
%li= link_to 'Help', '/'
#page
#content
//These will only render if there is
a non-false value returned from the helper
#errors= print_flash(:error)
#notice= print_flash(:notice)
= @content_for_layout
#sidebar= @content_for_sidebar || false
%hr/
#footer
%p= "Copyright Hampton Catlin 2006"
えーと、慣れたら使いやすい....のかもしれない...多分。
テレビで放映していたものを子供たちに見せた。
映画は自分たちで楽しむばかりであまり子供には見せてなかったんだけど(ポケモンかアニメにしか興味を示さないし)、 なんか、みんながみんな気が狂ったように笑うんだけど。
他の人(悪党)が痛い目にあうのがそんなに面白いのかしら。
確かに可笑しいけど。
というわけで、この種のものがウケると分かったので、 他にも見せてみようかしら？
akrさんのLinux Conferenceでの発表スライド。 如何に1.9で(akrさん主導で)ダイエットが行われたか、の記録。
akrさんのおかげで、1.9では以下のようなメモリ削減が行われた。
私自身のダイエットもこれくらい進んでほしいものだ。
スライド前半のRubyのオブジェクト構成の説明も (Rubyの中身に興味がある人には)有益な解説だろう。
Twitterのスケーラビリティに関する情報まとめ。
Twitterの瞬間最大11,000アクセスというのはおおげさに伝えられているが、 平均毎秒600アクセスというのも興味深い情報。 これは楽天の個別サービスのアクセスよりも多い。
また、それを実現したテクニックなどについてもまとめられている。
「STIC is the vendor neutral Smalltalk lobby organization」なのだそうだ。 今まで無かったのが不思議なくらい。
2008年6月18-21日にSmalltalk Solution 2008というカンファレンスも開催するそうだ。
Rubyアソシエーションもちゃんと仕事しなくちゃなあ。 やりたいことは沢山だが、できることは限られている。
とりあえずロゴコンテストの応募は沢山集まってるけど。
Scalaのstructural conformanceについて
def test(f: { def getName(): String }) { println(f.getName) }
と書けば、testメソッドはgetNameというメソッドを持つ任意のオブジェクトを (DuckTyping的に)引数にとりつつ、静的な型チェックも行える、という話。
もう一歩進んで
def test(f) { println(f.getName) }
だけで、
とかまで推論できるとかなりうれしいのだが、 いくら型推論言語でもシステム全体をそれで通すわけには行かないだろうなあ。
C#における並列パフォーマンス実現機能。 C#から離れて純粋にAPIとして見ても興味深い。