Hatena::ブログ(Diary)

naoyaのはてなダイアリー

May 18, 2005

僕やはてながPerlを選ぶ理由

ご存知の通り、はてなのシステムはほぼすべてPerlで書かれています。そもそも僕がはてなに入った一つの理由に、僕が一番得意とする言語であるPerlを使ってシステムを構築していたという点があったりします。

世の中にはたくさんのプログラミング言語があります。Perl、Java、Ruby、PHP、Python、C、C++、lisp、Smalltalk、Cobol...数え上げたらキリがありません。そして、プログラマはかならずと言っていいほど、どれかひとつ以上の言語を愛しています。好き、ではなく愛しているのです。

自分が愛しているものを批判されると感情的になりやすいのは人の常、プログラミング言語の差異に関する議論は炎上しがちで、よく宗教戦争だなんて言われたりもします。その中で、言語なんてどれも一緒だなんていう乱暴なまとめがされることもよくあったりします。

しかし、何年かプログラマというものを経験して、はっきりわかったことがあります。プログラミング言語がどれも一緒だなんていうことは間違っているということです。そして僕は、数ある選択肢の中から Perl というプログラミング言語を選択しました。

C言語、Java や Ruby、Python などに触れたこともあります。こと Java に関しては、昨今のウェブアプリケーション開発のベストプラクティスと言われていることもあり、書籍も結構な数を読んだし、それである程度の物を開発した経験もあり資格を持っていたりもします。それでもなお Perl という言語に拘るのは、大きな違いがあると認識して、自分に最適なものはこれだと確信しているからです。

ハッカーと画家 コンピュータ時代の創造者たち』の著者であり天才的なハッカーであるポール・グラハムはその書籍の中で静的型付けの言語とそうでない言語を比較しながらこんなことを書いています。

自分(ポール・グラハム)は大学で、プログラムは紙の上で完全に理解しなければいけないと学んだけれど、それは無理だった。おもむろにめちゃくちゃなコードを書き始めて、それを次第に形にしていくというやり方が好きだとあります。「デバッグとは書き間違いや見逃しを捕まえる最終段階の工程だと教わったけれど、実際に私がやっていたのは、プログラミングそのものがデバッグという具合だった。」と。

それと同時に、当初ポール・グラハムは、自分が世間一般で良いとされている方法論で物を作ることができないことに引け目すら感じていたのだともあります。

実は、このポール・グラハムが感じていた引け目というのと同じ類ものを、僕もずっと感じ続けていました。僕がこれまで読んできた多くの技術書には、プログラミングは詳細に設計された設計書を実際の形に落とし込むための手段に過ぎないとか、オブジェクト指向開発においてはコーディング作業は全体の中で占める20%の作業にも満たないとか、そんなことが書いてありました。一時はそれを正しいと思って、実践しようと思い試行錯誤を試みたものでした。

でもなんだかうまくできませんでした。僕がプログラミング言語を使わずに考え出したソフトウェアというのは、綺麗に設計されているようで、実際に作り出してみるとまったくその通りにいかない。あそこがおかしい、ここがおかしい。紙の上の設計に後戻りしては設計書の間違いを訂正するのです。なんでだろう、本にあったとうりにやっているのに! そのときは、僕にはソフトウェアを綺麗に設計する才能がないんだろうと思い込んでいました。

しかし、経験を積んでいく中で、そのやり方が自分に向いていないこと、自分に向いてるのはプログラミング言語を使いながらプログラムを考えることだというのが分かってきました。また、プログラミングをしている最中により良いアイディアが思い浮かぶということが何度もあり、次第にそれはプログラミングをしているからこそ思いつくことなのだということもよく分かってきました。紙の上では決して思いつかないようなアイディアが、プログラミング作業を通じて驚くほど自然に生まれてくるのです。

でも世間一般的には、それは間違ったやり方なんだろうなと思い、引け目を感じていました。

もうひとつ僕が引け目を感じていた原因として、ソフトウェア工学というものを学んだことがないというのもありました。僕は大学で物理を専攻していたこともあって、いわゆるソフトウェア開発の方法論やアルゴリズムといったものをまともに勉強したことがありません。

そんなこともあって、思った物とか面白い物は作れるんだけど、コードを書いては試して書いては試してを繰り返してめちゃめちゃに進んでいく僕のやり方は人とは違うんだなあといつも感じていたのです。なので、僕が書いたモジュールの CVS のりビジョンは、やたらとリビジョンナンバーが進んでいたりするのです。作っては実際に動かして、壊して、というのをやたらといっぱいやるから。

そんな僕の物作りの過程においては、コンパイラにやたらと怒られたり、変数の型を気にしたり、変数に入れるオブジェクトが何者だったりするかをいちいち意識しなければならない静的型付けの言語は性に合わなかったんですね。一方で簡単なことは簡単に、難しいことでもそれなりにできる Perl という言語は、僕のやり方に合っていたし、なんとなく"Hackしている"という気分にも浸ることができたんです。

だってそうでしょう、"Hello, World!" を出力するのに、コマンドラインから一行書くだけで済む言語と、パッケージを選んでクラス用意して何行も書いてコンパイルして、やっと実行できる言語とで、作っては壊していくのに向いているのがどっちかなんてのは、さすがに書籍に頼らなくても分かるでしょう。

そんな感じで僕なりのやり方だけど間違ってるんだろうなあ...と思いながら悶々としていたのですが、優秀なハッカーのひとたちに会ったり、はてなでの開発を知ったら、なんとみんな同じようなことをしてたんですね。そんなわけで徐々にそれは間違ったことではないという風に考えられるようになりました。むしろ、いままで正しいと思っていた方法の方が間違いなんじゃないかと思うことすらあるほどです。

ポール・グラハムもこう言っています。*1

静的片付けは、私が大学で教わったようにプログラムするなら良い考え方だと思う。でも私の知るハッカーたちはそんなふうにはプログラムしない。私たちに必要なのは、落書きしたりぼかしたり塗りつぶしたりできる言語であって、型の紅茶茶碗を膝に置いて、落とさないようにバランスをとりながら、作法にうるさいコンパイラおばさんとお上品な会話をするような言語じゃない。(『ハッカーと画家』 第2章 ハッカーと画家 P.26 より)

近頃では、プログラミング言語売り場の棚にずらりと並んでいるのは、いつも決まって Java の本ですし、名著と言われるのはお上品な方法論を解説した分厚い書籍だったりします。別に Java がだめだと言っているわけではなく、僕も Java は素晴らしい言語だと思っています。Javaとその周辺の技術が市場やこの業界にもたらした数々の方法論の多くは、他の言語でも応用することができますし、その功績は非常に大きいと思います。

しかし、独創的なソフトウェアを"創りながら創る"という方法においては静的型付けの言語よりも動的型付けの言語の方が有利だと思うし、スーツを着て設計書を書いてからものを作るなんて作業は、今の僕には耐え難い作業です。もう後戻りはできなそうです。だから、賢そうなおじさんが(PerlやPHPなんかを使っていた会社がJavaを採用したなんていうニュースをみて)「Javaはいい」とか言っているのを見ると、「ほんとに分かって言ってるのかな」という一言が、いつも脳裏をかすめます。

これから先、Perl でアジャイルに物を作る会社が続々と増えるなんてことはあり得ないでしょう。でも、はてなという会社はそれが正しい方法論だと確信しているし、僕らは、頭でっかちの設計屋が何日もかけて設計するようなやり方よりも、よっぽど優れたやり方でやっていると思っています。

またハッカーと画家の話に戻りますが、ポール・グラハムがかつて全精力を注いだ Viaweb というベンチャー企業は、lisp を使ってウェブアプリケーションを作っていたそうです。多くのプログラマは、lisp でウェブアプリケーションだなんて奇妙なことをするよなあ、なんて思うはずです。しかし Viaweb という集団は、lisp によるアジャイル開発で他の大企業の何倍ものスピードで物を作ることを知っていたし、自分たちしか知らない正しい方法を、他の企業が鼻で笑っているという状況は競争社会においては非常に有利なことだったと振り返っています。

そんなわけで、はてなという会社はこれから先も僕らなりのやり方でやっていくし、たとえ周囲の人たちから笑われたとしても、それを曲げることはしなくてよいだろうな、と思うこのごろです。

ハッカーと画家 コンピュータ時代の創造者たち

ハッカーと画家 コンピュータ時代の創造者たち

気になる君気になる君 2005/05/20 02:41 静的片付け → 静的型付け

気になる君2気になる君2 2005/05/24 11:40 「とうり」→「とおり」「通り」
某大手IT企業でもアジャイル開発に関心のある人は多いようで、関連する社内セミナーは非常で盛況でしたです。時代は徐々にそちらの方向に向かっているよーに思うので、笑われるとかということ自体気にしなくてもいいんじゃないかな。

みかんみかん 2005/05/27 06:38 読んでてプログラミングって何だか人生に近いかも、って思いました。
「大げさな!」って笑われそうですが、綿密に計画(=設計書)を練って行動(=プログラム)しても、自分が正しいとか普通だとか思っていたこと(=きまり、文法)がくつがえされることってあるんですよね。
「うまく行くと思ったのに、なんで無理なんだよ」なんて言ったところで何も変わらないし、だからみんな試行錯誤して臨機応変にやっていく。プログラミングの作業がそれに似てるのは、ごく自然なことなんじゃないかと思います。紙と鉛筆だけでCPU作っちゃった日本人もいたらしいですが(笑)、私もトライアンドエラーが性に合いますね、やっぱり

さくらいろさくらいろ 2005/05/28 18:46 言語というよりコンパイラかインタープリタの違いでしょ。

>独創的なソフトウェアを”創りながら創る”という方法においては静的型付けの言語よりも動的型付けの言語の方が有利だと思うし、

多分面倒臭いだからでしょ。簡単なものなら手軽な言語が一番楽なのは確か。

しかし何で独創的なって付けるかな。(笑)

弾 2005/06/02 13:41 またもやTBはじかれたのでURI

http://blog.livedoor.jp/dankogai/archives/21738544.html

snakajimasnakajima 2005/06/05 15:40  プログラミング・スタイルに関しては、私も全く同感です。アーキテクチャ・レベルの話ならいざ知らず、細かな設計仕様書なんて書いてプログラムを書いたところで、結局プログラムを書き始めれば設計の変更はいたるところに生じるので、結局あっというまに設計仕様所は古くて役にたたないものになってしまいます。私が過去に関わったプロジェクトは全て、詳細設計書なしで作りました。

rozroz 2005/12/13 15:31 内容を読んでいてますますphpを薦めたくなるのはわたしだけか。
perlをやっている人たちはphpをやったら負けだと思っていると聞いたことがあるけれどそれは本当なのか。
わたしももとはperlを愛していた人間だが今はperlが面倒で嫌いになるほどphpを愛している。
すてきな言語なんですがね。

perlも良いところは本当に良いのだけど。
後からソースを追った時の明快さという点で。
どっちがいいかというと・・・。

7777 2007/04/23 07:26 perlでウォーターフォール型開発をしてるところもあるかもしれませんし(たぶん結構あると思う)言語の問題ではないのではないかと。
動的型付けでも変数の状態を把握できる人はいいのですが それで痛い目を何度も味わっていると間違いを起こさない処理系のほうが好ましく思える場合があります。私が(愛してはいないけど)使ってる処理系は動的も静的も選べますが たいてい静的型付けを使っています。ちょこちょこっと実験的なプログラムを書く際に変数定義してことなど 理解不明のバグに悩まされることを思えば なんの苦でもありません。
PerlやLispのコードを瞬時に構造的に理解できるような才覚のない人にはブロックやモジュールがはっきりわかる言語のほうがよいでしょう。
また多くの言語を使ってみて自分にあったものを見つけられる人というのもごく少数だと思います。
頭のいい人が使いやすい言語とそうでない人でも使える言語っていう違いはあるかもしれませんね。本物のプログラマはFortranで人工知能を研究するといいますが 頭のいい人の選択が万人に適用できるわけでもないというのは認識しておいたほうがいいかと。
Javaなんて あらゆる痛い目を見た人たちの集合知で支えられているような言語だと思います。普通の人にはそっちのほうが無難です。一輪車と補助輪付き自転車みたいなもんですね。

名無し名無し 2007/04/23 14:38 プロトタイピングや小規模な開発に向くのはインタプリタ系ということを知らない年寄りがうちの社にもいます。

どの言語が適しているかはいろいろな要因、たとえば開発スピードを求めるのか、要求仕様通りに堅く作っていくのか、仕事の内容次第でしょう。

パッケージ云々はHelloWorld程度なら言うとおりなんだけど、ちょっとしたアプリを組みだしゃPerlだってモジュールが数珠繋ぎに必要になるので微妙

個人的にはインタプリタ系はソースと実行形がバラバラにならない所が好き(Perlに限らないけど)

と適当にだらだら書いてみる

eigokuneigokun 2007/08/12 10:32 私も本当にそう思います。プログラミングに限らず、コンピュータというものは頭で考えるというよりも、体感するものだと思います。
はてなのような学びながら成長するタイプの企業にとっては、Javaのような綺麗な言語よりもPerlの泥臭さの方がよいですよね。私はCが好きですが・・・。

VSTLINKVSTLINK 2008/07/17 21:31 コメント読まずにコメント。

アジャイル性を求めてLWPL(スクリプト/インタプリター系言語)を選択するというのはよく判るけれど、
バグと不具合と統一性のない仕様だらけの「はてな」の現状を見ると、
Think differentしろよって言いたくなる。

PerlとかPHPってさ、変数の型管理が弱い言語だから、ランタイムエラーでまくるんだよな。
俺もJavaアプリのプロトタイプを最初Javaで書いて、次にPerlでクラスライブラリ全て書き下して(当時はCPANにはろくなライブラリが揃ってなかった)、最後にJavaで開発にとりかかった事あるけど。
Perlはプログラマの質によって
質の低いコード(COBOLer系の何でも一から順番に書いて、ライブラリなんてろくすっぽ使わないダメコード)も、
質の高いコード(LISPチックに動的に複雑なデータ構造を駆使しながら、Javaっぽい型安全性を確保した高度なクラスライブラリ)も、
どっちでも書けちゃうんだよね。
で、汚いコード書く奴に限って、糞みたいなスクリプトを延々修正し続けて、つまらないバグ入れ込んだり、つまらない機能追加で大騒ぎしたり、それを「Hack」とか仰々しい名前で呼んだり・・・。

本当に「Hack」と読んで欲しいなら、せめてLispかC++で書けよって気がする。

VSTLINKVSTLINK 2008/07/17 21:36 追伸:LWPLブーム(死語)に乗っかって「LWPLでERP開発しました」みたいな話を聞くと、「COBOLerにJavaもがきさせるよりはよっぽどマシだけど、『本当の所、判ってんのかな』」っていつも思ってました。

VSTLINKVSTLINK 2009/05/09 16:52 型付けについていろいろな考え方の方が居られるのは結構な話ですし、
私自身 学生時代は物理の傍ら Lisp にはまっておりましたので
naoyaさんのおっしゃる「動的型付け」に対する愛着も理解できるつもりです。

しかし Hatenaの諸サービスを Product Line として見た場合、
サービス間の仕様の齟齬(例えば相互連携可能性の欠如)や、
概念/操作手順/UIのバラバラさ加減 には目に余るものがあり、
新規ユーザの目で見ると 恣意的で一貫性のない約束事だらけでとっつきにくく、
また日々Hatenaを使うようになったユーザにとっても
一貫性がなく連携の難しいサービスに日々苦痛を感じさせる
ものとなっているように見えます。

複数のサービスの仕様に互換性を持たせたり、
概念(や 操作手順/UI)に共通性/連続性を持たせるためには
個々のサービスをバラバラに作って放置するのではなく
折を見てサービスの再設計を試み、複数のサービス間にまたがる共通概念を抽出し、
共通のクラスライブラリや設計指針を抽出するという作業が必要です。

naoyaさんの否定的な比喩
「頭でっかちの設計屋が何日もかけて設計するようなやり方」
「スーツを着て設計書を書いてからものを作るなんて作業」
が、上記の当たり前なブラッシュアップ作業まで否定するものではない事を希望します。
(というか、最近の若手にありがちなスピード重視品質軽視にもかかわらず、
 Googleのサービスは品質高いでしょ。考える事を放棄しちゃダメだよ。)

といったわけで、Hatenaを初めて見た日から直感的におかしいと感じ続けている
「サービス間の分類カテゴリの共通化」について、「はてなアイデア」に提案を出しました。
諸事情でコメントの投稿が遅れておりましたが、ご検討をよろしくお願い致します。

    idea:23563

naoyanaoya 2009/05/09 21:48 ありがとうございます。

改善できるよう頑張ります。

d0id0i 2010/09/06 16:36 Cでもエイヤで書いたり設計変更したりしますけどねぇ。違う種類の制約があることは事実ですが、コンパイラだからと言って「独創的なコード」が書けない、ということはないと思います。

単に対象とするアプリケーションドメインの差と、言語に対する習熟度の差ではないかと。愛、と言い換えても良いですが。

トラックバック - http://d.hatena.ne.jp/naoya/20050518/1116425594