hamadaさんから
ところで、Plankalkuel についてですが、Konrad Zuse が作った Z3 というコンピュータ上で動いていたわけではないのでしょうか？
というツッコミがあった。
確かに、 Plankalkülの設計者でもあるKonrad ZuseはZ3というコンピュータも作っている。 というか、PlankalkülはZ3用に設計されたのだ。
しかし、彼がPlankalkülにかかわっていた1949年までに、 処理系が動いたという事実は確認できていない。 この時点では記法として設計されていたのではないかと考えている。 この時代の技術レベルでPlankalkül処理系が実装されたとはいくらなんでも考えにくい。
Wikipediaには、
It was first published in 1972 and the first compiler for it was implemented in 2000 by the University of Berlin.
と1972年までは存在さえ(広くは？)知られていなかったこと、 最初のコンパイラは2000年(!)に実装されたことが記されている。
参考資料
p.s. しかし、ウムラウトは打ちにくいぞ。
うちの社長と島大の縄手先生と学生さんとで新年会。今年は焼肉。ちょうど今朝、焼肉食べたいな、と思っていたので、ちょうど良かったのだが、食べ過ぎた。おなかいっぱい。研究のこととか、就職活動のこととかいろいろ話したような気がするなあ。
朝から雪。あっという間に道が真っ白になる。 米子道はそうとう積もっていて、 雪道をこわごわ岡山へ。
しかし、岡山県に入ってしばらくすると雪は消え、 岡山市内では雪なぞ影も形もない。 山陰と山陽の気候の違いを思い知らされた。
会議終了後、日が暮れて凍結しないうちにできるだけ進みたくて、少々急いで帰る。 山間に近づくにつれ、朝よりは量は減っているものの、それなりに雪が積もっている。
だが、息がスムーズだったので気がゆるんだのか、あるいは、急ぎ過ぎたのだろうか。 蒜山のあたりでスリップ。右サイドをガードレールに当ててしまい、 タイヤがグリップを失った。カウンターを当てようとしたが*1、コントロールし切れず、そのまま回転。 時計まわりに約300°ほど回転したところで止まった。
ガードレールに当ててしまったところは少しへこんでしまったが、 それ以上には車にも人にも被害はなかったのは、とてもとてもラッキーだったと思う。 命があってよかった。
でなければ、Rubyの開発が致命的に滞っていたことだろう。 もちろん家族も路頭に迷う。
車にまた大きな傷をつけてしまったのはショックだが、 ここは我慢しなくてはいかんのだろうな。
*1 素人がとっさにマンガのような運転ができるはずがない
米子へ行く。
実家の両親はまだ風邪が治り切っていないということで、 挨拶のみ。去年から滞っていた贈り物や荷物の交換。 こちらの風邪、向こうの用事などでクリスマス前からずっと会えてなかったから。
その後、弟のうちに行き、赤ん坊を見てくる。 まだ生後10日にもならないが、結構男の子らしい顔をしているような気がするのは 思いこみか。
その後、買い物などして帰る。
本当は仕事初めなのだが、
があるのに、今日になって
4日前に〆切だった原稿についてどうなってますか
というメールが来た。がーん、完全に忘れてたよ。 っていうか、そういう奴なんで、〆切当日に催促してください、お願いします。＞ 担当の人
仕方がないので、オフィスには行かないで(移動時間もったいない)、 自宅で超特急でスライドを仕上げて(今日〆切)、 夕方から東京に向かう飛行機で4日前〆切の原稿を仕上げ、 ホテルについてから日経Linuxの原稿。
これで私も立派なライターです(〆切を忘れる人は立派じゃありません)。
今回の日経Linuxのテーマは「AJAXとJavaScript」。
ちなみに4日前〆切の原稿は「Rubyレシピブック第二版」の前書き。 この調子だともうすぐ出るはず。
は、IDEであるという話。
あんまり、リファクタリングツールとか使ったことないんだけど (私にとってはEmacs全体が巨大なリファクタリングツールなので)、 慣れ親しんだ人には必須なのかもしれない。
動的言語にはリファクタリングツールは難しいって思ってる人もいるみたいだけど、 リファクタリングツールの元祖は動的言語そのものであるSmalltalkなんだから、 難しいってことはないだろう。RubyだとRipperみたいな構文解析をする ライブラリの使い勝手がもっと良いとリファクタリングツールが作りやすい かもしれない。ParseTreeとか？
「なぜLispを学ぶべきか」という話。
このエントリだけを見るとRubyでいいじゃんって思っちゃうんだけど、 S式を使った自己書換とかマクロの駆使とかはRubyでは逆立ちしてもできないね。 あと、MOPという概念がRubyにはないので、それを使いたい人も Lispが良いと思う。
今風のプログラマ。
この分類で見る限り、私は限りなく1.0的だなあ。 以前の「ニュータイプ/オールドタイプ」の時もオールドタイプだったし。
まあ、結構古いプログラマなんで仕方がないと言えばそうだし、 昨今の2.0ブームも下積みになる1.0の層があってこそ存在できるわけだし。
1.0万歳。
でも、真似しなさいとは言えないな。
本当は[言語]タグではないような。
MozillaハッカーであるRobert O'Callahanによる、 「UTF-16はダメ、UTF-8でいいじゃん」という話。
私も前に書いたような気がするけど、 UTF-16は良くない。まず、第一にUTF-16はバイト単位のCES(Character Encoding Scheme)でないので エンディアンの影響を受ける。これは結局同じ名前で2種類のCESがあるのと同じである。
それを区別するための方策がBOM(Byte Order Mark)だが、 これが輪をかけてよくない。 BOMの文字としての意味は「ZERO WIDTH NON-BREAKING SPACE」なので、 これは見えない文字である。付いているかどうかひと目でわからない文字は 面倒なだけである。うっかり文字列やファイルの途中に混じってしまったら目も当てられない。
さらにその全身前身であるUCS2と比較して、
UTF-16は固定長ではない。ので、n番目の文字をアクセスするコストは
普通に実装すればO(n)である。
UCS2の頃に重大な選択を「してしまった」Javaとかはともかく、 これから選ぶならUTF-16はありえない。 もう、ダメの三連荘。
UTF-16がダメなら、なにを選ぶのか。 ここではUTF-8を推奨している。私も(条件つきで)賛成する。
UTF-8は、エンディンアン問題と無縁である。 BOMも不要だ(付けられるけど)。メモリ効率もUTF-16よりはずっといいし。 可変長であるという点はUTF-16同様だけど、 それもそんなに問題ではない。
というのも、そもそもn番目の要素へのアクセス(ここではCharAt(n)と呼ぶ)は そんなに登場しないからだ。実際に頻繁に現れるのは 文字の検索であり、それはもともとO(n・m)だったりするし、 UTF-8でBoyer Mooreを実装するのもたやすい(今のRubyはKarp Rabinを使ってるけど)。
LarcenyというScheme処理系でどのように文字列を表現するか、という話。 前にShiroさんが話してたものだね。
紹介されているのは以下の7通り。
興味深いのはやはりrecord2やrecord1。 ただ、これってSchemeに閉じている時にはいいんだけど、 Cから文字列がほしい時にはrecord1やrecord2のフォーマットのままでは困るので、 毎回UTF-8なりUTF-16なりに変換してやる必要が出てきそうだ。 そうなったときに、変換やメモリ割り当てのコストがどのくらい効いてくるかが 興味深いところだ。少なくともRubyでは難しそうだなあ。