読者です 読者をやめる 読者になる 読者になる

レガシーコード生産ガイド

私に教えられることなら

最近やってること

近況です。

プログラミングについて

今まで体験した中で、お気に入りは

  • Smalltalkでの、デバッガ・インスペクタを用いたオブジェクトを直に触って環境を変えていくスタイル
  • Clojureでの、immutableでextensibleなマップやシーケンス等に関数を適用していくスタイル
  • Elmでの、型検査の安心感と、ML系の記法とカリー化による関数合成のやりやすさ

の3つです。

特にSmalltalkの、全てがオブジェクトという環境は衝撃的で、味わって以来、とにかくファイルベースの環境から逃げ出したいという思いが強くなるばかりです。

というわけでClojureみたいなimmutableなデータ構造をベースにした、Smalltalkっぽい環境作れたらな〜とコードを書いていました

Scheme(Gauche)でClojureのPersistent Vectorの解説記事を参考にデータ構造を実装して、いつも通りパーサコンビネータとパーサを作って、プロトタイプ用のSECDマシンを書き始めました。

そこでふと気づいたのは、デバッガやインスペクタでオブジェクトを覗きこみながらプログラミングするスタイルだと、目の前の値を書き換えられないというのは、とてもストレスが溜まるということです。何かがおかしいと思ったら、動いている最中のコードを書き換えてそのまま動作を見たいし、その変更をできるだけそのまま使いたいのです。そのためにはLate Bindingと、やはりオブジェクトの破壊的な変更が必要になります。

不変な値で上手くやる方法もあるかもしれませんが、遠回りにならない方法は思いつきそうにありません。また、そこまでこだわりもないので、諦めることにします。cloxpとか他の人に期待します。

ちなみに何故SqueakやPharoなどのSmalltalkをそのまま使わないのかというと、継承の存在です。継承は、Rich HickeySimple Made Easyで示したようなcomplect、複数の独立した概念を絡みあわせてしまったものだと思います。絡み合ったコードに、さらに別のコードを絡ませて上手く扱おうとしても、最終的に人智を超えると思います。少なくとも私の知能では簡単に手に負えなくなります。

というわけで、次はメッセージのディスパッチ方法を変えたSmalltalk風環境、のプロトタイプを作っていきます。今のところ、委譲ベースかな、とぼんやり考えています。

150人程度フォローしているTwitterアカウントを見ていると、変に時間を費やしてしまう上に何故か精神状態が非常に悪くなる事に気づき、更にそれに気づいたことで見たくなくなってしまったので殆ど見ていません……。理由はわかりませんが、ツイートや人の好き嫌いに関わらず、大量のメッセージが次々に流れてくる事自体がまずいのかなと推測しています。それと、今年1月ぐらいから、たま〜に絵を描くようになったのもあって、絵を貼ったりくだらないこと呟くようのアカウントを作りました。因果関係はわかりませんが、今のところ心身の状態は良いです。

音楽は打ち込みを完全にやめてしまって、Korg Kross-61というキーボードを買って毎日弾いています。ワイがやりたかったのはこれや!!という感触です。普通に弾いてるだけで楽しいので特に録音・発表などをするつもりは今のところないです。誰かとセッションはしてみたい。

運動あんまりしてないのまずいな〜〜と思っていたので、WBCの影響で再びプロ野球を見るようになった(昔野球少年でした)のもあって、彼女と毎朝キャッチボールしています。肩を回す+ボールを見るために視点を動かすせいか、肩こりや眼精疲労から来る頭痛やだるさが完全に消えて最高です。今のところ1時間程度で500kcalぐらいの運動になっています。それとゴルフ好きの親からいらないゴルフクラブを譲ってもらって、ゴルフの打ちっぱなしを始めてみました。今のところあまり面白さはわからない……。

それからMake: Electronics ―作ってわかる電気と電子回路の基礎という本に従って、LEDを焼き切ったりして楽しんでいます。いろいろアイディアがあるので、取り組むまでの道のりを早く埋めたいところです。

最近影響を受けた本

失敗の科学Antifragileです。

今までの自分が、根拠の無い予想と机上の空論、それによる恐怖によって動いていた(又は動けてなかった)のだな、と痛感しました。完全に人生観が変わって、そのおかげで最近は精神の調子がよろしいです。(そしてその影響であまりブログ記事を書いていませんでした、多分)

いろいろ語りたいんですが、中途半端に文章に残したくないことなので、誰かオフラインで会ったら聞いてください。

VMとGCとClosure Conversion(途中まで)

やったことの記録・感想です。

モチベーション

Squeak SmalltalkVMは、Smalltalkのサブセット「Slang」で書かれていて、Cに変換されて生成されます。

Slangはかなり機能が制限されてはいますが、サブセットなのでSqueak Smalltalk上で直接動かすことができます。(Squeak) Smalltalkの強力なデバッガを使うことができるので、そのままCで書くよりも大変楽、と聞いています。

その話を知ってから、同じようにLispでもサブセットでVMを記述してみたいと思い続けています。

VMを記述するためのサブセットに必要な特徴は、GCを書く部分だけはGCを利用してはいけない、ということです。(GC中にGCが発生すると……?)

The 90 minute Scheme to C compilerというスライド([日本語での説明])(http://www.slideshare.net/ryos36/90-scheme-to-c)を読んでいると、CPS変換は置いといて、Closure Conversionだけを使えばとりあえずlambdaをある程度便利に使ってGC不使用のCに変換できるのでは……?と思ったので途中まで書いてみました。

結論から言いますが、読み間違えていました。"One heap section (and currently no GC!)“というのは、GC不要という意味ではなく、ただサンプルコードで実装してないだけで、GCは必要です。例えばグローバル変数fooに対して、nがlexical scopeに入ってる状態で(set! foo (lambda (x) (+ n x))とやるとき、Closure部分のメモリをどうにかしてアロケートする必要があります。

というわけでC出力の手前ですがやめることにしました。まあ結構楽しかったし、後で使いそうなので良いかな……

Lambda Liftingなら不要かもしれませんが、Internal Defineぐらいにしか使えないので、単純にGC記述部でのlambdaを諦めたほうが良さそうです。

Closure Conversionについて

最初、どう書いていいのかわからなくて結構苦労しました。

まずlambda/apply/def/symbol/valueだけのシンプルな文法のみを対象にして、さらに Closure Conversion→トップレベルへのLambdaの持ち上げ と分けて書きました。Schemeみたいに動的型付けの言語なら、中間表現(の型)が増える事を気にしなくていいので、何度もフェーズを分けて処理し、後にアルゴリズムを統合するという戦略でも良いと思います。

こういった式の変換については、ML系のレコードやClojureのマップのような、Immutableな名前で引けるデータ構造があると楽です。引数を増やすことで対応するとかなり厳しいコードになります……。

コード

(途中まで中途半端に自作方言への移植を目指したので、変なコードになっています)

github.com

「小さなチーム 大きな仕事」を読んだ

前々からある作りたい仕事があったんだけど、自信が持ててなかった。しかしこの本から「どう流されずにやっていくか」という態度を学べてとても良かった。同時に「イノベーションのジレンマ」も読んだけど、そっちは半分参考になって、半分はサイズ感が合わなかった。

本の書かれ方も、その考え方を体現している。芯となる部分は何か、ということに注力しているのが感じ取れて小気味良い。

まだその段階では無いときに、詳細に入り込みすぎてしまうことに対して、環境をコントロールする方向で対策を取ってるのも参考になる。そうしようと思ってたんだけど、できていなかったことに気づけた。

と、自分用のメモとして書いてたらやけに抽象的になった。良かったです。