コードの世界 http://amzn.to/MgHEmL という著書を読みつつも、何か変だな。。
と感じていた。が、昨今、Colorado州で開かれたwork shopに参加して、Prologをやっておられた方の意見で、スッキリとした。それを以下に書く。
どういうコンピュータ言語が普及するのか)
- 革新的な記述アイディアがある
- 実行速度が速い
- プログラミングする量が少なくて済む
など思いつく。が、いずれも本質ではない。本質はズバリ。
コンピュータ言語は習得に時間がかかる。なので、普及するためには、あえて習い直したいような価値すなわち応用が存在するか。
につきる。これが、彼がくれた卓見である。
Rubyは、オブジェクト指向を取り入れたり、webの記述に使える、記述がシンプルであるなどの特徴を持つ。が、普及した最大の理由は、大手の楽天が、積極的に採用し、このユーザが増えたからだと思われる。
「2006年よりRubyに対する取り組みをスタートさせ」
インタビュー：［楽天］Ruby活用事例とROMA，Fairy
http://gihyo.jp/dev/column/01/prog/2010/030801「2006年よりRubyに対する取り組みをスタートさせ」
などにある。
コンピュータ言語は、オブジェクト指向などの新アイディアは出てきているものの、強い型制約(たとえば、Pascal : http://ja.wikipedia.org/wiki/Pascal)になったり動的な型決定(Perl, Ruby)になったり、関数型言語(Lisp, Haskel)になったり、制約プログラミング(http://bit.ly/Md5dkm)になったり、行ったり来たりしていて、それほど、新しい概念が出てきているわけではない。
Rails http://ja.wikipedia.org/wiki/Ruby_on_Rails が、存在したからだと言う人もいる。これは、TCL/TK の普及が、TCLが良かったからではなく、「x-windowのプログラムがスクリプト言語で簡単に書けるTKがあったからだ」、という人が居るのに似ている。
もちろん、画期的なアイディアで、従来できなかったことができるようになるとか、プログラミング自体が圧倒的に簡単になる。ないしは、バグが入らなくなる。など、飛躍的な進化があれば、それは、「習い直したいような価値」や、「新たな応用」を生むことになる。
Rails http://ja.wikipedia.org/wiki/Ruby_on_Rails が、存在したからだと言う人もいる。これは、TCL/TK の普及が、TCLが良かったからではなく、「x-windowのプログラムがスクリプト言語で簡単に書けるTKがあったからだ」、という人が居るのに似ている。
もちろん、画期的なアイディアで、従来できなかったことができるようになるとか、プログラミング自体が圧倒的に簡単になる。ないしは、バグが入らなくなる。など、飛躍的な進化があれば、それは、「習い直したいような価値」や、「新たな応用」を生むことになる。
たとえば）
まつもとゆきひろ氏は、上記コードの世界の中で、Javaに対するPerlでの記述の完結さを主張している。つまり、下の図(著書: 「コードの世界」のp.11より引用）のように ()や{} ; を用いずに、予約語をデリミタに使ったと言うことである。これは、まつもと氏 以外は気づかなかったのだろうか。。否である。
当然、皆知っていた。それでも、Java等が、メジャーになったC言語のこの形を踏襲したのは、見慣れているからであろう。() {} ; 等を削って減らせるタイプ量は極わずか。それで、見慣れない形式になるよりは、既存の言語に近づけようというのが、世の中のあり方。これに背いてまでも、Rubyが普及できたのは、上記に書いたように応用が存在したというラッキーさに他ならない。
氏の新刊書、「コードの未来」のインタビュー http://engineer.typemag.jp/keyperson/2012/07/matz.php では、そうは見えないので、
まつもと氏は違うと思うが、技術者が思い上がると、方向を間違えることがあるので、本当に注意が必要である。
上記の著書では、言語に関する深い知識での設計思想が紹介されていて面白いが、技術者が思い上がって独走してはならない。いつの時代でもマーケットあっての技術である。
むかし変だなと思ったこと）
こういう話しもあった。世の中の事象は、物体が相互影響をしながら動いている。本質的に並列処理で有り、オブジェクト（モノ）とモノが相互通信をするオブジェクト指向で書いて、これを並列に実行すれば性能はいくらでもあがる。
結構、有名な先生も言っていた。が、全然実現していない。
当然である。自然界では、物体の影響は近傍であっても瞬間的に伝わる。コンピュータで扱う以上、空間方向は数値の精度を上げればよいが、時間方向はどうしても離散化する。これを細かくしないと計算制度がでないが、細かくすれば、計算時間がかかる。
そこで、世の中では、数値計算を使って解決していた。つまり、微分方程式の数値解法である。ここでは、積分の時間ステップを短縮するために、陰解法 http://bit.ly/MgKqsl という、より精度の高い微計数予測を使う。これによって、時間ステップを100倍以上に粗くすることが出来て、計算時間がぐっと縮まる。だが、疎な行列の逆行列演算になり、並列度はぐっと下がる。これは、並列オブジェクト指向であっても解決しない。
また、有限要素法 http://bit.ly/MgKwQB とよばれる数値解析法もあるが、これも、空間の切り分け方（メッシュ http://bit.ly/MgKEQj ）を上手に最適化することで、計算時間を短くしているが、これをやると、負荷が不均質に成り並列化はぐっと難しくなる。また、車の衝突シミュレーションのように、時間に伴い形状が変化していくことも多く。するとメッシュも変化させないとならない。つまり、プロセッサへの負荷分散も変わっていき並列化性能を出すのが難しくなってゆく。
言語設計だけにこだわって、応用や問題の解き方をみないと、こういう事態がおきる。
言語設計だけにこだわって、応用や問題の解き方をみないと、こういう事態がおきる。
上記の本の間違い）
些細なコトだが、コラムに書いている点で間違いがあるので指摘しておく。コラムだからと専門外のことを検証しないで、書くと間違いが起きる。
p.282 「2つの法則」本には、ムーアの法則による速度向上とあるが、ムーアの法則は、あくまでも集積度向上の法則であり、これは現在も維持されている。
p.282 「2つの法則」本には、ムーアの法則による速度向上とあるが、ムーアの法則は、あくまでも集積度向上の法則であり、これは現在も維持されている。
ムーアの法則に陰りがでてきて、クロックが停滞したというのも間違い。クロックが上がらなくなったのは、発熱量限界によるもの。
そもそも「陰りがでてきて」と書きつつ、「タスクを分割できるプログラムがムーアの法則の恩恵をうけ高速化できるようになります。」と書いていて自己矛盾しているのに気づいていない。
p.318 「時間の難解さ」ローマ時代に皇帝の名前を2ヶ月突っ込んだ(JulyとAugust)... これは誤っている。wikiにもあるが、http://bit.ly/MgLsEH に詳しい。つまり3月始まりを1月はじまりにしたので、8を意味するOctが10月になっただけである。
名前の由来とこれが混乱している。http://ja.wikipedia.org/wiki/8%E6%9C%88 ：英語の8月Augustは、ローマ皇帝Augustus（アウグストゥス）に由来する。アウグストゥスは紀元前1世紀、誤って運用されていたユリウス暦の運用を修正するとともに、8月の名称を「Sextilis」から自分の名に変更した。ということである。
名前の由来とこれが混乱している。http://ja.wikipedia.org/wiki/8%E6%9C%88 ：英語の8月Augustは、ローマ皇帝Augustus（アウグストゥス）に由来する。アウグストゥスは紀元前1世紀、誤って運用されていたユリウス暦の運用を修正するとともに、8月の名称を「Sextilis」から自分の名に変更した。ということである。
投稿
