ToDo:
これの達成は、言語の数を以下に簡単に見積るかと いうことにもかかっているけど、年齢にもかなりよるよな。
15歳で達成できてたら変態だ。 20歳で達成はちょっとすごい。 25歳くらいが一番達成しやすそうな気がする。 30歳くらいになるとまたキツくなってきて、 40歳くらいで達成してるとかっこいい気がする。
(01:31)
なるほど。
http://www.nmt.ne.jp/~ysas/diary/?200706c&to=200706291#200706291
これは Code Golf の方で使ったことあるけど、 あれくらいの真剣さでやらないと出て来ないなぁ。
(01:34)
http://d.hatena.ne.jp/odz/20070629/1183121217
koreha omo si roi.
gmail toka dato motto owatteru na.
(01:37)
読み終わった。なかなか面白かった。 ストーリーが一本じゃないから刻んで読んで忘れてても そんなに問題にならんかったのもよいとおもう。
なんかこう、囚人って変人ばっかやなー と思ってしまうのだけど、 よくよく考えるとドストエフスキーの書く人間なんて もともと変人ばかりなのであった。
でもアルカトラズで聞いた感じでも変人ばっかだったけど、 アメリカ人なんて俺に言わせりゃみんな略。 いやそうでもないか。
でどう面白かったかというと。 うーん忘れたのだった。
あーなんだ。当時の平民と貴族の断絶っぷりは 尋常なもんじゃないなーとか。
いやまぁそういうことより こうネチネチネチネチと 人間について細かい描写を ひたすらにしていくだけ、 っていうのが楽しいんだよな。
(13:26)
たぶん二回目だけど読んでみた。
とりあえずtypoぽいのがあるな。
http://assam.cims.hokudai.ac.jp/et/indexj.html
この条件は他のルールの_景況_は受けません。
たぶん影響。
_C語_のように処理を細かく指定したり
C言語。
(14:03)
文章の主張の根拠がよくわからないのは、 主に Prolog と比較してるからだと思う。
プログラムに厳密な正当性を求めると代償が伴いました。例えば論理プログラミングでは
とか
記述可能です。例えば、Prologでは
とか、こいうの。 まぁ僕が知らんのがアレというか対象読者はまともな研究者なんだろうし まぁしょうがない。
ただなんか、 「非常に高速に」とか「非常に単純明快」とか が曖昧で根拠がその場に無いのは エンジニア的にはイヤンなかんじ。 Apple的というか。
(14:09)
とりあえず libboost は static link して欲しいにゃー と思いつつゴマかして動かす。
Hello …と思ってドキュメント読むのに飽きたので YT さんとこを見る。 動いたけど意味ない。
あとリンクと言えばデッドリンクが結構あって困る。
このへん読めばいいのかな。
http://assam.cims.hokudai.ac.jp/ettext/dtext/chap1.html#1
む、まただよ。
ＥＴの枠組みでは、プログラムを作り出すことは比較的たやすくなる。 それは、一挙にプログラム全体を作り上げる必要がないからである。
こいうの見ると大抵の言語はファイルを分けられるし 一挙に全体作ったりしないんじゃないのか…とか思うのであった。
(14:19)
(fizzbuzz 0) --> (print "done").
(fbprint *N), {(:= 0 (mod *N 15))} --> (print "FizzBuzz").
(fbprint *N), {(:= 0 (mod *N 5))} --> (print "Buzz").
(fbprint *N), {(:= 0 (mod *N 3))} --> (print "Fizz").
(fbprint *N) --> (print *N).
(fizzbuzz *N) --> (fbprint *N), (:= *M (- *N 1)), (fizzbuzz *M).
現状では Prolog と何が違うのかよくわからないのと、 あと := と = と == の違いがわからないという。
(14:39)
http://assam.cims.hokudai.ac.jp/eti/eti_builtin/arithmetic.htm#arith
http://assam.cims.hokudai.ac.jp/eti/eti_builtin/match.htm#unify
http://assam.cims.hokudai.ac.jp/eti/eti_builtin/match.htm#eq
これ見ると == 使うのが正しく見えるんだけどなぁ。
(14:43)
def ite(n):
if n < 0:
raise ValueError("minus dame zettai")
for i in xrange(n):
yield i
# Error deru koto kitai simasu!
try:
ite(-1)
# Error tonderu hazu dayo ne!
assert False
except:
# OK
pass
何度やらかしてもこれはやらかす。
Io は呼び出し側が意識しないといけないので やらかすことは無い。
ite := method(n,
write("hoge\n")
for (i, 0, n,
i println
yield(i)
)
)
ite(10) // 全部実行される
@ ite(10) // hoge も出ない
微妙に関係したりはする: http://d.hatena.ne.jp/ku-ma-me/20070613/p1
(15:08)
| 前 | 2007年 6月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
>> 大抵の言語はファイルを分けられるし一挙に全体作ったりしないんじゃないのか…
そこらへんはまぁ，そういう話ではなく，「絞り出し法」 とかいうルールを仕様から段階的に作っていくための方法論の話が絡んでくるので，話だすと長くなるのですが…
まぁ，僕も，ちゃんと論文とか読んでボスと議論を繰り返すまでは，何が良いのかよくわからなかったです．
そのサイトは，技術的な根拠や必然性は一切書かれてないので，それだけを読んでもなかなか納得できないと思います．
# かといって，それ以外の資料は，もう原論文しか無いのですが… 人手不足の零細研究室の上，うちのボスは完璧主義者なので，全部完成するまえに公開して的外れな批判をされて時間を無駄にすることを嫌がるので，なかなか情報が外部に公開されなかったりも (過去に長年，Logic Programming の人たちに，散々的外れな批判や 「そんなのは我々の〜でもできる」的なナンセンスな反応しかされなかったので，わりと頑固になってしまったのです)．
要するに，等価な関係の記述を蓄積していくと，それがアルゴリズムになる，アルゴリズムは自動的に合成されることになるので，人間が全体を一気に考える必要が無くなってうれしい (そして，それを理論的に保証するためには，仕様に対する正当性という概念を厳密に定義することが必要不可欠なんですが，それは Prolog では考えられていなくて云々… とかいう話に)．
shinh さんのような熟練者は，問題を見た瞬間アルゴリズムを思いつくと思うので，面倒な理論とかはバカバカしく感じるかもしれませんが，初心者はなかなかそうは行かないと思うので．プログラムを作るための体系をちゃんと考えていくと，それが教育方法の成熟にも繋がっていくという良さもあると思います．
# 今のところは，とにかくたくさん本読んで，プログラム書いて読んでがんばれ ！ という，その人の資質に依存した根性論しか無いと思います．しかし，誰も彼もが shinh さんのようにプログラミングの才能があるわけでは無いので．
うーん。たとえば FizzBuzz とかどうなるんですかねぇ。そんなにうまくルールに分割できるんでしょうか。手続きに慣れてしまったからかもしれませんが、ハノイとかみたいないかにもアルゴリズムアルゴリズムした問題以外で Prolog 系言語が初学者に優しいとはどうしても思えないのです。
あとどうでもいいのですが、私はプログラムの才能とかそんなにあるとは思えません。単に時間投下量で勝負してる感じだと思ってます。それこそ根性論というか。
Prolog は，建前は「宣言を書く」ということになっているのに，現実的には，プログラマの頭の中で手続きを脳内逆コンパイルして宣言に変換しないと，まともなプログラムが書けないという，かなり捻れた言語なんですよね．理論と現実が乖離しちゃってる．
なので，初心者に Prolog が優しくないというのは，そのとおりだと思います．
ET の D ルールなんかは，まんまパターンマッチがある Scheme なので，素直に手続きが書けます．
S 式でも書けるので，プログラムを操作するメタプログラミングとかも容易ですし，ルールベース言語なので，ルールを動的に追加削除したりとかいう，いろいろと面白いプログラムも簡単に書けたりします．
また，バックトラックみたいな高度な処理は，N ルールで素直に書けます．
# バックトラックは深さ優先探索ですが，N ルールは幅優先探索 (Erlang みたいに大量のプロセスが非決定的に同時に走る) を素直にかけますので．
んで，Prolog ライクな (そしてより素直な) 仕様記述から，N ルールを生成して，N ルールを D ルールに変換して，D ルールから機械語を得る，という体系を作りたいなーというのがモチベーションとしてあります．そこらへんが，根本的な Prolog との違いですかね．Prolog とかは，みんな処理系依存ですから．
いや〜，ゴルフとかに夢中になれる人は，どう考えてもハッカータイプの人間だと思いますよ (笑) 僕はそこまでプログラミングが好きではないので，つくづく向いていない人間だと思います．
OS とかコンパイラとかは，なぜか純粋に好きなんですけどね．あと，アプリケーションとかを作るのも好きなんですが，プログラミング自体は好きじゃないという．
あー N の方が高レベルであるごりずみっくーで D が低レベルで手続きーみたいな感じなんですね。で N から D に変換とかしちゃったりするとグニャグニャ、と。少しイメージがつかめましたありがとうございます。
いやしかし D ルールの方あきらかに for 文的なも無いし、組み込みの map やら fold やらもリファレンスに見当たらないような…これどうしても再帰になりませんか。
あとまぁありがちな話ですが、好きも才能のうちなら才能アリキラン☆ということになるのでしょうが、3歳の時には積み木をクイックソートしてたとか最初に喋った言語は x86 とかそいう意味の才能は無いなぁと思ってる感じです。こう数十時間かけてやっと Quine の書き方わかったとか、今は十数時間かけても Unlambda 書けないとか年中そんなアホなことやってるわけです。
そこはまぁ，物凄い零細研究室なので… 実は今公開されている ETI は，うちの研究室 OB の人がドクタの時に，たった一人で作ったものです．研究用のプロトタイプもいいところです．
# それでけっこう長年，うちの大学の講義で実際に使われている e-lerning system が動いているというのも凄い話ですが．
今は某私立大学で教鞭を取られていて，なかなか時間が取れないようで．あと，基本的に C++ をあのレベルまでわかる人が他に誰もいないとか．
sumii 先生が，けっこう大きなコミュニティがある OCaml に対してさえああ言ってるという点からして，こう，いろいろ察してください．
(僕も基本的にああいう立場です．アカデミックの世界では，処理系の完成度とかではなくて，理論的なコンセプトの完成度が勝負所で，後々徐々に産業界に取り込まれていけば良いのかなと．もちろん，実用化ばかりを意識しているわけではありませんが．そもそも何が役に立つかなんて誰にもわからないわけですし)
N/D ルールのレベルだと，変数の破壊的更新が一切無いので，for 文を直接定義するのは難しいです．でも，末尾再帰で全部書けば問題ないのでは ? 基本的に扱うのは主にリストなので，再帰 + パターンマッチの方が便利だと思います．
実装においても，概念的にも，末尾再帰は単なる goto にコンパイルされるはずなので，for 文的なものと本質的な違いは無いはずです．
# いや，ETI の中身の最適化の度合いは知りませんが．
まぁ，全部手書きしようとすると，毎回同じような形がソースに現れて冗長ですが，それはプログラムを書くプログラムを書いておけばよいだけだしーという (メタプログラミング脳)
map やら hold やらも，組み込みであって欲しいですよねぇ．というか，append や length さえ無いんですが．
まぁ，そこらへんは定義すれば良いだけなので．拙著ですが．
http://www.geocities.jp/kl1_interpreter/GradThesis/thesis.pdf
map とかは 146 ページ，fold とか 150 ページあたりにあるみたいです (自分が書いたのに他人事)
計算機に限らず，工学の世界は知識量と経験が全て的なところがあるので，純粋数学のような意味での天才は生まれにくいでしょうねぇ．なので，好き = 継続できる力 = 才能で良いのだと思います．Schemer じゃありませんが，continuation is power と (笑)