2010/02/14
仕事でLispを使うこと
http://www.google.com/buzz/rui314/St7Z3Wm9ZjJ/
Lispはなんとなくすごそうというイメージがあるけど、実際にはそれほどでもない。90年代くらいまではGCがあるというだけで、生産性X倍といえたのかもしれないが、いまは良い他の言語がたくさんあって、言語の日常的な使用例で差が特にあるとは思えない。
[...(中略)...]
Lispで仕事をしたいというのはいいけど、それが極端になってLispでしか仕事をしたくないとかJavaは書きたくないというと、なんかもったいないなと思う。
まったくそのとおり。プログラミング言語なんて道具にすぎない。 エンジニアは仕事に合わせて最適な道具を選ぶのであって、 道具に合わせて仕事を選ぶのではない。
けれども道具に愛着を持つのもまたエンジニアの性であって、 良さげな道具を手に入れたらそれを使ってみたくなるというのも人情だ。
この二つは必ずしも相反するものではない。 自分の得意分野、つまり相対的に自分が他に比べてより多くの価値を生み出せる分野が、 たまたま自分の好きな道具がもっとも適している分野と重なっていれば良い。 もちろん言語の選択には色々な事情が絡んでくるので、 その場合であっても常にLispで仕事ができるというわけではない。 けれども、(1)他ではなかなかできないことをあなたのチームはやれる、 (2)あなたのチームがそれをする時に、Lispを選択すると生産性が最大となる、 というのであれば、Lispを選択しないというのは悪手であろう。
Lispが好きで仕事に使いたいと思っているなら、(2)をクリアするのは簡単だ。 問題は(1)である。他のチームが他の言語を使ってできるのと 同じことを同じように出来るだけでは、意味が無い。 他の条件が同じなら、マイナー言語はメジャー言語より不利なのは間違いない。 エンジニアを探すのも、ライブラリを探すのも、後々のメンテナンスも、メジャー言語を 選んでおいた方が楽になるに決まってる。 よそではできないことができます、そしてその秘密兵器が実はLispなのです、 という順番でなければならない(MLでもHaskellでもいいけれど)。
現在の環境で、そういった意味でのLisp (decentなCommon Lisp処理系)のエッジは、 抽象度の非常に高いところ(DSLとか)から非常に低いところ (ビットを直接触るとかコンパイル結果のネイティブコードを見ながらチューニングするとか) までを単一の言語でカバーしているところだと思う。 今もCommon Lispのコードで共有メモリ上に置かれたバイナリのデータ構造を いじってるのだけれど(事実上、特殊なmalloc/freeを実装している感じ)、 性能を確保しつつメンテナンス可能な範囲に複雑性を収めるには 多分Common LispかC++じゃないと無理だろうなと思う。 とりあえず、それなりの質のネイティブコードを吐けること、 必要ならばさらに高速なネイティブコードを出せるように言語から制御できること、 メモリ上のデータ配置を制御できること、 GCを起こさないコードを書けること、あたりは必須。 (このへんは言語というより処理系の話も含まれるんだけれど、 言語の選択は現在availableな処理系で考えるしかないので、 「そういう処理系が使える」ということ自体はポイントになる)。 それでいて性能クリティカルでないところでは高階関数もGCも使いまくりたいので、 そうなると選択肢はCommon Lispということになる。
JVM上で走るLisp/Scheme処理系というのはその意味で不利な競争を強いられる。 大きな強みである低レベル層へのアクセスが制限されてしまうからだ。 もちろん、JVMはJVMで大きな土俵を用意してるのでその上で競争することにも 意義はあるのだけれど、「他の条件が同じならマイナー言語はマイナーであるだけで 不利になる」というハンディキャップがある。 Clojureのように、今までのメインストリームであまり目にしなかった パラダイムを付加価値として持ち込むという戦略がないと難しいだろう。
なお、Gaucheの狙いは、上で述べたような現行のCommon Lispがカバーするところではなく、 「使い捨てスクリプト」から「大規模なプログラム」へと プログラムが自然に発展してゆけるようにすることにある。
(追記：続きもあるよ)
Tags: Programming, Lisp, Scheme
2010/02/11
文字列リテラルの連結
■ Rubyって文字リテラルを二つ連続で書くと連結されるの? 知らんかった。おかげでバグの理由がわからず悩んだよ。 ["hoge" "fuga"] => ["hogefuga"]
□ @emeitch C/C++もそうですね
■ @fistfvck なんと。これは誰にとって嬉しい仕様なんですかね?
■ 文字リテラル連結はpythonでもできる。perlやjavascript(spidermonkey)ではできなかった。ほとんどではないけど、いくつかの言語処理系ではできるので、それなりに一般的な文法なんだなぁ。
■ あ、scheme(gauche)でも当然できなかったよ。まぁ、Lisp系言語でやられたら困るんだけど。
いくつかメリットを考えてみた。
- 文字列リテラル中に(無視される)改行+インデントが自由に入れられない言語では、長ーい
リテラルを書こうとするとソースの横幅が伸びちゃう。ソースを80カラムに
納めたくて、かつ実行時に文字列連結をやりたくない場合に、
リテラル連結があれば自由に改行してかつインデントを揃えることができる。
const char *long_string = "Lorem ipsum dolor sit amet, consectetur adipisicing " "elit, sed do eiusmod tempor incididunt ut labore " "et dolore magna aliqua. Ut enim ad minim veniam, " "quis nostrud exercitation ullamco laboris nisi ut " "aliquip ex ea commodo consequat.";(Cで'\'を入れてつなげた場合、2行目以降がインデントできない (空白文字がリテラルに 入っちゃう)。 - マクロが貧弱で、マクロ内で文字列連結処理ができない場合。
#define DEFGREETING(var) \ const char *var = "Hello, " #var "." DEFGREETING(Shiro);
- もともと、連接する式が文字列の連結演算ってセマンティクスになってる場合 (そういう言語があった気がするけど忘れちゃった。) リテラルでなくても文字列を生成する式を並べておけば、実行時に連結される。 たまたまそれが全部リテラルであった場合は、 最適化として実行前に連結されるってだけ。
第一点について。 Schemeの場合、無視される改行+インデントはR6RSで書けるようになった (Gaucheも対応済)。
(define *long-string*
"Lorem ipsum dolor sit amet, consectetur adipisicing \
elit, sed do eiusmod tempor incididunt ut labore \
et dolore magna aliqua. Ut enim ad minim veniam, \
quis nostrud exercitation ullamco laboris nisi ut \
aliquip ex ea commodo consequat.")
CommonLispの場合、案外文字列リテラルの機能は貧弱なんだけど、 format使うと無視される改行+インデントを埋め込める。まともな処理系なら これは単なるリテラルに展開されるはず。
(defparameter *long-string*
(format nil
"Lorem ipsum dolor sit amet, consectetur adipisicing ~
elit, sed do eiusmod tempor incididunt ut labore ~
et dolore magna aliqua. Ut enim ad minim veniam, ~
quis nostrud exercitation ullamco laboris nisi ut ~
aliquip ex ea commodo consequat."))
ただこのCLの方法は、このformatフォームを別のリテラル (quoteされた リスト内とか)に自由に入れられないという欠点がある。`(... ,(format ...) ...) とかすればできなくはないけれど、透明でないのがいやな感じ。 マクロを利用してリテラル同士をくっつけるという解も同じ欠点がある。 (透明でない、とは、それまで単なるクオートされたリテラルだった 構造の一部をこの形式に置き換えた時に、その場所のローカルな変更だけでなく リテラルの外側にあるクオートも変更しないとだめ、ということ)。
第二点についてはLisp/Schemeではマクロ展開時に好きなだけ 文字列連結できるので問題ではない。
第三点については、Lisp/Schemeの文法と両立しない。
なのでLisp/Schemeに取り込むメリットはないけれど、言語の機能によっては メリットがあるだろう、と思う。実際C/C++では自分もよく利用するし。
Tag: Programming
2010/02/07
らむ太と変身
最近のらむ太は戦隊ヒーローものとか合体変身ロボットものに夢中で、 毎日毎日、各種仮面ライダーとかシンケンジャーとかレスキューファイアーとか スパイダーマンとかトランスフォーマーなどに変身し、 大人には見えない敵と戦うのに大忙しである。
ところでらむ太世界においては、何故か長ズボンを履いてないと 変身できないことになっているらしい。より正確には膝が隠れる長さでないと 駄目らしい。短いのを履かせようとすると
「『ひざかくれる』はく〜」
と泣いて嫌がる。
それでも洗濯の都合でどうしても短パンを履かなければならない時は、
「へんしんできなくなった…」
と言って見るからに落ち込んでいる。
しばらくして静かになったので覗いてみると、 熱心に仮面ライダーのベルトだのレスキューファイアーの剣みたいのだのを 作っていて、次の変身に備えているのであった。
Tag: 生活
2010/02/01
プログラマもいろいろ
業務の一環として文章を書く人が全て文筆家ではないように、 コードを書く人をひとくくりに「プログラマ」とまとめることに 無理があるのかも。
「日々の学習や訓練と仕事が切り離せない」というのがこの話の要点のひとつだが、これはプログラマに限らず、デザイナーや建築家、文筆業、料理人、役者など、「プロフェッショナル」と呼ばれる専門的な職業のほとんどにあてはまるだろう。
今やってる仕事にはフリーランスのソフトウェアコンサルタント (という肩書きのノマド的プログラマ)が数人参加してて私もその一人。 こんな具合に、あるプロジェクトに向けて専門家をえいやと集めて 短期集中でものを作るのは、確かに映画製作とか芝居のプロデュース公演に似ている。
地理的にヨーロッパ、米国両海岸、ハワイと分散してるため、 テレカンファレンスのために朝5:30に起きるのは億劫だけど、 仕事自体はやりやすい。みんな自律的に自分の役割を見つけたり 調整したりすることに慣れてるので。そのへんも映画や芝居の感覚と似ている。 (そういえば、業界界隈では一過性のプロジェクトのことを"gig"と言うことがある。 "I was in Boston that summer for a Lisp gig." とか。)
ただコンピュータソフトウェアは、映画や芝居と違って継続的に手をかける必要があり、 「できました、はい解散」というだけでは済まない。 一発もののソフトウェア (ビデオゲームとか) でもなければ、 誰かが製品やサービスのライフサイクルを見届ける必要があり、 その誰かはやっぱりプログラミングが出来ないとならないだろう。
つまり「特定の技術の専門家としてのプログラマ」ばかりがプログラマではない。 ある製品なりサービスなりを組み上げて手をかけて行くのが仕事で、 その手段としてプログラムをしている、というプログラマもいるはずだ。 現実には後者の方が圧倒的に多いだろう。 役者や文筆業に例えられる「技能でもって独り立ちしているプロ」というのは 前者のプログラマにはよく当てはまるけれど、 後者のプログラマに当てはめても良いものだろうか。
例えが微妙だけれど、法学部を出ても弁護士になる人もいれば企業の法務部に 勤める人もいる。どちらも法律を扱うけれど、仕事で求められることも キャリアパスもかなり違う。一般的には別の職業とみなされるんじゃなかろうか。 同様に、共通するのはプログラムを書くということだけで、 仕事内容もキャリアパスも異なる別の職業が、今は「プログラマ」といっしょくたに されているのかもしれない。
(追記2010/02/03 01:31:17 UTC): このエントリでは「プログラマ」と呼ばれる人々のうち、 特定の技術を武器にプロジェクトを渡り歩くノマド的プログラマというカテゴリを 設定してみたが、そうではないプログラマ ("後者のプログラマ") にも 様々な業態が考えられるのでひとくくりにできるものではない。ノマド的 プログラマに含まれないプログラマとしては、例えば以下のような カテゴリがあり得るだろう。
- いわゆる日本の「システム・エンジニア」で、 システムデザインやインテグレーションと同時にコードも書く人。
- Web2.0系のトッププログラマだけれど、 特定の技術そのものの追求よりはサービスの提供にコミットする人。
- プログラミング専業じゃないけれど、職場の効率化のために Excelのマクロとかイントラネットのcgiを書いてる人。
このうち、「Web2.0系のトッププログラマ」については 24x7で努力が求められる「独り立ちするプロフェッショナル」という パスがあるかもしれない。ただ、そのキャリアパスはどっちかというと 「技術もわかるプロデューサ」的なポジション (肩書きはVP of Technologyとか CTO) につながるもので、プログラミング技術を提供して渡り歩く ノマド的プログラマとは若干違うものになると思う。
3番目のカテゴリについては、現在ではこういう「片手間プログラミング」が 正当な業務の一環として扱われてないきらいがあると思うのだけれど、 「高レイヤでプログラムを書くこと」が「論理的な文章を書くこと」くらいまで 一般的なリテラシーとみなされる時代が来れば、 「業務の一環としてプログラム書いてます」ってのが普通になってくるだろうし、 そうなると業務システムの開発も、システムインテグレータが全部作るんじゃなくて、 ユーザ側で書ける人がカスタマイズに参加する形になってくかもしれない。
ともかく、「プログラムを業務の一環として書く人」のうち、 プロフェッショナルとして公私別無く研鑽を積まなくちゃならないって人は 特定のキャリアパスを目指す一部の人たちだけだろう、というのが要点。 今現在、そうなってない (将来独り立ちする技術者になるつもりは無いのに、 四六時中学習することを求められる) のは、コンピュータエンジニアリングが 未成熟だからだ。これについては項を改めて書くかもしれない。
Tag: Career
2010/01/31
発言する必要がないなら出なくて良い
渡辺千賀さんの仕事のプロになりたかったら - 会議でわからないことがあったら、その場で必ず聞く。これは徹底して欲しいあるですよ。を受けてのこの記事を読んで：
でも、アメリカだと、他の方に敬意を示して喋らないでいると・・・バカだと思われます。それか、使えないヤツだと思われます。次から、きっと、会議には呼ばれなくなるでしょう。
発言して、議論に何かバリューを与えられるからこそ、会議に呼ばれます。何も発言しないんだったら、そんな人、会議に呼ぶ必要はない、となります。
だから、会議では発言し、存在感を示す必要があります。そうしないと、会議に呼ばれなくなるので。
「呼ばれなくなる」と言うと切り捨てられるみたいで怖ろしげだけど、 会議というものは全体が回る限りにおいては少なければ少ないほど良いので、 発言する必要が本当に無いのなら、呼ばれなくなる前にこちらから 「意味が無いので次から出なくていいですか。」と言えば良いのである。 実際、「とりあえず関係ありそうな人集めてみましたミーティング第一回」の後で、 「Do I need to attend further? It seems that I'm no use here.」 みたいに断って出なくなる人、普通にいる。 会社としても会議するためじゃなく業務を遂行するために雇ってるわけだし、 本人としても無駄な時間を取られずに仕事に集中できるわけだし、損する人はいない。
というのはまあ上のエントリの著者の意図とは違うツッコミなんだけど、 でも根本は同じだと思うんだよね。アメリカは何も、ごりごり自己主張しないと 蹴落とされるサバイバル世界ってわけじゃなくて (まあ主張しなきゃならない 時には主張しないとまずいけど)、自分がやるべきことやらなくちゃ ならないこと、相手がやるべきことやらなくちゃならないこと、どちらも尊重したら、 無駄な会議に時間を使わないっていうのは自然な帰結のひとつだってだけ。 この論理のフレームでは「発言して議論に貢献する」とか、 「わかるまで質問して完全に理解する」ことこそが、参加者全員への敬意の 表明になるわけだ。
なので、「こんなこと聞いたら失礼なんじゃないか、邪魔なんじゃないか」と 思っていたら、フレームをいちど掛け替えてみるといい。聞かないことが失礼に あたるのだとね。
さて、それを頭で理解したとしても、いざ発言したい何かが頭の隅にひらめいた時、 そこからうまい具合に質問にまとめてうまいタイミングで発言する、 というのは難しい。会議で発言するというのは身体動作を伴うアクションであって、 キャッチボールや球技のパスと同様、練習しないとうまくできないものなのだ。 (頭の中でヴァーチャルに発言してみるだけじゃだめ。 イメージトレーニングはリアルのトレーニングが伴ってこそ役に立つ。)
学生さんなら、練習の機会はたくさんある。私の大学院時代、毎週一回、 専攻の院生(修士、博士)必修の輪講というのがあったのだけれど、 修士の途中くらいから、毎回必ず一回何か質問すると決めて実行していた。 これはすばらしい練習効果があるのでここ読んでる学生さんはやってみると良い。 何より、質問するつもりで聞いてると集中して聞ける。 (もちろん、参加者全員が質問する時間は普通はないので、やったもん勝ちである。 今でも学生の気質が変わらなければ、多分質問時間は余りまくっているはずなので、 先着2-3名の余裕はあるだろう。それ以上質問が出るようなことになったら それは大学院輪講としても大変結構なことであるので、運営の方で うまい方法を考えるだろうから(当て方を工夫するとか)、心配しなくてよい。)
仕事をしてる人でも、まあ社運を賭けた製品の戦略ミーティング、みたいに 緊迫した場面じゃさすがに練習はできないだろうけれど、もっとゆるい ミーティングはあるはずなので、その場を練習に使うといいと思う。 ただ、気の置けない仲間内、っていうのはだめ。 たまに、質問に立ったはいいがだらだらとまとまりのない話をしだす人が いるけれど、そういうのに対して「要するに質問は何?」というツッコミが 入るような場じゃないと練習にならない。突っ込まれることは落第点を もらうことではなく、キャッチボールのボールを投げてくれたってことだから、 受け取って次に活かせばいい。
Tag: Career
Comments (0)