はてなブックマーク

アメリカではコンピュータサイエンスに長けた人が経営を行っている例が目立つよなぁと思っていた。ちょっと思いついたものをリストアップしてみた。 エリック・シュミット Googleの元CEOで現会長。UCバークレーで電子工学・コンピュータサイエンスの博士号を取得。コンパイラを書くときに使われるLexのオリジナル作者の一人としてコンピュータサイエンスの歴史に名を刻んでいる（論文）。1990年台後半にNovellの社長を務めたあと、2001年から2011年までGoogleの社長を務める。総資産83億ドル（1兆円）で、創業者でもなくこれだけの財を成した人物は珍しい。社長をできる人物を探していたラリー・ページとサーゲイ・ブリンを感銘させてCEOとして雇われたらしいが、確かに彼は話がいちいち説得力があって面白い。趣味としてパイロット免許も持っている。 ビル・ゲイツ マイクロソフトの共同創業者で、1995年

仕事としてプログラミングをしていると、ときどき、どう見てもダメなコードを扱わないといけないことがある。そういうコードでも動いている以上はそれなりの価値を提供しているわけだけど、ときどき触るのすら嫌悪感を感じるようなものがある。 なぜ嫌悪感を感じるのかといえば、自分で最低限だと思っている想定すら守られていないからだ。常識の通じない人たちの書いたコードには身の毛もよだつような何かがある。 コーディングスタイルが統一されていない インデントが狂っている 到達不能なデッドコードがたくさんある 無意味なコメントやコメントアウトされたコードがある コメントの文章が文章としておかしい コピペの繰り返しがたくさんある ネストが恐ろしく深い 関数が絶望的に長い 無意味に複雑 こういったコードを触らなくてはいけなくなったとき、そのままで編集するのはかなり難しい。コードの内容以前に、不自然な部分でいちいち引っか

Goのコードを読んでいると変数名がやたらと短いことにすぐ気がつくと思う。c, i, nみたいな1文字変数や、br, wr, errみたいな2〜3文字の変数がいたるところで使われている。これは他の言語、特にJavaみたいな言語と比べるとぱっと見でずいぶん違うところだ。 どうしてこんなに短い変数名でよしとしているの？ という疑問を抱くのはもっともなことだ。でもそれに対しては、なぜそんなに変数名が長くなくてはいけないの？ という質問を返すことになると思う。 Goは、最近では当然のものとして受け止められている（が昔は特にそうでもなかった）「プログラミングの常識」を改めて問い直した言語だ。 たとえば、複雑なクラス階層のあるオブジェクト指向言語機能は、本当にプログラミングを簡単にするのに役立っているのだろうか？ 例外機構はそれが持ち込むややこしさに見合う存在意義があるのだろうか？ ジェネリクスやテンプ

コンパイラなどを作り始めると本来自分が作りたかったわけではないものについてもせっせとコードを書かないといけなくなる。とくに標準ライブラリの貧弱なCで書いているからそうなってしまうんだろうけど、文字列とかハッシュテーブルみたいな基本的なものも自分で書かないといけない。仮に、ライブラリが充実していたとしても、コンパイルする言語の文法の細かいポイントなどは個別に作り込んでいかなくてはいけない。そういうのはただ複雑なだけで、別に何か勉強になるとかそういうものではなく、ただ地道にコードを書いていかないといけないだけのものだ。 こういう話はコンパイラに限ったものではない。なにを作るにしても、自分の最初から作りたいと思っていたところのコードは分量にして1割とか2割とかで、残りはただ単にひたすらガシガシと書いていかないといけないだけのものだったりする。本質的なものではないなら書かずになんとかならないかな？

なにかの機能を実現するためにコードを書いているというのに、そこから脱線して意味不明なコードを書く人たちがいる。汎用性は高いつもりらしいけど無意味に難しいものを作りたがったり、必要がないのに「念のため」に既存の機能を残したがったりする人たちがいる。どうやら柔軟性あるいは汎用性が至上の価値であって、その価値に反するものはなんであれよくないものだと思っている人たちがいるようだ。 そういう考え方は間違っていると思う。 ある機能を実現するにはいろいろな方法がある。プログラマはそのうち一つの方法を選んでそれを実装しなければいけない。機能を実装する前は無限の可能性がありえたが、機能を実装したあとは具体的に実装したこと以外のことはできない。芸術家が大きな大理石のブロックから一つの彫刻を削りだすように、具体化することによってそれ以外のありえた形というのがなくなってしまうが、それは避けられないことだ。全部の可

大昔の話だけど、公共関係のミッションクリティカルなシステムの構築に関わっていたことがあった。止まっても人が死んだりとかはしないけど、それなりの時間止まったりしたら各方面にいろいろ面倒なことになるようなシステムだった。 しかし、そこに導入しようとしていた機器は結構新しいもので、わりと不安定だった。二重化されていたと思うんだけど、頻繁に片方がハングしてしまうというような問題があった。その状態でもう片方もハングすると完全にシステムがダウンしてしまうので、これはなんとかしなければいけないということになった。 そこで誰かが、シリアルポートがついていて、それ経由でコマンドを送ると電源の差込口ごとに電源のオン・オフができる電源タップというのをみつけてきて、それを間に噛ませようという話になった。マシンの状態を監視しておいて、おかしくなったら自動でコンセント抜き差し的なことをして復帰させようというのだ。そし

Javaには結構昔からあって、最近ではC++11に導入され、JavaScriptでも提案されているFutureというものがある。 このFuture、日本語に訳すのなら「未来」ではなく「先物」が正しいのだと思う。英語では未来も先物もどちらもfutureという。まだ存在しない現物の代わりに、未来のある時点で現物を引き渡すことを確約するオブジェクト（あるいは契約）がfuture。同じだよね。

Lispはなんとなくすごそうというイメージがあるけど、実際にはそれほどでもない。90年代位まではGCがあるというだけで、生産性X倍といえたのかもしれないが、いまは良い他の言語がたくさんあって、言語の日常的な使用例で差が特にあるとは思えない。 現代のプログラミングでは充実したライブラリの存在がますます重要になってきている。その点マイナー言語は苦労することが多くて、PythonやJavaでさっさと書けることにすごく時間がかかったりする。プログラミング言語はコンピュータで実行するものであるのと同時に、ほかのプログラマに読んでもらうための文字通りの言語だ。自分でいろいろ作るのも楽しいけど、仕事でどっちを使うかというとみんなが読み書きできて早く終わる方がいい。 プログラマの費やす労力のうちプログラミング言語そのものにかかっているのは一部にすぎない。プログラミング言語は一番目立つ位置にある――字面その

昔はよくわかっていなくて、今は身にしみてよくわかっていることの一つは、追加した行数がマイナスのパッチは素晴らしいということだ。コードは削除できるなら消したいし、自分の書いたコードであれ、誰かが消してくれたらとてもよいことだと思う。 昔はがんばって書いたコードはなるべく「活用」したいと思っていた。活用というのはつまり、捨てるのはなんとなくもったいないから、そのコードをなるべく消さずにすませたいということだ。 しかし無理にコードを生かしておくことの意味など何もない。 コードの履歴などは全部いったん置いておいて、ある時点のソースコードを初めて見たものとしよう。そのソースコードが、そのプログラムが実装するべき機能を実装するために十分かつ最小限のコードであるのと、十分かつ最小限のコードに加えて何かよくわからないコードのどちらかであるとしたら、どちらのほうがいいコードだと思うだろうか？ 前者のほうがい

スタンフォード大学の社会人オンラインコースを始めてみることにした。Stanford Center for Professional Development (SCPD)というプログラムで、一応受験資格のようなものはあるものの、それなりの会社で専門職をやっていれば基本的には誰でも受けられる授業であるようだ。正直コンピュータサイエンスなどは自分で本を読めばだいたい何でも勉強できるのだけど、ちょっとこういうやり方も試してみようかと思って始めてみた。 とりあえず自分の専門に関係があるものとして、プログラムの解析と最適化（Program Analysis and Optimization）のコースCS243を受けてみることにした。コンパイラにおけるデータフロー解析とかそういう話。 授業料は意外と高い。協賛がなければ$5500、社割で$4500。僕の会社の場合は授業料のサポートがあるので実質負担はそれ

いま僕は働いてみたいと思っていた会社で、アメリカにきて、コンパイラ・ツールチェーンチームの一員として仕事をしているのだけど、なんとなく入社して、なんとなくチームを移ってここにきて、なんだかよくわからない流れで仕事をしているという感覚がある。周りの人は、人によるけどガチのコンパイラエンジニアだったりするのだが、僕はそこまでの専門性はないと思う。 実際のところは自分の仕事は問題なくできているので、僕のスキルでも十分に通用するようだ。僕はプログラミングには時間を使いまくったので、他の人よりできるのは当然なのだが、しかしそれにしても通用しすぎだ。いまのポジションは偶然何かのはずみでこうなっているだけで、本来は何か違うのではないかという感覚がある。 こういう感覚のことをインポスター症候群というらしい（imposter = なりすまし）。 これが何なのかということを考えてみたが、僕は自分のことを基本的

一番最初に僕がプログラミングをしてみたいと思ったのはコンピュータを手にする前からだったと思う。 あるとき小学校高学年の頃に読んでいた子供向けの雑誌の巻末に、巡回セールスマン問題のような懸賞問題が載っていて、最高得点を出した読者に景品が当たるなどというものをみて、それを手でひたすら試行していた。それを見た親が「これはコンピュータでバーッと計算するんじゃないか」みたいなことを言った。そのとき、そうか、こういうのはコンピュータを使えば手でやらなくていいんだ、機械的にパターンを試していくだけなんだからな、と思ったのだった。 その懸賞には相当時間を費やしたのだけど、結局景品はもらえなかった。当然だれかがプログラムを書いて、僕の手で求めた解よりよい解を一瞬で見つけてしまったんだろう（しかし僕は今でも、人間がやるかコンピュータでやるか微妙なくらいの問題をひたすら手でやるのはなぜかかなり好きではある）。

設定ファイルが下手に高機能すぎて、それに頼りすぎた結果、運用環境が非常に難解になってしまうことがある。そういう設定ファイル地獄のようなシステムができてしまう理由は、開発しているプログラマのレベルが低いからというのではなく（それもないわけではないと思うが）、いくつか他の構造的な理由があると思う。 柔軟性が無条件に良いものだと思っているから ―― コードを変更せずに設定ファイルでカスタマイズできるならそっちのほうがいい設計に決まってるよ、という思い込みのある人が多い。実際には、ベタに書けば簡単なものを設定に出すと複雑になることが多いから、これは事実ではないのだけど。 バイナリのアップデートが面倒だから ―― 運用ポリシーによっては、バイナリの更新はオオゴトだけど設定変更は通常作業みたいな環境がある。そういう環境では、設定にできるだけ多くのものを追い出してインストール後の柔軟性を最大化しようとい

これを一部でシェアしたのは2014年なので結構前ですが、エンジニアのキャリアパスを考えるにあたって参考になるかと思って公開します。あくまで個人的な体験談で会社の見解などとは関係ないということに注意してください。 -------- 入社日記念の無料マッサージクーポンのメールを受け取って気づいたんだけど、こないだで入社後7年が経過したらしい。僕は結構長い期間をここで過ごしたことになるんだなと思った。ちょっと以前のことを振り返ってみようと思う。言うまでもないけどこれは僕の書ける範囲での個人的な感想と体験談であって会社の見解等を表しているものではない。 きっかけ そもそも最初は2007年にGoogle Japanのリクルーターからメールをもらったのがきっかけだった。Google Japanの知り合いから紹介で誘いがきて、「お、これは引き抜きってことかな？」と思ってよろこんで話を聞きに行ったのだった

「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう（そういう人は結構たくさんいる）。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん

僕はプログラマをしていて、数千万行以上の規模で10億ユーザ以上が使うようなプログラムの開発にもかかわっていたりしたけど、そういう仕事環境で「（ある何かが）オブジェクト指向かどうか」という議論をほとんどしたことがない。デザインのレビューでもAPIが十分シンプルかどうか議論にはなるけど、そのやり方がオブジェクト指向かどうかなどという観点でものを見る人はいなかった。日頃のコードレビューでも、やるべきことが普通にわかりやすく行われているかという観点でコードを見るのが普通で、オブジェクト指向ではどう、ということをいう人はいなかった。 一方でプログラミングの入門書などをみると「オブジェクト指向とはなにか」という説明に多くの分量が割かれていて、オブジェクト指向というものが、なにかまるである時点で悟りを開くように理解すべきものであるかのような解説がなされていることがよくある。しかもその解説が哺乳類と犬と猫