三日間、シアトルでやるらしい。ぼくは今年はどう見ても無理です。そのころってちょうど某書の締切だし、なにより金がないです。均一にならない」プログラム言語だけに関わらずですよね。(行で言うなら)それぞれに違った役割があるわけだし。[シアトルでも原稿は書けるし、お金はなんとでもできると思うよ。Nutshellのゲラ直してました。[まあ、flameを始めるつもりはないんですが、ちょっと誤解があるかなと思ったので。Schmidtという方なんですが(ページの下方に書いてあります)、彼はLisperなのかな。RAAにプロジェクト登録しているみたいだけど。例の式は半分ジョークで、冗長な言語の見掛けの易しさを皮肉っているだけだと思いますよ。「行」という単位にあまり意味が無いことは同文章中に書いてあるし。[リンク先を読んでみると「各行を読む苦労×行数」は、Basic言語に対してと読めますね。(読んでからツッコメよ)だったら、少し納得。寝て起きたらうわあっ、妙にたくさんツッコミが入ってるっ。郷に逝っては郷に従え、みたいなあ、いや、ぼくのほうも半ばギャクですし。言ってくれたら文句ゼロで賛同するんですけどねえ。整合性がある皮肉ではないですよ。作られる構造の数が重要なのだ」と言ってるわけじゃないですか。記法の短さじゃなくて文法構造の短さが問題のはず。八つ当たりするのは変です。整合性がないことに違いはない。プログラムを読む苦労の総和まじめに考えると、Σでもまずいでしょうねえ。単発の文をいくらたくさん並べて書いてたところで総和は難しくないですから。いうことになると難しくなるわけです。(よく知らないですけど)。いう感じの、構造を制御する数学を使って解くべきなんじゃないですかね。制御の線が多いかどうか、線がどのくらい交差するか、ということをしないといけない。それも、言語の隠してる部分まで考えて計算するべきですね。逆に言えばそのプログラム言語はある部分を隠しているとも言えます。その隠した部分が想像しやすいものであれば、プログラマは動きを想像しやすくなります。想像しにくいものであれば、想像しにくくなります。ないわけですが、思いついてしまったので思いつくままにいろいろ言ってみました。