薄いブログ

去年はなんかこう，無駄に毎日エライ長文更新というスタイルを貫いてきたので，今年は凄い長いスパンで更新されて内容も凄い短いという，なんかこう凄い薄いブログスタイルで行こうとか思った．

---

なんかこう，やる気が出ないな．ていうか，風邪を引いているのである．だいぶ良くなってきたけど，頭がぼーっとして思考がまとまらない．

せっかくの日曜が丸々潰れてしまったんだけど，どのみち北海道は暴風雪だったので，まぁいいかと．むしろタイムリーとさえ言えるかもしれない．

明日から講義が始まるので，なんとしてでも今日中に治さないといけない．

---

今年は研究 （らしい研究活動） をちゃんと進めて，論文書いて，ちゃんとどっかの学会で発表しないとなぁ．さすがに去年はダラダラどうでも良い事しすぎた．もうブログなんて書いてる場合じゃないよ，ホント．

---

Lispについての正しい認識と、それでもLisperがLispを使う理由

ここに書いてある Lisp の暗黒面って，別に Lisp に限った話では無く，ようするに動的型 （いや，これも静的検証ツールやしっかりした処理系があれば済む話だけど） の粘土みたいな言語で未知のシステムを作る際には，必ずハマルようなポイントなのではないだろうか．

逆に，Web とかなんとかで，既にフレームワークが存在するようなドメインだったら，それこそ言語とかは何使っても同じだと思う．だから，フレームワークの有無しで言語の優劣を付けるとか言うのは，なんというかどうしようもなく本末転倒というか．

俺なんかはとりあえずテキトーなシステム書き過ぎで，もうかなり研究関係のやっつけコードがたまってきていて，今年はまずそいつらをちゃんと書き直すところから始めないといけないんだけど．

ボクは，とりあえずシステムが動くところ，まではなんとかモチベーションが続くんだけど，いったん動くと興味が一気に無くなるというダメ人間なので．今まで誤魔化し誤魔化しでやってきたんだけど，さすがにそろそろ限界でしょう．

そんなこんなで，去年の年末辺りは研究のモチベーションが限りなく低くなってたんだけど．今年こそツケをちゃんと全部払って，次のステージに研究をすすめる所存であります．

みたいなことを，ここを読みながら思った．

遅い人

まぁ，ボクの場合は，思い付いてから実装するまでは比較的速いんだけど，コードが汚くなりすぎて… （とりあえず S 式にシンボル突っ込んで，やっつけのとりあえずルールを大量に書いて，とか．そして後々，仕様変更に仕様変更を重ねた後，巨大な S 式の塊に泣かされたり，スルーしておいた最適化パスを有効にするのを忘れたりという．あと，テストとかコメントちゃんと書け ！！ ← 過去の俺）

# ちなみに，ボクは ET とかいう謎の言語 （パターンマッチが使える，ルール型の Lisp ? というか Prolog というか） を常用しているので，ツールもライブラリも揃ってなさ過ぎて，より大変．

それをちゃんとまとめて，成果を積み上げて，アイデアを理論として論文化していくみたいなのが苦手という．

まぁ，ようするに性格がテキトー過ぎて研究に向いてない，ということなんだけど （駄目）

---

いや，Shiro さんみたいに優秀な人 （具体的には，かなり遠くの仕様変更まで，（ぼんやりとでも） あらかじめ見通して設計できる人） ならば，それでも最終的にはちゃんとシステムを完成させられるし，そういう人ならば，Lisp の欠点 （的なもの） は相対的に薄まり，利点だけが強調される結果になるのではないだろうか．

逆に，sumii さんみたいな，未知のシステムであっても最初からある程度目星を付けて進んで行けるような方ならば，OCaml みたいにシステム全部の整合性が取れていないと実行もできないような静的型の言語でも，欠点が欠点とならず，利点だけが強調される結果になるのではないだろうか．

いや，ボクが ML とか Haskell とか D とかがあんまり好きじゃないのは，逆に構文指向の言語だから，というのもあるんだけど．要するに，「とりあえず S 式」 ができないから （心理的に） 窮屈というか，つまり気分の問題．やろうと思えば，どの言語でもボクがやりたいことはたぶんできるのだろうとは思う．

ただし Ruby 作者も言っているように，気分の問題，ってのは馬鹿にできなくて，オブジェクト指向なんちゃらってのの最大の利点は，やっぱり気分の問題な気が．

結局，プログラミングという行為は非常に属人性が強いので，言語機能がどうこう，ツールがどうこう，フレームワークがどうこう，という議論はいろいろ虚しい，というのがボクが以前からずっと思ってきたことで．そこらへんは （ボク的には） 非常にどうでも良い．

---

ものすごくどうでも良いことだけど，なんで言語オタクとかいう人々ってのは，Prolog とか GHC/KL1 は （故意かか本当に知らないのかはともかく） はなから無視するのだろうね （笑）

いつか言語ヲタになりたい。

実用性はともかく，新たな知見という意味では，Haskell とかに勝るとも劣らないぐらい豊かな世界が広がっていると思うのですが．KL1 はともかく，Prolog ならば処理系も Web 上のリソースも日本語の本もいっぱいあるし．

いや，特に深い意味は無く，最近 「それ Prolog」 「それなんて KL1 ?」 と思う機会がやたら多かったもので．あー，やっぱりどうしようもなく認知度低いんだなと．改めて．

% [Erlang] Erlang デビューしてみた

基本的なところは ML とか Haskell とか触ったことあれば、迷うところはあんまり無さそう。変数名が大文字かアンダースコアで始まらないといけないってのが、ちょっと変わってる感じ。

それ Prolog w (Prolog は，大文字で始まる識別子が変数になる)

% [Erlang] Erlang のちょっとした特徴

同じ名前でも引数の数が違うと別の関数

まあ、要するに関数のオーバーロードだから、Java とかから見ればめずらしいわけでもないかもしれないけど、関数型言語として見るとめずらしい感じ。引数の数によってシグネチャが変わるから、それぞれに export するかどうか選べるのが肝。とりあえず、関数内関数がうまく作れない (クロージャだと再帰できないし) ので、その代わりとして使ってるが、デフォルト値を持った関数を書く時なんかもすっきりする気がする。

．．．

なんだかんだ言ってもパターンマッチがサイコー

やっぱパターンマッチが有ると無いとじゃ、流れの把握しやすさが段違いだと思う。その事実は動的型付け言語でも変わることは無い。Ruby とか Python もとっととパターンマッチを採用するべきだと思うよ。

Erlang とか良く知りませんが，ここらへんは思いっきり Prolog （というか，ルール型プログラミング言語） の特徴でしょう．

あと，並列関数型言語ということで，並列論理型言語の GHC/KL1 とも，プログラミングテクニックなどが思いっきり重なるでしょうし (並列論理型言語GHCとその応用)

# GHC/KL1 は，論理型言語，と言いながらも，並列性を実現する際に不利になるバックトラックなどは廃止されているため，限りなく関数型言語に近い，というか，非決定的な意味論を持つ関数型言語と言っても良いような．Erlang と KL1 の関係などはよく知りませんが

# 追記 : 変数に再束縛できない ってのも，Prolog 由来だと思います．もともと，この特徴によって並列計算が容易になるという性質に目を付けたのが，並列論理型言語．その際，バックトラックは，変数を一度破壊しないといけなくて （ボックスモデル） 並列計算に不利なので廃止されたという．あと，やっぱりパターンマッチがある言語の中に，Prolog は入ってないのね w (むしろ本家なのに．70 年代からあるから，かなり歴史は古いはず) Scheme にパターンマッチってあったっけ ? そもそも，関数型言語のガード部でのパターンマッチと，ルール型言語のそれはけっこう異なると思いますし．

マルチプロセッサ向けソフトウェアパラダイムとは？ (ユメのチカラ)

それなんて第五世代コンピュータ計画，と

ムーアの法則によりインテルの単一 CPU パワーの激増によって淘汰された超並列計算機アーキテクチャとプログラミングが，ムーアの法則の限界に直面し再び表舞台に復活するかもしれない，という歴史の皮肉．やはり時代を先取りしすぎだったのでしょうねぇ．

第五世代コンピュータプロジェクトは死なず！＼(^O^)／

# KL1 ってのは，極端な超並列言語で，全てのアトムがガードで同期を取りながら非決定的に並列実行されます．当然専用のハードウェアも作られました．日本が世界をリードしていた黄金のような時代の話です．その後貿易摩擦という当時の事情 （日本脅威論が非常に強まった時代） によって IBM と INTEL によって潰されたのですが （ファイゲンバウムの 第五世代コンピュータ―日本の挑戦 とか，持ってるけどまだ読んでないから怪しい知識だけど）


20XX年のユビキタス、ロボット、Web／Ｔｅｃｈ総研

今後は map の並列化とかが注目されるだろうって… それこそ，FORTRAN 作ったジョン・バッカスさんの FP まんまですから… っ ！！

チューリング賞受賞講演 Can Programming be Liberated from the von Neumann Style? は 1977 だから，ちょうど 30 年前か… （ため息）

まさしく人類の夢．超並列計算パラダイムは滅びぬ，何度でも甦るさ，と．

今，風邪で非常に頭がぼーっとしているので，何書いてるかわからなくなってきたのでこの辺で．

最初は 5 行ぐらいで終わらせるつもりだったのになぁ…

---

とりあえず風呂に入ってすっきりしたよ．微妙に熱があったらしく，丸一日ぐらいずっと汗だくで寝込んでいたから．

jijixi さんの件といい，ボクが記事を書いた直後に，モロに関連する記事がいっぱい上がってきてタイムリーだなぁと．本当にシンクロニシティってあるのかもしれない．ユング万歳 （どうみても心理学的錯覚です）

最上の日々 1月8日（月）　▼ ITPro: スペシャルインタビュー: 世界がRubyを愛する理由

単にmapとreduceを加えれば良いのでは？と思ってしまった。

mapとreduceと後はsortのような配列演算ライブラリを整備するだけで、並列化可能な部分の99%は自動的に並列化される。Rubyでも簡単に対応できる。あとはiteratorにvariantかpragmaを入れて評価順を不定にし、破壊的変更を不可にするのを加えると良いかも。

なぜ、それはRubyの役目では無いと思うのかと、考える。上記のような変更は言語の変更としては小さいが、プログラミングのスタイルを大きく変えてしまう。そのことへの忌避感があるのでは無いかと思った。

それなんて (ry

ちなみに，リンク先のような，まつもとさんの公式の場 (?) での発言は，いつもいろいろ素晴らしいと思う．

私は，もっともっとプログラミング言語が作られるべきだと思っています。アプリケーションは，それこそ無数に書かれていて，その結果デザインパターンのような定石が生まれてきた。それに比べて，これまでに作られたプログラミング言語は数千か数万でしょうか。まだプログラミング言語をデザインするノウハウが確立するところまできていません。若い技術者にどんどんプログラミング言語の開発に挑戦してほしいですね。

どうして APL や FP やコネクションマシン (65,536台のプロセッサから構成される超並列コンピュータ) が流行らなかったかというと．

もちろんハードウェアの成熟度 （当時の集積度レベルでは，特殊な超並列チップの性能向上よりも，汎用的で大量に量産され，シンプルな単一 CPU の速度向上の方がはるかに劇的だった） などの，歴史的要因もいっぱいあったんだろうけど．

結局のところ，いつもの，パラダイム （人間の平均） の進歩は技術の進歩よりもはるかに遅いということなのかも．天才が 10000 歩歩いても歴史は動かない，歴史は，10000 人が 1 歩歩いた時に動くでござるよ薫どの，みたいな話 （るろうに剣心）

現状のプログラムは，プログラミング言語，というよりも，プログラミングパラダイムの影響に強く制限されていると思う．

良くいわれるような，「○○が流行らなかったのは，実際にやってみると○○の需要は思ったよりも少なかったから」，ではなく，「○○は難しいから無意識の内にみんな使わないようにしている」，の方が正解なのではないか．例えば並列性についてもそう．

そのような無意識的な抵抗感が消えた時こそ，バッカスの夢 「プログラミングはフォン・ノイマンスタイルから開放され得るか ?」 が実現するのだろう．もう 30 年も経ってしまったけど．from 1977 to 2007

歴史は巡る．いろんな言語が消えては現れ，現れては消え．行く言語やスタイルの流れは絶えずして，しかも元の言語にあらず．