最近のいまさら過ぎる Y コンビネータネタとかが 100 近いブクマを集めている様子とかには，正直辟易していたのですが．
(あんたらもしかして，ポール・グレアムの VC (
http://ycombinator.com/) の名前の由来とかを，今まで知らなかったの ? とか．Web 2.0 プログラマ (?) 向けの VC のような気がするのに… これで，VC の面接の質問の一番最初が 「我々の名前の意味を知ってますか ?」 とかだったら皮肉過ぎる w まぁ，MIT とかスタンフォードとかの計算機科学部を出てれば 100 % 知ってるだろうし，そういう人たち対象なのでしょうが)
2005 年とかにも話題になって，sumii さんとかが同じようにネタにしてたんですよね．Y コンビネータとか，基礎的な計算機科学の概念を勉強する最大の価値は，何度も定期的に繰り返されるブームに踊らされないで済むということかも :-)
まぁ，そんな，がんばって GCC とかの記事書いても1ブクマもつかないオメガブロガーの僻みはどうでも良いとして (笑)
k.inaba 神のまとめが大変素晴らしいですね．このネタを引き出したというだけでも，1年以上前の話題をループさせた価値はあったのかもしれません．
# 追記 もう 2008 年だから 2 年以上前だよ ！ 時間の流れが止まってるよ…
Derive Your Dreams 17:08 08/01/29 まとめ
lambda やクロージャを使って何ができるかやってみるのも楽しいけれど、時には、逆に、lambdaやクロージャは何と何を使ってできてるのか、とか、何と何があれば lambdaやクロージャがどのくらいのレベルまで実現できるのか、を考えてみるのも楽しいこともあるかも。役には立つかどうかは人によるような気がする。
そういう風に「○○は何と何があればできるのか？」を突き詰めてった一つの究極が …… 「ループって再帰で書けるよね」「名前付き関数っていらないよね。無名関数だけでいい。」「再帰もYコンビネータがあればいいしね。」「自然数ってChurch Encodingすればこれも無名関数で書けるよね。」「booleanとif文も全部関数だけで実現できちゃった。」 …… λ計算。
で、もう一つの究極が …… 「要はどんなオブジェクトも文字列化できる言語なら、create_functionみたいなのさえあればクロージャ要らんよね。」「全部文字列でいい。」「クラスオブジェクトとかもJSONとかみたいなのでなんか文字列になるよきっと。」「関数も全部"関数本体のソース"っていう文字列で表すことにしちゃえ。」「つまり文字列操作さえできれば他全部要らない」「文字列操作っつーか、一文字ずつ読んで隣の文字の処理に移って…みたいな一文字ずつの処理さえあれば実はおｋ」 …… チューリングマシン。
だったりもする。
これを見て，そういえば Smalltalk とか Lisp Machine みたいな (OS を含む) プログラミングシステムは，全てをオブジェクトとして統合的に扱うという点で，ラムダ計算的なパラダイムに基づくシステムなのかなぁと．もちろん，抽象階層のレベルは全然違いますけど，根底に流れる思想として．
逆に，UNIX とか Plan9 みたいな，アプリケーション間 (Plan9 ではネットワーク間さえも) のデータの流れを全部文字 (バイト) 列としてパイプとかリダイレクションでつないで，正規表現とかで切り貼りして扱うするような文化は，チューリングマシン的なパラダイムなのかも．
結局，ラムダ計算的なシステムは主流にはならず，チューリングマシン的なパラダイムが生き残ったので，その後は CPU とかプログラミング言語とかも，どんどん TM 的 （命令型) になってきたと．UNIX 文化は C と Perl を生んだわけで，PHP あたりはそれの Web 向けの後継という気がします (どちらもその後どんどん改良されて当初とは別物になってますけど)．
それが，現在のインターネット，ひいては Web アプリケーションの文化まで，脈々と影響を与えつづけている (テンプレートや正規表現の多用，(言語オブジェクトではなく) 文字列ベースの DB 操作やデータ通信) ってのは，なかなか面白いですね．
んで，ラムダ的な文化圏の人が 「文字列の切り貼りで Web アプリケーション作るのはダサいし危険だよ．それはセンス無いやり方だよ」 とか主張していると．Ruby なんかは，いろんな言語の合いの子なんでよくわかりませんが，構文が C/Perl (ALGOL) like な Smalltalk とか Lisp に近い文化圏なんでしょうね．
PHP とか Rails とか，単なる表層的な言語論争ではなく，Lisp Machine vs UNIX，S 式 vs XHTML もっと言えば ラムダ計算 vs チューリングマシン，そういう根本レベルまで遡れる構図なのかもしれませんね．言語レベルだけで語っていると，本質を見失うかも．
Matz 日記 2008-01-29 PHP使いの反論
なんか酔っ払って帰ってきたら，higepon さんのブログや amachang さんの twitter からリンクが…
自分が無能なプログラマだってことぐらい分かってますよ。才能もないし。そう思ってるからこそ、必死に勉強してるんですよ。それが悪いことですか。はてブとかどうでもいいんじゃないですか。
http://www.twitter.com/amachang/statuses/659075442
あわわわわ，すいません．(このブログではよくある)ちょっとした自虐ネタのつもりだったのですが… ＞＜ 無能とも言ってないですし，悪いとも言ってないです… そもそも，amachang さんほどのアルファブロガーが才能無いんだったら，日本に才能あるプログラマなんてほとんどいなくなるような… (^-^;
はてブが付く，注目を集められるってのは，それだけで素晴らしい才能だと思います．僕みたいに何書いても反応が無いオメガブロガーは，その才能が眩しくて妬ましいんですよね．なのでついつい怨み節に満ちた攻撃的な書き方になってしまったのです (苦笑) ほんとすいません
別にラムダ計算にせよ Y コンビネータにせよ何にせよ，そんな知識いくら知っててもクソの役にも立たないですし，飯は食えないので，僕のような NEET 同然の貧乏大学院生からすれば，知名度があって有名企業に勤めてる amachang さんなどは圧倒的に立場が違うので，蚊に刺された程度にも感じないと思ってテキトーな噛みつき記事を書いたのですが… もし傷付けてしまったのならば，ホントすいませんでした m(_ _)m
あとまぁ，higepon さんなども，僕などとは比較にならない圧倒的な勝ち組ですので．数学とか物理学とは異なり，歴史も体系化も浅い計算機科学 (レベルのアカデミックの) 知識なんてのは，ちょっと学校通うか，何冊か本読めば誰にでもわかる程度の知識なので，全然大したこと無いです．それよりも，継続して開発しているプロジェクトを持っていて，知名度があって，立派に社会人やってて，家庭を維持しているということの方が，中途半端な知識やプログラミング技術などよりもはるかに立派なことですよ (あまりにもあたりまえすぎていまさら言うようなことでもないですが)
というわけで，単なる日陰の NEET キモオタのやっかみ記事ということで．多少気に障ったとしても，スルーしていただければ幸いです (甘え)
まぁ，こんだけ (客観的に読みかえしてみると) 痛い記事書いて，higepon さんや amachang さんにリンク張っていただいても，ブクマもコメントもそんなに付かないし，炎上もしないところが，このブログのオメガさを象徴してますね （自虐） ← こういうのがよくない w
面白い記事でした．これからも頑張ってください．
たしかに，チューリングマシン的な文字列操作を中心にすると
処理状態が見えづらくなりますね（そして型も考えづらくなる）．
文字列中心で処理することは，evalを使いまくるということにつながると思います．
Lispにしても変則的なevalの使用はややこしさの最大要因ですね．
はてなの人口が増え続ける限り、同じネタがブクマされるのは仕方ないのではないでしょうか。
どれだけ既出な話でもやっぱり知らない人は知らないわけで。
逆に言うと、何度もブクマされるということはY Combinatorは誰が見ても「すごい」と思えるような、キッチリしっかりした理論だということですよ。
"There's a sucker born every minute" -- P.T. Barnum
たく、ややこしい奴だなw
自分からすれば、ブクマの数がどうこうよりもすげー濃い面子が(挙げ忘れると
とっても失礼なので具体的な名前は出さないけど)直接コメントつけてくれたりしてるじゃない。
1000や2000のブクマ(とそこについたコメント)よりもよほどありがたいものだと思うけど
そういうところに価値を見出せない?
#日々「戦いは数だよ、兄貴!」とか吹いてるけどね。わしw
> 通りすがり さん
ありがとうございます．
よく正規表現が諸悪の根源と言われるのですが，文字列ベースのパターン記述というのは構造が無く (コンパイル時にチェックもされない．例えば printf が代表例) 原始的なプログラミングになりがちなので，S 式などの言語オブジェクトを操作するプログラミングに比べると，速度・エラーチェック・可読性など，様々な面で不利なことが多いです．
なので，必要以上に文字列ベースに依存するのは，センスが良いとは言えないでしょうね．現在の Web プログラミングなどは，CGI/マークアップ (XML/HTML)/DB 操作/アクション記述，全部バラバラのプログラミングモデルで，それを文字列ベースでつぎはぎてきに組み合わせてるだけなので，統一的なプログラミングモデルが存在しないという点が，一番の問題だと思います．どのプログラミング言語を使うか，なんてのは瑣末な問題に過ぎないと思います．
もちろん，オブジェクトモデルに左右されない，一番プリミティブで汎用的なデータ表現というメリットもあるのですが (Plan9 なんかは，バイト列以上に汎用的なデータは無いということで，徹底的に何もかも，OS のコアとの I/F もネットワークも GUI さえも，全てファイルとして抽象化してます)
既存のものを効率的にパイプなどで組み合わせて，とりあえず動くものを作るというのも，UNIX に限らず，インターネットの本質的な思想だと思いますし．AJAX などは，インターネットの理念 (高尚な理論よりも，とりあえず動くことを優先する，機なるべく既存のものを再利用してコストを抑える) の申し子と言えると思います．
> さん
知らないことを馬鹿にしているわけではありませんし，知っているからといって直接何かの役に立つわけでもありませんが，もちろん知らないよりは知った方が良いですね．むしろ amachang 氏のような有名人がとりあげることにより，裾野が広がるので，それはどんな高名な学者でもできない，大変素晴らしいことだと思います．
> きむら さん
だーかーらー 自虐ネタなんですよ w
そういうわかる人にしかわからないややこしいネタを，わかる人にだけわかれば良いってスタイルでずーっと書いてきたのが，このブログなの （笑）
コメントくださる，大変素晴らしい方々には，もう何度も何度も感謝の言葉を書いてきたはずですし，既にわかっていただいているはず (という甘えというか，信頼が)
そこそこアクセスがあるのに，ブクまが少ないということは，みな常連さんということでもありますしね．そっちの方が，ニュースサイトとかに張られて，一過性のブクマがたくさん付くよりもはるかに有り難いことです (とかいうセリフは，ニュースサイトに張られるぐらいメジャーになってから言えっつー感じですが ← いういうのが)
>わかる人にだけわかれば良いってスタイルで
まあそれはわかってたつもりだけど、たまに拗ねたくなることがあって
それがでたのかなあとw
このところ鬱屈がたまってるみたいだから。
紙一重のところを見切るのは難しいよね。ということでひとつ。
#まつもとさんのあれもそうだな
うーん“統一的なプログラミングモデル”ですか……色々と難しそうですね．
理想としては，現状同じようなことやっているすべての逐次スクリプト言語
(Lisp/Scheme/Perl/Javascript/Ruby/Pythonなどなど)の基盤が
統一されればいいなとは思うのですが．
SQLの関係代数と，あともう一つの言語くらいになってほしい．
もちろん，Parrotとかはありますけどね．
でも，命令列的なVMの統一は，Javaと同じだし，あまりうれしくないような．
もう少し上のレベルで統一できないものでしょうか？それこそラムダ計算みたいに．
コンパイラにはあろはさんが頑張っているGCCの中間言語なんかあるみたいですが．
しかしあれはＣ言語的なコードの表現だけに留まっている気がします．
たぶん，クロージャ(局所環境付きオブジェクト）を確保したままの
モデル化・運用は色々と難しいのでしょうね．
そういえば，SICPにある環境モデルの説明でもちょっと複雑でした．
そしてさらに，Rubyみたいに継承機能が絡むとさらに参照関係がゴチャゴチャになりますね．
以下，話は変わりますが，こちらは“汎用的なデータ表現”の話．
そういえばこんな記事があったことも思い出しました．
＠IT：XMLにおける「ボヘミアンと貴族の階級闘争」を読み解く:
http://www.atmarkit.co.jp/fxml/tanpatsu/24bohem/01.html
これはXMLへのスキーマ，つまりは型づけの話みたいですが．
XMLの処理を，
ボヘミアン：テキスト（文字列）構造
貴族 ：文法（スキーマ）を満たすツリー構造
で，テキスト vs. ツリー中心のどちらで考えるかということを言うらしいです．
あろはさんは，貴族寄りということになるのでしょうね．
僕からしたら alohakun さんの才能が凄くうらやましいです。
自分の知らないことをググっていると、
よく alohakun さんのブログが出てきて勉強させていただいていましたし、
いつも遠くから憧れていました。
今回は失礼なことを twitter で発言してすみませんでした。
これからも、たのしくブログを読ませていただきます。
# そして、今回の件でチューリングマシンやラムダ計算を少しだけ理解することができました。
# ありがとうございます
GCC のアレは単なる趣味で遊んでるだけでして，本職の研究の方は全然違うことをやってたりします．んで，Web 系のプログラミングモデルの方は (僕が研究しているわけでは無いので，どこまで外部に公開しても良いのかわからないので，かなり仄めかして曖昧に書いてるわけですけど) そういうことを目的にした研究をやっている人はいます．
正規表現にせよ，SQL や XML の文字列埋め込みにせよ，そういう DSL 的な機構ってのは，しょせんは後付け，もともとの言語のプログラミングモデルや実行モデルとはかけ離れたものなので，コンパイル時の検証や最適化が困難なので，安全性の保証が難しく (SQL インジェクションなどが代表例) 効率も良くなりませんし （Rails が代表例），結局のところ，違う言語を一から覚えるのとたいして変わりません．確かに構文は見慣れているので，一見親しみ易そうに見えますけど，中身は全然別物なので，初学者の学習は容易にはならないでしょうね．これが，Web プログラミング (に限らず，単なる異なるモデルの寄せ集めシステム) が難しい本質的な理由です．これが 「プログラミング言語」というレベルでプログラミングを見ているパラダイムの限界でしょうね．
# C++ が難しいのも，あれは本質的には 4 つぐらいのプログラミングモデルのパッチワークだからですね (構造化プログラミング (C) + ユーザ定義型機構 (Simula) + Generic Programming (STL) + Template Metaprogramming (Boost) + α)
# C# は LINQ なんかで，Java のように，単に SQL を文字列として埋め込むのではく， 言語機能と統合しようとしているようですが… Scala も XML をリテラル表記できたり．でも，関数型言語ってのは，DB 操作と相性が悪い気がします．論理型言語なんかは，本質的に言語の実行モデル自体が DB 操作なので，比較的近かったりしますが，完全ではありません．もうちょっと統合的なプログラミングモデルを作る必要があると思います (それが，我々の研究なんですけど)
おっしゃる通り，GCC は，おおざっぱに言って，C/C++ (静的な OOP)/ObjC (動的な OOP)/Java (C++ と Objc の合の子) などのための，コンパイラフレームワークなので，スクリプト言語とかには向かないでしょうね．
ラムダ計算とかチューリングマシンみたいな計算可能性の理論ってのは 「『計算』とは何か ? 何が計算できて，何が計算できないのか ?」 ということを明確にするための理論 (計算理論研究の対象にする世界を，おおざっぱに区切るだけの理論) なので，プログラミングモデルとかよりも，はるかに下の階層だと思います．
僕は以前から amachang さん (に限らず，表舞台で注目を浴びる 「東京の」 ブロガー) 羨ましいネタを僻みったらしく書いてきていて，そういう自虐ネタがブログの枕詞になっていたというか (笑) なのでそんなに重く考えないで，軽くスルーしていただければ幸いです．
# 愚痴をダラダラ書いた後 「とかいう話はどうでもいいとして」 で本題に入るなどの「オヤクソク」
こちらこそいろいろ失礼もうしわけありませんでした．amachang さんに取り上げていただいてアクセス数が増えたので感謝しております．やっぱり可燃性が高いネタは美味しいなというアクセス乞食っぷり．地方で淡々と，家と研究室を往復するだけのような地味な生活をしていると，人間が小さくなって駄目ですね (← こういうのがよくない)
僕は全然すごくないですよ．ダラダラ親のすねかじって，学生支援機構から借金しまくって，良い歳していつまでも国の税金で学生やってれば，誰でも僕程度の知識は蓄えられます．研究者のたまごとしても，落ちこぼれ寸前で，ギリギリしがみついてなんとか足掻いてる程度の実力しかありませんし．学生は国の宝と言いますが，僕は不良債権になる可能性高いです w
働いて税金納めて，実際に世の中の役に立つものを作りながら，超人的なペースで知識を吸収している amachang さんや higepon さんの方がはるかに凄いですし，才能もあると思います．あれだけの影響力を持ちながら，慢心せず，ストイックかつ謙虚に自己研鑚し続ける姿に，僕もいつも，文字どおり遠く海外 (笑) から，憧れていますよ…
基礎的な概念だからこそ、当然、新しくそれを学び始める人が常に一定数いるわけで、「いまさら」も何もないんじゃないんですかね。それこそ、1930年代かそこらのネタを21世紀にもなって何をいまさら…… (^^;;
…とそれはさておき、通りすがりさんのボヘミアンと貴族の話はちょっと違うかな、と思ったのでものすごい勢いで駄弁りにきました。
どちらも、XMLをツリー構造として考える立場であることに違いはありません。
自分の理解では、ボヘミアンは「データ(XML)はデータ、型(スキーマ)は型と分けて考えよう」という立場です。同じデータに必要に応じて色んな粒度の型を付け替えるとかそういうことがあっていい、という立場。貴族は、「型のついてないデータなんてありえない。型のもたらす情報があわさって初めてデータはデータになる」という立場。
プログラミングの世界でこれに対応する議論は、"ボヘミアン" Gilad Bracha が提唱している
"Pluggable Type System"
http://lambda-the-ultimate.org/node/1311
かな、と思っています。「型システムとプログラムは可分になってるべき」みたいな考え方。
# 面白そうなので誰か調べてまとめてくれないかなー
そこらへんはまぁ，烈海王の「その場所は我々が2年前に通過した場所だッッッ！！！！」ぐらいのネタと (ry
マジレスしとくと，これですね．
http://d.hatena.ne.jp/hira_sosuke/20080113/1200181456
XML あたりだと，門外漢の私があれこれ言わなくても，専門家の k.inaba さんとか m-hiyama さんあたりに wktk してしまうところですが，予想通り凄い勢いで反応していただきうれしいです (o^冖^o)
なんだかさっぱりよくわかりませんが，「型システムとプログラムは可分になってるべき」ってのは面白そうですね．
> k.inabaさん
あーすみません．やっぱり専門家の方から指摘がきましたか．
後から読み直してまずいなーと思っていました．
XMLをツリー構造と見ない理由はないですよね．
処理する場合の意識として，（例えばSAXとかスクレイピングな場合には）
ツリー意識が薄れてしまうということはありそうですけど．
ボヘミアンは，プログラムと型が独立していると見る．
そして，型は適時色々あってよいということでしょうか．
分かりやすい説明ありがとうございます．
これは各種プログラム解析や，型推論（再構成）システムとも関係しそうですね．
そうしてみると，ボヘミアンの方が現実的に思えますね．
（どちらもあまり良く分かっていないのですが）RESTに比べてSOAPみたいな
技術が最近弱まっているのは制限がきつすぎるからかも？
もっとPluggableなものがほしいのかもしれません．
> あろはさん
> GCC のアレは単なる趣味で遊んでるだけでして，
> 本職の研究の方は全然違うことをやってたりします．
趣味であれだけできるのはさすがです．本職も頑張ってください．
> 関数型言語ってのは，DB 操作と相性が悪い気がします．論理型言語なんかは，本
> 質的に言語の実行モデル自体が DB 操作なので，比較的近かったりしますが，完全ではあ
> りません．もうちょっと統合的なプログラミングモデルを作る必要があると思います (そ
> れが，我々の研究なんですけど)
たしかに，論理型方面の言語はより強力なSQLを目指すべきな気がします
（いやXMLQueryでもいいのかな？ストレージは表を基本とする方が美しい気がしますが）．
Datalog - Wikipedia, the free encyclopedia：
http://en.wikipedia.org/wiki/Datalog
を思い出しました．演繹データベースなどと呼ばれているみたいですが．
あまり聞くことがないのは効率や表現力などの面で足りないことがあるのでしょうね．
> ラムダ計算とかチューリングマシンみたいな計算可能性の理論ってのは 「『計算』とは
> 何か ? 何が計算できて，何が計算できないのか ?」 ということを明確にするための理論
> (計算理論研究の対象にする世界を，おおざっぱに区切るだけの理論) なので，プログラ
> ミングモデルとかよりも，はるかに下の階層だと思います．
いわゆる「計算モデル」ですね．
http://en.wikipedia.org/wiki/Category:Computational_models
いや，「計算」という言葉は紛らわしいですね．
そう，プログラミングモデルと計算モデル（というより抽象のレベル？）
をはっきり分けて考えなければ．
各種の計算モデルが混ざり合ってしまうからややこしくなるのでしょうね．
それでもなんとかできてしまうあたりは，ノイマン型（チューリングマシン）の
すごさも感じますが．
まさしく，ここですね．ここが，一番面白いところです．
>> 各種の計算モデルが混ざり合ってしまうからややこしくなるのでしょうね．
>> それでもなんとかできてしまうあたりは，ノイマン型（チューリングマシン）の
>> すごさも感じますが．
「計算機には何ができて，何ができないのか ?」すなわち「原理的に，何が計算できて，何が計算できないのか ?」
チューリングマシン/ラムダ計算/帰納的関数論/ポストマシン，定式化のやり方はいろいろあるんですが，どうやら全部同じ計算能力 (チューリング等価) があるようだ．なので，このクラスを計算可能関数と呼ぶことにした (チャーチ･チューリングのテーゼ) と．
http://ja.wikipedia.org/wiki/%E3%83%81%E3%83%A3%E3%83%BC%E3%83%81%EF%BC%9D%E3%83%81%E3%83%A5%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AE%E3%83%86%E3%83%BC%E3%82%BC
出発点は全然違うのに，枝葉を刈り取って抽象化を推し進めていくと，実は全部同じモノだった ！ というのは，理論の帰結の一番ドラマティックな形ですね．これは本当にすごいことです．
もちろん，だからといって，プログラミング言語は全部同じということにはなりません．冒険する世界の大きさは明確に区切られたわけですが，実際に世界の中をどのようにして探検すれば良いのかっていうのは，目的 (仕様) によって様々です．どういう地図やコンパスを提供できるか，っていうのが，プログラミングモデルの役割ですね．世界をどのように見て，どのように攻略していくか ? というのは 「パラダイム」と呼ばれたりします．のっぺりとして捉えどころの無い世界に構造を与え，意味付けを行うわけです．たとえ，具体的なレベルではやってることが同じでも，新しい光の当て方が発見されれば，また見える世界は違ったものになるでしょう．それが，理論の重要性というか，面白いところですね．
とてもいまさらですが．
いつもながら，Passion溢れる返答ありがとうございます．
しかし，こういう話を聞くたび，いつもこの文章が頭をよぎりますね．
たかが論理、されど論理：
http://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/7bits/saredo
いや，この悲観的な内容．正直あまり公開していてほしくないかもと
思うのは私だけでしょうか．
しかし，XMLやLispが認識されてきたということは少しづつ仕様・プログラム
を扱う知的なシステムへは近づいてきている気がします．
いや，あろはさんの卑下する気持ちは私も良く分かりますよ．
でも，あろはさんは本物だと思います．頑張ってください．
これからはもっと粒度の小さい専門知識で忙しくなるかと思いますが，
暇なときはまた一般的な記事を，そして，もちろん
専門知識も公開してもいい気がしますけどね．
ブックマークなんて，ほんとくだらないシステムだと思います．
日本のあれもdeliciousみたいにまともにならないものか．
あれって中途半端な数なのが性質悪いですよね．
……しょうもない愚痴になってしまいました，終了します．
ありがとうございます．今ちょっと大変な時期なこともあって，非常に励まされました
感謝感謝で，もうちょっとだけがんばります (来週修論発表会なのです)
# ただ，ブックマークは単なるツールなので，それを批判するのは筋違いという気もしますが (笑)
その萩谷先生のコラムは，もはやかなり古い内容だと思いますね．
pre K&R (UNIX V6) とか，昔の (register 宣言とか) C コードから機械語が透けて見えたような時代ならばいざ知らず．
現状，C 言語の (ノイマン型べったりと形容されるプログラミングモデル) でさえも
複雑化しすぎたアーキテクチャとの解離が激しいので
かならずしも C でべた書きしたから早くなるという時代でもないと思います．
むしろこれからの時代こそが，いかにしてプログラマの知識を体系化して
現実のハードウェアアーキテクチャとの間の制約条件を踏まえつつ
効率的なプログラムを合成していくか ? という研究の重要性は増し続けていくと思います
コンパイラってのは，昔みたいな単なる高級言語からアセンブリ言語への決め打ちの変換器じゃなくて
プログラマの経験と知識を蓄えた一種の AI （知識ベースシステム） にならないといけないんですよね．
あまりにも瑣末な知識が莫大なものとなってきているので，もはや一人の人間の
学習能力を大幅に越えていると思いますから．
そして，プログラミングモデルの整備 (単なるライブラリの寄せ集めではなく
いかに統一的なモデルを提供できるか) も並行して重要になってくるでしょうね
つまり，プログラムドメインごとの仕様記述手法の発展 (何が本質なのかという，モデルの整備) と
そこからの正当かつ効率的なプログラムの探索・合成の研究，両方という意味です．
>> これからはもっと粒度の小さい専門知識で忙しくなるかと思いますが，
>> 暇なときはまた一般的な記事を，そして，もちろん
>> 専門知識も公開してもいい気がしますけどね．
まさしくその通りですね．今までは比較的広く浅くやってきたのですが
これからはどんどん，狭く深く勉強しないといけないことがたくさんありますね．
昔は比較的自由に書けたんですけど，現在は研究室内のチームで役割分担を決めて
研究を進めているような感じになってます．なので，どこまで話していいのかということが
非常に微妙で難しいので，なかなか研究の話は書けなかったりします (苦笑)
もちろん，勉強したことについての一般的な記事や，既に論文になっている専門知識などは積極的に書いていきたいですね．
コメントありがとうございました ！
> 来週修論発表会なのです
あっと．これは余計な時間をとらせてしまいましたね．
申し訳ない．
いや，いつも空気読めないコメントばかりで本当に．
感謝しております．発表会がんばってください．
このコメントは管理人のみ閲覧できます
