「それでいいのかなぁ？」と思うのよ。
まつもと ひろゆき氏はきっと賢くて、いい人なんだと思う。
この理念は素敵だと思う。
はじめてプログラミングしたのがシャープのポケコンってところも素敵だ。私も持ってた。
が、現場を知らないなぁ、とも思う。以下、３つの点で、まつもとさんのおっしゃることは実用プログラムの世界では危険だな、、と思う。
ひとつめ。
今、底辺プログラマーの年収って５００万円切ってたりする。こうなってしまったのは、いわゆる大手システム・インテグレーターっていうゼネコンの元請けが価格のダンピング競争にあけくれ、現実にモノを作る人ば中国やインドになったせいだと思う。億円単位のプロジェクトなら、そういう単価引き下げはあるが、それを数百万円レベルのプロジェクトにも適用するから、こんな話になってしまった。
この年収ってOLより安かったりする。つまり、技術料は無料。今、ITの現場で起きてることは、技術者といいながら技術に金は払われていないのです。そんな中で技術を磨こうとか、いいもの作ろうなんて無理。みんな責任回避型の仕事しかできないのが現実です。
Ruby? オブジェクト指向? よりよいもの？放っとけ。とにかく動くものをとっとと作らんかい。というブルーカラーの世界なのです。
ふたつめ。
プログラマーが楽しくなる、ってことは、どんどんハードウェアであるコンピューターから離れていくってことなんです。いわゆる抽象化が進むと現実から乖離していく、ってことですね。
ちょっと前ですが、お客のところで働いているエンジニアに真顔でこんな質問されたことあります。「１億件のレコード読み込んだら、システムが止まるんですよ。バグレポートあげたほうがいいですか？」32ビットコンピュータがもつメモリー空間は２Gバイトって２０億バイト。レコードがたった20バイトだなんてないから、止まって当たり前。
こんなのもあった。16ケタの計算していて、最後のケタが狂う、と烈火のごとく怒るシステムインテグレータ。コンピュータ内部では一般的に計算は２進数で行われる。ケタが多いと浮動小数点演算として扱われ、IEE754という標準的なやり方で計算し、標準的にケタ落ちする。こういう限界を知らないで、バグだと騒ぐのが、今時の現場の「プロ」。
もっとも私が計量経済学がスタートでFortranで計算しケタ落ちについては極めて初心者のころから教授に教え込まれたので、あまりに当たり前になっているせいかもしれないけど。
抽象化ってこんなことすらわからなくしてしまうってこと。機械の特性を無視したプログラミングを許すことは、あんまりいいことだと思わない。
みっつめ。
Rubyを有名にしたものに、Ruby on Railsっていうフレームワークがある。Rubyの考えをさらに進め、データベースの扱いやWEB画面の作り方を簡単にできるようにしたといっていいかも知れない。でも、Ruby on Railsで作ったアプリケーションって、デバッグのしようがない。トラブルが起きてもどこでどうなっているのかわからない。
理由は単純で、言語、フレームワーク、自分で作った部分の境界がはっきりしないから。人間の世界でいう「責任分解点」がよくわからない。人間の世界と同様に、境界があいまいだと、協力しやすい、ってことは起きるけれど、いざ問題が起きると、誰がやるべきことなのかがわからなくなる。
ネットワークなどでレイヤーとか階層という考え方がある。現実世界でわかりやすいのは封筒。書類を封筒にいれ、どこかに送るのであれば封筒という単位で送る。海外に送りたいのなら、同じ方面の封筒を集め、さらに大きい封筒に入れて送る。到着したほうでは順次、封筒から取り出していく。
この方法だと問題の起きた点がはっきりする。
こう考えると、「開発者に優しい」ことが、「放蕩息子を甘やかす」になってしまってはロクでもないことが起きるように思えてならないのですけど。
例えば、シンプルにかければいいのであれば、以前、紹介したAPLってプログラムでは100の階乗は、
!100
でいい。
極限まで簡単に書くと、プログラミング言語はパズル化するってことはすでにわかっている。
まつもとさんだってご存知のはず。
まつもとさんが追求している道って、日本で情報処理学会がIT産業と乖離していった道に思えてならないのです。もう少し、現実との相談が必要なのではないでしょうか。
