プログラマーとしての日記 -30ページ目

「闘うプログラマー[新装版] ビル・ゲイツの野望を担った男達」を読んで

ビル・ゲイツはあんまり出てきません。
Windows NTを作ったデビット・カトラーたちの伝記。

技術者はあまり見るべきではない本、なのかもしれません。
徹夜したくなりますし。
徹夜はよくない。生産性が下がる。

実際のところ、
奥さんに捨てられたり、燃え尽き症候群になって一年間会社でゲームばかりしていて首になった人、
なんて話も出てきます。

ストックオプションで、多くの社員が富豪になれるようなマイクロソフトならそれもデメリットにはならないのかもしれませんが。
一般的な技術者は見習った身を滅ぼします。

が、そういう総論ではなく各論的に見るならば。
よい話がたくさん載っている本です。

個性の強い人たちが集まってチームワークを組んでいたり。
テストが大切であったり。
信念をもって正しい設計を行ったり。

マイクロソフトにドックフードを食べる風習があること、
つまり、自分たちが作ったソフトを使ってみることは有名ですが。
まさかアルファ版にもなっていないOSを開発とビルドに使っているほどだとは。
よいものを作るときにはそれほどの信念がいるのですね。

最後の最後で見つかったバグを、
みんなが徹夜でとるところなどは確かに感動的ではあります。
素直に感動しておきましょう。

などなど。
出てくる価値観などが古いことをフィルターをかけてみることができるなら、
やっぱり読んでみるべき本ではありますね。

「AR-拡張現実」を読んで

最近セカイカメラなどで注目されているARについて解説した本。

原理とかよりマーケティング面あたりを重視して書いた本のようです。

実際のところ、ARは見た目は大変未来的な技術ですが、
利用する技術そのものは大したものは必要としません。

基本は動画と３Dオブジェクトを重ねて表示するだけです。
すでに非常に当たり前に使える技術ですね。
あとマーカーの認識と加速度センサーなんかも使えたほうがよいですが、
これも大した技術というほどのものではありません。

コンテンツさえ揃えればすぐにでも普及する技術です。
実際、この本に紹介されているエヴァンゲリオンのARなんかは３週間で実現にこぎつけたそうですし、
ほかの例についてもそんなにコストがかかりそうなものはありません。

インターネット普及時に、
ブラウザがあっという間に普及して、
あとはみんながホームページを作ればいい、
という状況にすら似ていると言っていいでしょう。

まだ、技術のないデザイナーが簡単に作れるという域には達していないので、
技術者としてはもうちょっと頑張ることがあるかとも思いますが、
もうちょっとですね。

あとは魅力的なコンテンツがそろうかどうかです。
もし大衆に受けるようなものが出てくれば、あっという間に普及するでしょう。

未来は常に目の前にあるものですね。

「コンピュータが仕事を奪う」を読んで

現在コンピュータにできることできないこと、
そして近々できそうなことなどについて書いた本です。

またその関連で数学の話なんかも書いてあります。

コンピュータの処理能力はどんどん上がっています。
今までできなかったことがどんどんできるようになる。

コンピュータに任せておいたほうがよいことを人間が頑張ってやっても、
それは自己満足にしかなりません。

だから、今後自分がどういう仕事をしていくかを考えるうえで、
コンピュータの動向は押さえておかなければならない知識となります。

コンピュータにできることは、量的には増えていますが、
できることの種類はそんなに変わっていません。
量が増えることによってたまに新しい種類が増える程度です。
だから人間がやらねばならない仕事は、当面なくならなそうです。
そういう仕事をできるように人生計画を立てていかねばならないでしょう。

しかし、この本を読んで知りましたが、
最近またできることの種類が増えているようです。
翻訳なんかは近いうちにかなりできるようになるらしい。
そういう勘と経験的なものが必要な分野も、
大量のデータ投入とそれ用のアルゴリズムの採用によって、
可能になっているようですね。
たまに種類も増えるので油断がなりません。

そういう分野はいずれコンピュータに任せることができる前提にしておかねばなりませんね。

インターフェースの試行錯誤

汎用パーサーのインターフェースをじっくり考え中。

Perl6やboost::spiritのような同種のインターフェースでプログラムを組んでみたところ、
Perl6はよくわからない実行時エラーが多いところが使いにくく、
boost::spiritはよくわからないコンパイルエラーが多くて使いにくい印象でした。

C#4.0は強い静的型付けをもつ言語ですが、動的型付けにも対応しています。
これでよいとこどりになるようなインターフェースができないか考慮中。

また、静的型付けについても内部的にはC++より融通が利くため、
boost::spiritより良いものができるように頑張っています。
そこもC#4.0の新機能である共変性と反変性を利用することになり、
少なくとも練習にはなっています。
正しい利用方法なのかどうも自信がないのがなんですが。

まあ両方とも相手がすごいので、
客観的に見れば考慮の深さではかなわない可能性が高いですが。
少なくとも自分には一番使いやすいインターフェースくらいは目指したいものです。

ということで完成は急がずにじっくりと進めていきます。

「Mastermind of Programming」を読んで最後に

全体を通して、

私は言語設計はやったことはありませんし、今後もやることは無いでしょう。
が、昨今のライブラリＡＰＩの設計は、言語設計に近い思考が必要とされるレベルになっていると思われます。
また、その設計は言語と深く整合性が取れていないといけない。

それを成し遂げるためには、言語設計者が何を考えて選択をしているのか。
それを深いレベルで理解することが必要となります。

そのために、非常に役立った本でした。

「Mastermind of Programming」を読んで 18(Ruby)

18章はRubyを設計したまつもとゆきひろさんのインタビュー。

これまでの言語設計者の話を見ていると、
数学的な美しさにこだわっている人が多いようです。
が、まつもとゆきひろさんは、ほとんどこだわっていないみたいですね。
ラリー・ウォールさんもそうでしたが、それ以上です。
かなり珍しいとおもいます。

その代わりこだわっているのは、気持ちよくプログラミングできること、だそうで。

実際のＲｕｂｙの評判も合わせて考えると、
これによって表されていることは数学のシンプルさとかなり共通点があると思います。
他の言語の作者が数学を用いて達成しようとしているものと近い。

ただ、数学のシンプルさが論理に最適化されているのに対して、
Ｒｕｂｙのシンプルさは人間の脳に最適化されているのでしょう。
似たような方向性ではありますが、より人間に使いやすいものになっている。

それを突き詰めた言語が広まってきているということはすばらしいことですね。
今後もこういう言語設計者が増えていくと、プログラミング環境はよくなっていくのでしょう。
そうなってもらいたいものです。

「Mastermind of Programming」を読んで 17(Eiffel)

17章はEiffelを設計したバートラント・メイヤーさんのインタビュー。

Eiffelは主流とはいえないまでも結構広く普及しているようで、
その実用的な価値は疑うことはできないでしょう。

なんですが、インタビューからはそれを生むにいたった理念があまり読み取れませんでした。
残念です。

一般論としてはいいことも言っているのですが、
Eiffelに関すること、特に他言語との比較の話を振られると、
他の言語とは比較にならないほど進歩的だとか、
Eiffel以外の言語を使ってどうやってプログラミングをすればいいのかわからないとか、
そういうことしか言ってないのです。

それで納得できるのは本人とシンパだけですな。

Eiffelの実績がなければ、トンデモ言語じゃないかと読み取れるようなインタビューで、
ちょっと残念でしたね。

自動テストを制約から全自動で生成できるとか言われても。
それができるなら、論理的にはコードも全自動で生成できそうなもの。
なんか齟齬があるのでしょうが、伝わってないことは確かのようです。

「Mastermind of Programming」を読んで 16(PostScript)

16章はPostScriptを設計したチャールズ・ゲシキさん、ジョン・ワーノックさんのインタビュー。

この人たちも、言語設計者というよりむしろAdobeを率いてきた人たち、と位置付けたほうがよいでしょうか。
PostScriptは言語としてはForceと同じくスタックベースであることなどが特徴として挙げられるようですが、
その辺の言語機能にはあまりこだわりはなさそうです。

それよりも、実際の成果のほうが重要だと思っているようですね。
PostScriptは電子印刷の品質を一気に利用可能なところまで押し上げたそうです。
その後ディスプレイでの表示も一部機種で管理することに成功し、
今ではFlash Airでインターネット上に高品質の表示を行うことを目指しているようです。
大変一貫していますね。

成果ベースの評価をしている人はこの本では少ないようですが、
これはこれで参考になる話でした。

「Mastermind of Programming」を読んで 15(Perl)

15章はPerlを設計したラリー・ウォールさんのインタビュー。

言語設計者というと、数学的に考えてその成果として言語設計をする人が多いです。
マーケティングも考えている人もいますが。

その中で、このラリー・ウォールさんは、言語学者的な観点で言語を設計したとのこと。

自然言語の使いやすさを達成するために、
Perlに取り入れようとした自然言語の性質を最初に列挙してあり。
ちょっと感動しました。

まあ確かに自然言語はいろんな表現ができますよねえ。

数学的な美しさではなく、
話すようにかけるプログラムを目指すために必要なことが列挙されています。
そしてPerlはそういう言語です。

多少古いこともあり古い文法もあるわけですが、
その変更Perl6で一気に解消すべく活動中のようです。
後方互換性は捨て、その上１０年以上もかかっているようですが。
これだけ名を挙げて、まだ夢に向かって走っているのは素晴らしいことですね。

「Mastermind of Programming」を読んで 14(UML)

14章はUMLを設計したイヴァー・ヤコブソンさん、ジェームズ・ランボーさん、グラディ・ブーチさんのインタビュー。

この本に書いてある中で、唯一プログラミング言語ではない言語設計者のインタビューです。
設計言語ですね。

やはり立ち位置がほかの人とは少し違う感じがしますね。
きちんと実作業寄りの話もしてはいるのですが。
より大局的な話題が多いように思えます。

大局的な理解をするのに役立つ話は多いですが、
今一つエキサイティングではないですね。

３人でもいろいろな意見があるようですね。
一人はUMLは1の段階であまりよろしくなかったと思っていて、
もう一人は1はよかったけれど2.0は全然だめだと思っていて、
最後の一人は2.0も素晴らしいと思っている、
らしいです。

多様性があるのはよいことだと思いました。