仕事風景
自宅での仕事風景はこんな感じです。今日は緑の子が2台。オフィスと自宅の間をラップトップ4台運んでいます。
devel@laptop.orgにもちょっと書きましたが、タッチパッドは非常に使いづらいです。というか、ほとんど使い物になりません。USBマウスを外付けしないと大変です。
ネットワークを使うプロセスがよく死にます。せっかく二台あるのでやることはひとつ、Nebraskaによる共有だったわけですが、つなごうとした瞬間にサーバー側もクライアント側も死んでしまいます。Squeakの問題でない証拠に、Web Browser Activityでいろいろ見ていても、Browserが死んでしまいます。
Sugarの「枠」は使いにくいです。きっと改良されるでしょう。
Etoys内のいろいろなところの文字はやっぱり読みづらいです。Pango対応を急がねば。
それはそうと、devel@laptop.orgにちょっと長々と書いたら、神経衰弱ゲームの作者が、神経衰弱にも「教育的意義がある」と強く主張してきました。大丈夫か?
http://mailman.laptop.org/pipermail/devel/2006-November/003176.html
言語実装用言語
Cが使われるのはたまたまでしょうねえ。Lispのcarとcdrの語源を考えれば、Lispももともとハードウェアに非常に近いところを記述できる言語でもあったわけです。Smalltalkのat:やat:put:だって、ArrayやByteArrayはCの"[]"と大差ないですし。
小さなブートストラップ用の処理系は書いた上で、後は全部自分自身で書くというのは、まともな記述力を持った言語なら昔から当然行われてきたことではあります。まともな記述力というのは、コンパイラとか構文木とか実行系とかの要素がその言語自身のデータとして扱えるということなので、CとかRubyとかは外れてしまいますが、LispやSmalltalkとかということになるでしょうか。ML系の関数型言語もその線に載っているものが多いと思うのですが、実行している自分自身を変えるときの自由度が小さい(たぶん)という問題はありますね。自分自身の言語で書かれているというだけならCだってCコンパイラは普通Cで書きますが、とてもじゃないけどコンパイル実行中のプログラムが使っているデータ構造が見えるわけはないですからね。
最初のSmalltalkはBasicで書かれたわけですが、その後の変更は基本的には歴代のSmalltalk内で行われてきたわけですし、Lisp-70はS式の書き換え規則だけでバイナリにまで落としてしまうというものでした。Cが使われるのは、OSのAPIがCのものが多いということと、みんなが力を入れて最適化をがんばった歴史があるということですね。Squeak VMはSqueakで書かれていますが、CへのトランスレータがSqueakで書かれていて、それをコンパイルして実行します。いろいろなOSに移植することを考えると、Cが一番ポータビリティがあるのは間違いないと思いますが、「Cで書く」必要は特にないですね。
Cokeも、小さなブートストラップ用のIdStコンパイラ(idc)はC++で書かれていますが、"stage 2"のidcはIdStで書かれていますし、Jolt以降は命令列を生成してメモリに書き込んで実行するところまでCokeで書かれています。ABIは、Cの関数が呼べるようにCokeの関数呼び出し規約はCのものを使うようになっていますが、そこも本質的ではないです。
