You can read this blog in any language using google translate as follows:

Goto http://translate.google.com/
Paste URL in the box and select "Japanese for From Language" and "To Language". Then click "Translate".

English translated pages are here:
http://bit.ly/xPuXoy

你可以閱讀這個博客,在任何使用“Google”的語言翻譯

本ブログのアクセス統計: 60万アクセスを達成しました。ご訪問ありがとうございました。

60万アクセスまでの経過

2009年12月に始めた本blog。2011年7月ごろに10万アクセスを達成し、2011年12月13日には15万アクセスを達成。
その後、私も更新しておらず、アクセスは少し減りましたが、3月1日には18万アクセス。2012/4/18に20万アクセス、2012/8/21に25万アクセス、2013/1/18に30万アクセス、2013/12/17に40万アクセスを達成しました。しばらく見ていなかったら、2015/5/1に50万2584アクセスになっていました。またまた、しばらく更新しないうちに、2017/6/11に60万7197アクセスになっていました。久しぶりに更新します。

2012年7月10日火曜日

普及するコンピュータ言語の要件とは - 技術者の思い上がりの危険

日本発で、世界に広まったコンピュータ言語で、まつもとゆきひろ http://bit.ly/MgHtYO さん作のRuby http://bit.ly/MgHwDQという言語がある。

コードの世界 http://amzn.to/MgHEmL という著書を読みつつも、何か変だな。。


と感じていた。が、昨今、Colorado州で開かれたwork shopに参加して、Prologをやっておられた方の意見で、スッキリとした。それを以下に書く。

どういうコンピュータ言語が普及するのか)
  1. 革新的な記述アイディアがある
  2. 実行速度が速い
  3. プログラミングする量が少なくて済む
など思いつく。が、いずれも本質ではない。本質はズバリ。
コンピュータ言語は習得に時間がかかる。なので、普及するためには、あえて習い直したいような価値すなわち応用が存在するか。
につきる。これが、彼がくれた卓見である。

Rubyは、オブジェクト指向を取り入れたり、webの記述に使える、記述がシンプルであるなどの特徴を持つ。が、普及した最大の理由は、大手の楽天が、積極的に採用し、このユーザが増えたからだと思われる。

インタビュー:[楽天]Ruby活用事例とROMA,Fairy 
http://gihyo.jp/dev/column/01/prog/2010/030801
「2006年よりRubyに対する取り組みをスタートさせ」

楽天版MapReduce・HadoopはRubyを活用 2008/12/01
http://www.atmarkit.co.jp/news/200812/01/rakuten.html
などにある。

コンピュータ言語は、オブジェクト指向などの新アイディアは出てきているものの、強い型制約(たとえば、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があったからだ」、という人が居るのに似ている。

もちろん、画期的なアイディアで、従来できなかったことができるようになるとか、プログラミング自体が圧倒的に簡単になる。ないしは、バグが入らなくなる。など、飛躍的な進化があれば、それは、「習い直したいような価値」や、「新たな応用」を生むことになる。

たとえば)
まつもとゆきひろ氏は、上記コードの世界の中で、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.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」から自分の名に変更した。ということである。
blog comments powered by Disqus