やっぱりハードウェア方面の人々には話が通じやすくてよいなと
ソフトウェアの人に 「仕様記述が… 検証が… 自動合成が…」 という話をしたとしても，「はぁ ? んな面倒で大げさなことしなくても，Ruby で書けばいいじゃん (ﾌﾟｹﾞﾗ」 というような反応をされがちで，日々枕を濡らしているわけですが (大げさ w)
ハードウェアの世界は，バグがあったら Windows update 〜とかはできないし，ずっとβ版でいいや〜 Web アプリはいつでも bugfix できるし〜 という甘い世界でも無いので，検証のコストが馬鹿みたいに高いわけです．ハードにバグがあって 「なんだこのチップは ！ 女将を呼べ ！！」 と回収騒ぎになったら，あっという間に会社が傾きもう死んだも同然なので．豚肉や中国の兎肉は混ぜてなくても，「従業員も全部辞めて頂きますので」 となっちゃう．
もちろん，ハードウェアロジックの複雑度なんてのは，ソフトウェアに比べたら相対的に単純なんだけど．現在のハードウェアはどんどん大規模化複雑化が進み，テストなどの品質保証のコストの割合が，全行程の半分以上とかいう，ソフト屋さんの世界から見たら考えられないような異常事態になってきている．
そうなってくると，プログラムが「人間にとって」書きやすいか，とか読みやすいか，とかは何の意味も無くなってくる．どうせテストで全てのバグを洗い出すことなんて不可能だし，巨大な論理回路を全て人手で検証するなんてことは非現実的だから．
なもんで，ハードの人たちは，僕が今ソフトウェアに対して憂いているような事態が，既にもう現実になってきているわけで．仕様記述とか検証とか自動合成とかいう概念の重要性が，ツーカーに通じるような感じなのがうれしい (笑)
おお，なにやらありがたい感じのお言葉が．どうもです．普段こういう話を書いても全然反応が無いので，うれしいなぁ．
なんか，僕は「Lisp の人」ってことになってますが (笑) 普段僕は，ET といううちの研究室独自の Rule-based なプログラミング言語しか使ってないので，全然 Lisp の人では無いです．プログラム変換の利便性のため，表記こそ S 式 (ソースコード上はルール形式でも書けるけど，内部では S 式になってる) ですが，セマンティクスが全然違うので．
あと，「晩飯の話」 とかのどうでもいいはなしは，別に隠蔽しているわけではなく，全部 mixi に書いてるだけですよ (笑)
ここらへんの，宣言的記述からの論理回路合成の研究は，うちの研究室でもやってる人がいます．
その人曰く，もともと，ここらへんの研究は，MIT のJames C. Hoe という研究者が，項書き換え系 (term rewriting system ; TRS) によるハードウェアの仕様記述と，仕様からの論理回路合成を考えたそうです．なので，今この分野は，MIT がリードしているみたい．ただ，表現力が TRS では不十分で，あまり性能も出なかったという話らしいです．
ちょっと 「term rewiting」 とか 「hardware synthesis」 とかでググっただけでも，いっぱいヒットしますねぇ．
上に挙げた Hoe さんのは，これなのかな ?
Hardware Synthesis from Term Rewriting Systems
なので最近は，いろいろアドホックなルールベース型の制約記述言語が考えられたりして，けっこうゴチャゴチャしてきているみたいです．
# 僕からすると，ここらへんの話は，全然新しいわけではなく．既存の C 言語のような逐次実行モデルや関数的な簡約モデルを持つ高級言語では，並行に動作するハードウェア間の制約の記述や検証が難しいので，過去にもいろいろ専用言語が作られている．例えば GHC/KL1 みたいな並列論理型言語も，その並列動作の意味論がハードウェアと親和性が高いので，いろいろ応用されたりしてきた．
Hardware synthesis from guarded atomic actions with performance specifications
もともとうちの研究室のボスは，同じように混沌としてきて進歩が停滞してしまった論理プログラミング (Logic Programming） や制約プログラミング (Constraint Programming) の世界をなんとかしようとして，今の汎用的な等価変換計算モデル (Equivalent Transformation Computation Model) を提唱したんですよね．
なもんで，それと同じように，ET のモデルと ET 言語という汎用的な枠組を使えば，そんなにゴチャゴチャいろんなプログラミング言語を新しく作らなくても，論理回路合成まで含んだ計算モデル全体を統合して，体系化できるのではないかという見通しをもって，うちの研究室の人々はみんな研究しているわけです．
まぁ，僕がやってる研究では無いので，どこまで論文ができてて書いて良いのかとはよくわからないし，そもそも研究内容の深いところまでは理解してないので，この辺で．
カコイイ ！
以前は，ソフトウェアに比べてハードウェア周りのエンジニアリング技術は遅れがちだったように思うけど．これからはどうなるかわからないねぇ．むしろハードウェアの合成技術の進歩がソフトウェアに大きな影響を与えて行くのかもしれない．そして徐々にハードウェアの柔軟性が増し続ける極限には，ハードウェアとかソフトウェアとかいう区別は過去の物になっていくのかもしれない．今後とも目が離せませんな ！
ハードウェアの世界は，バグがあったら Windows update 〜とかはできないし，ずっとβ版でいいや〜 Web アプリはいつでも bugfix できるし〜 という甘い世界でも無いので，検証のコストが馬鹿みたいに高いわけです．ハードにバグがあって 「なんだこのチップは ！ 女将を呼べ ！！」 と回収騒ぎになったら，あっという間に会社が傾きもう死んだも同然なので．豚肉や中国の兎肉は混ぜてなくても，「従業員も全部辞めて頂きますので」 となっちゃう．
もちろん，ハードウェアロジックの複雑度なんてのは，ソフトウェアに比べたら相対的に単純なんだけど．現在のハードウェアはどんどん大規模化複雑化が進み，テストなどの品質保証のコストの割合が，全行程の半分以上とかいう，ソフト屋さんの世界から見たら考えられないような異常事態になってきている．
そうなってくると，プログラムが「人間にとって」書きやすいか，とか読みやすいか，とかは何の意味も無くなってくる．どうせテストで全てのバグを洗い出すことなんて不可能だし，巨大な論理回路を全て人手で検証するなんてことは非現実的だから．
なもんで，ハードの人たちは，僕が今ソフトウェアに対して憂いているような事態が，既にもう現実になってきているわけで．仕様記述とか検証とか自動合成とかいう概念の重要性が，ツーカーに通じるような感じなのがうれしい (笑)
なつたん 2007.06.26 最近のへこみ
Lispの人って文章上手いよね。びっくりするくらい読んでいて面白い。C++/Perlの人ってのは混沌としている。ニッチな最適化の話をしていると思ったら、普通に晩飯とかアニメとかの話がでてくる。言語が性格を作るのかもしれない。C++とかPerlをやっていると、practicalな汚さを汚いまま受け入れられるようになるのだと思う。Lispの人たちは抽象度を上げていく過程で、晩飯の話は隠蔽されるのだろう。
おお，なにやらありがたい感じのお言葉が．どうもです．普段こういう話を書いても全然反応が無いので，うれしいなぁ．
なんか，僕は「Lisp の人」ってことになってますが (笑) 普段僕は，ET といううちの研究室独自の Rule-based なプログラミング言語しか使ってないので，全然 Lisp の人では無いです．プログラム変換の利便性のため，表記こそ S 式 (ソースコード上はルール形式でも書けるけど，内部では S 式になってる) ですが，セマンティクスが全然違うので．
あと，「晩飯の話」 とかのどうでもいいはなしは，別に隠蔽しているわけではなく，全部 mixi に書いてるだけですよ (笑)
ESLの本の5章から、bluespecなる言語を発見。こっちの記事からソースがダウンロードできます。見てみたけど意味がわからない。ESLの本によると、rule-based, declarative hardware specification language based on term rewriting らしい。素独を解いているのがN-queenを彷彿させてすごい。
ここらへんの，宣言的記述からの論理回路合成の研究は，うちの研究室でもやってる人がいます．
その人曰く，もともと，ここらへんの研究は，MIT のJames C. Hoe という研究者が，項書き換え系 (term rewriting system ; TRS) によるハードウェアの仕様記述と，仕様からの論理回路合成を考えたそうです．なので，今この分野は，MIT がリードしているみたい．ただ，表現力が TRS では不十分で，あまり性能も出なかったという話らしいです．
ちょっと 「term rewiting」 とか 「hardware synthesis」 とかでググっただけでも，いっぱいヒットしますねぇ．
上に挙げた Hoe さんのは，これなのかな ?
Hardware Synthesis from Term Rewriting Systems
なので最近は，いろいろアドホックなルールベース型の制約記述言語が考えられたりして，けっこうゴチャゴチャしてきているみたいです．
# 僕からすると，ここらへんの話は，全然新しいわけではなく．既存の C 言語のような逐次実行モデルや関数的な簡約モデルを持つ高級言語では，並行に動作するハードウェア間の制約の記述や検証が難しいので，過去にもいろいろ専用言語が作られている．例えば GHC/KL1 みたいな並列論理型言語も，その並列動作の意味論がハードウェアと親和性が高いので，いろいろ応用されたりしてきた．
Hardware synthesis from guarded atomic actions with performance specifications
もともとうちの研究室のボスは，同じように混沌としてきて進歩が停滞してしまった論理プログラミング (Logic Programming） や制約プログラミング (Constraint Programming) の世界をなんとかしようとして，今の汎用的な等価変換計算モデル (Equivalent Transformation Computation Model) を提唱したんですよね．
なもんで，それと同じように，ET のモデルと ET 言語という汎用的な枠組を使えば，そんなにゴチャゴチャいろんなプログラミング言語を新しく作らなくても，論理回路合成まで含んだ計算モデル全体を統合して，体系化できるのではないかという見通しをもって，うちの研究室の人々はみんな研究しているわけです．
まぁ，僕がやってる研究では無いので，どこまで論文ができてて書いて良いのかとはよくわからないし，そもそも研究内容の深いところまでは理解してないので，この辺で．
カコイイ ！
なつたん 2007.06.26 Bluespecは凄い！
関数型言語で高位合成をがすでにプロダクトになっていた。
まずはこのPDF見て欲しい。
Future Programming of FPGAs
英語だけど、10ページくらいしかないから大丈夫。
40年前の話を持ち出して、ソフトウェアの世界では、FortranとCは成功したけどLisp/Prologは失敗したよね。
でもハードウェアの世界は違うよ。C/C++/Javaが失敗して、Bluespecが成功するよ。からプレゼンは始まる。
最後は、ソフトウェアの歴史から学んだ教訓を忘れるな！で終わる。
cf. why Fortran and C succeeded
cf. why Lisp/Prolog/Functional Languages (mostly) failed
cf. why automatic parallelization (mostly) failed
以前は，ソフトウェアに比べてハードウェア周りのエンジニアリング技術は遅れがちだったように思うけど．これからはどうなるかわからないねぇ．むしろハードウェアの合成技術の進歩がソフトウェアに大きな影響を与えて行くのかもしれない．そして徐々にハードウェアの柔軟性が増し続ける極限には，ハードウェアとかソフトウェアとかいう区別は過去の物になっていくのかもしれない．今後とも目が離せませんな ！
