Rebuild A Podcast by Tatsuhiko Miyagawa. Talking about Tech, Software Development and Gadgets.

Feb 13
2013

1: Podcasting, LTSV, RubyMotion (伊藤直也)

収録時間: 52:53 | Download MP3 (31.5MB)

伊藤直也さんをゲストに迎えてポッドキャスト、LTSV、RubyMotion、Perlなどについて話しました。

00:00

miyagawa: naoyaさん、最近は結構ブログが活発になってきている感じですね。

naoya: はいはい、そうですよね。

miyagawa: なんか、心境の変化があったんですか。

naoya: 心境の変化(笑)

miyagawa: (笑)

naoya: いやずっとドラクエしかしてなかったんですけど(笑)

miyagawa: (笑)

naoya: いやそれで、最近ちょっと、なんか作ったりしてるので。結構一人で作ってるんで、あんまり「こういうことやった」みたいなことを、他人に共有する機会が無いんですよ。

miyagawa: うんうん。

naoya: そうすると、なんかブログに書いてみようかなって気になって。久しぶりにブログを更新してみたら、案外面白いな、みたいな。そういう心境ですね。

miyagawa: うん。あれですよね、大きい企業とか、特にGoogleなんかに入ると、急にブログのアウトプットが無くなるみたいなの、よくありますよね。

naoya: ああ、そうそう。ありますねぇ。まあ単純に、僕の場合は前職で忙しかったっていうのはあるんですけど、Googleとかだと、話を聞いてると、職場の中で承認されちゃうっていうか。

miyagawa: うんうん。

naoya: 技術的にもすごいねって話をみんなでしちゃうから。

miyagawa: そうなんですよね。なんかね。

naoya: なんかね、コードの隅々まで見てもらって満足しちゃうみたいなのはあるかと。

miyagawa: その逆パターンで、職場とかで満たされないものが出てくると「ブログに書いてアウトプットしたくなってくる病」みたいなのは、結構ありますよね。

naoya: そうそう。そうですよね、まさにそんな感じです。

miyagawa: (笑)

naoya: (笑)

01:29

miyagawa: あれですねー、僕も最近、podcastとかをね、海外のpodcastを、昔からずっと聴いてたんですけどpodcastが最初に出てきたのって2004年とか5年くらいなんですよね。

naoya: そうですね。

miyagawa: で、当時はCNETとか英語のブログとかのpodcastを聴きつつ、日本でも盛り上がってきたのがここ3,4年くらいで。でも、盛り上がってるのが個人のpodcastとかじゃなくて、大体がニッポン放送とかTBSラジオとか、なんかそういうのの、ラジオ番組のおまけみたいなのをやってるのが多くて。

naoya: うん。

miyagawa: なんかもうちょっと、いい使い方ないかなーと思っていたところに、ここ半年くらいアメリカのほうで、個人とかがやってるインディーpodcastネットワークみたいなのがいくつか出てて。あとでこの記事をアップするときに、リンクを貼っとくんですけど、5by5っていうネットワークとかMule Radioとかっていう、なんか、著名なブロガーの。例えば、Marco Armentっていう元tumblrのCTOで、今はInstapaperとか作ってる彼とか。あとJohn Siracusaっていうのが、Ars TechnicaでMac OSXの記事を書いてる人で、そういうなんかブロガーの人とかが結構、個人のpodcastで、色々と、週に1時間とか30分とか話してて、結構面白くって。そういうのを日本語でもあったらいいのになーと思って。

naoya: なるほど。彼もあれですよね、Instapaperの人も一人で開発とかやってるんですよね。色々読みましたけど。

miyagawa: うん、ほとんど一人で、自分で開発をしているみたいです。特にiOSのアプリとか、ウェブサイトに関しては全部一人でやってて、こないだInstapaperのAndroid版が出たやつに関しては、「自分でAndroidの開発は絶対にやりたくない」って言ってて。

naoya: (笑)

miyagawa: だから、レベニューシェア的なのでアウトソースしてるみたいですね。

naoya: あ、そうなんだ。

miyagawa: やっぱりその、(彼は)個人的にはすごいiOSのファンというのもあると思うんだんだけど、ユーザーベースが増えてきて、だんだん無視できなくなってきたけど自分でやりたくないみたいな、そういう感じだったんでしょうけどね。

naoya: そういう人がpodcastとかやってる感じなんですね。

miyagawa: 僕の他のpodcastを見てくれてた人がいるかもしれないですけど、僕、他にも、drikinがやってるdrikin.tvっていうの(podcast)にも出てて。これ別に、なんか問題があって別の(このpodcast)を始めたっていうんじゃなくて、全然なんか違う感じでやってみようかなと思って。オーディオのみってのもあるし。あと、ネタとかももうちょっと開発寄りとか、techとか。向こうの番組はなんか、techネタもそうだけど、ガジェットとかが中心なんですけど。もうちょっとなんか、ウェブサービス全般とか、開発に突っ込んだ話とかそういうのもできたらいいなーとか、思ったりしているわけです。

naoya: はい。

04:52

miyagawa: 最近の、naoyaさん的に盛り上がってるのは、LTSVってのに盛り上がってるぽいですね。

naoya: LTSV、盛り上がってましたねw あれなんででしょうね(笑)

miyagawa: (笑) 簡単に説明してもらっていいですか。

naoya: TSVは、ApacheとかでcombinedログっていうApacheのログのフォーマットがあるんですけど、あれの、改良版というか、新しいログフォーマットです。新しいっていっても、実際には単純にタブでフィールドを区切って、それぞれのタブに名前を、キーをセミコロンでつけるっていうだけのすごくシンプルなフォーマットなんで、特に技術的に新しいってわけではなく単純にフォーマットが新しいっていうだけのやつです。

それの、ちょっとした工夫だけで、ログのパースがすごく簡単になるんで、意外とそのApacheのcombinedログって、こう、パースしようとすると、すげーめんどくさかったりとか。あと、値を途中に追加しようとしたときに、ログのフォーマットを、それまでやってたプログラムを全部書き換えなきゃいけないみたいな問題があったのが、ま、簡単に解決できるっていう、そういうフォーマットだと。

miyagawa: なんか、ブログ記事がポンと出てきて、それですぐに色んなのが対応するみたいな、なんかブログの初期みたいな盛り上がり感が、ちょっと懐かしい感じがしましたね。

naoya: そうそう。たまたまなんか僕がブログを最近書いてるなーみたいなところに、あのネタが他の所から投下されて、たまたま乗っかってたら広まってったみたいな感じで。ちょっと確かに昔っぽい感じがしましたね。

miyagawa: 一番重要なのは多分、フォーマットが新しいんじゃなくて、名前が付けられたことだと思うんですけど。

naoya: ああ、そう、それもあると思う。だから、あれを最初から名前付きで、なんとなくそれっぽい名前で、stanakaさんが、postしてたってのは結構大事だったと思うんですけど。

miyagawa: それは狙ってやってたんですかね。

naoya: どうなんですかね。でも多分社内で三年間使ってたから、その間に多分その名前が定着してたというのもあり得るんじゃないかと思いますけど。

miyagawa: うんうん。

naoya: ある日突然その自分がそういうのを思いついたって言って、名前つけてpostしようと思っても、なかなかあまり自信がないと思うんだけど。

miyagawa: たしかに。やっぱり名前があるないで、多分あの記事に名前が無かったら、「こういうことやってます」「へー便利だね」で多分終わるんですよね。
naoya: そうですね。で何かLTSVっていう、こう、かっこいい感じの名前がついているから、ブログのタイトルとか見て、「あ、なんだろう」とか思って見に行ったら、盛り上がってるみたいな。

miyagawa: 結構、ググラビリティがあるというか、しかも、Twitterとかで反応も探しやすいし。

naoya: うん。結構、ツイート見てたら、「LTSVって最近なんかよく聞くんだけど、見に行ったらログのフォーマットのことだった」みたいなツイートが結構あって。

miyagawa: (笑)

naoya: 「大げさなことかと思ったら、ただのフォーマットだった」みたいなのありましたけど(笑)

miyagawa: 確かに名前だけ見ると、別に、テレビ関係かなとかなんか全然わかんないですよ。

naoya: (笑) あれですよね、一方でやっぱFluentdとか、最近結構ログ周りのソリューション、すごい盛り上がってるんで、そういうところにうまくはまったていうのもあると思うんですけど。5年前とかに同じことを言っても、「別にApacheのログなんかcombinedログでいいよ」で終わりだったみたいなところは、ちょっとあると思うんですけど。最近、ソーシャルゲームとか特にやるんですけど、データを結構ログの中に埋めるんですよね。

miyagawa: うんうん。

naoya: そもそもApacheが標準で対応してないような値を。そういうことをぐちゃぐちゃやってると、ああいうフォーマットがすごく生きてくるんだろうなと。

miyagawa: あれ?Apacheってcombined意外にももういっこ何か、extendedとかいうのありますよね、確か。

naoya: 何かありましたねぇ。combinedしか使ってないからよくわかんない。

miyagawa: それがある時点でなんかすでに破綻しているというか。(笑)

naoya: (笑) 確かに。

miyagawa: 確かextendedは何かリファラとかUAとかが、あれ、何かが追加されてた気がするんですけどね。

naoya: リファラやUAは多分combinedでもある。

miyagawa: ああ、あるか。何か追加でありますよね、他にも。

naoya: まあまあ、そんな感じでしたね。

miyagawa: うん、しかも簡単だから他の言語の実装とかを見るのが結構面白いっていうか。

naoya: ああ、そうそうそう。

miyagawa: なんかperlとかRubyだとね、ほんと、ワンライナーで書けちゃうんだけど。nodeのやつとか。

naoya: streamのやつですよね。

miyagawa: うん。そういうのを見ると、ああ、こういうふうに書けるのね、みたいな。結構そこが面白かったなーと思うんですけど。

naoya: C#のやつ、僕、C#は本当はほとんど見ないんですけど、ダイナミックなんとかっていう、こう、クラスを使って、型を無視して、値を扱うことができたりしていて。昔、Java書いてたときにそのウェブサービスのWeb APIとか、XMLをパースしたあとに型をマッピングさせるのがすげーめんどくさいとか思ってたんですけど。最近こういう感じでダイナミックにできるんだなーとか、面白かったです、見ていて。

10:08

miyagawa: やっぱりこれはあれだね、日本の技術コミュニティって、すごい、蛸壺化(たこつぼか)っていう言い方は悪いかもしれないですけど、なんか、狭いから、すぐバーッて広まる所はあると思うんですよね。地理的に狭いのはもちろんあるし、Twitterとかブログとかでフォローし合ってるのが、もの凄い固まってるイメージがあって。

naoya: あれですかね。そもそも、なんというかウェブ系のエンジニアっていうんですかね、こないだ反応したみたいな人たちって。

miyagawa: うん。

naoya: で、まあ日本だと大体、エンジニアって呼ばれているソフトウェアエンジニアの人口の10%ぐらいしかいないんですよね、ウェブ系エンジニアって、実は。それ以外はほとんどSIerとか、SEとかのエンジニアで。その極(ごく)10%のしかも東京近辺の人たちとほとんど繋がっちゃってるからw

miyagawa: (笑)

naoya: だからすぐ広まるっていうのはありますよね。

miyagawa: すごい特殊な環境というのは、多分、あると思うんですけどね。なんか、Hacker Newsとかにもpostして(ましたよね)。

naoya: そうそうそう、や、だから、本当あれはもうちょっと英語圏でも盛り上がって、なんとなくデファクトになっていけば、例えばそこから標準化しようみたいな話がちゃんと進んでいくと、Apacheの標準とかに取り込もうみたいな話になっていくと嬉しいんですけど。

miyagawa: うん。

naoya: なかなかねー、そこが乗り越えられないっていうのが、ちょっと課題かなーと思っていましてね。

miyagawa: ちょっとだけ盛り上がってましたよね、Hacker Newsの上で。

naoya: そこから、こう、なんていうのかな、誰かがブログを書いて、どっかで話題になってみたいなところにはまだ行ってないので。最初の火種をどうやったらそこまで広げられるんだろうというのは、思いましたけど。

miyagawa: 結構、炎上マーケティング的なやり方をしようとしてたけど(笑)

naoya: (笑) ま、でもね、実際こう、英語のニュアンスで、どこまで、なんていうか、こう、ひどいタイトルをつけるというのも自分ではよく分かんなくって。
miyagawa: いやでも本当ね、Twitterでkyotoさんとかが言ってたけど、そういう釣りタイトルでHacker Newsにpostするってよくやってる人いるんですよね。

naoya: あーそうなんですね。

miyagawa: それで釣られて読めば儲けモンみたいな。

naoya: うん。

miyagawa: でも最近Hacker Newsって、まあ、最近に始まったことじゃないんですけど、Geek向けはもちろん、スタートアップ関係の人たちとか、すごい、読者層が(厚くて)、リーチが多いんで。Hacker Newsのトップページに、ちょっと何十分、一時間載るだけで、やっぱりものすごい露出にはなるみたいですね。

naoya: そうですね。、昔の、某は(ry「某ソーシャルブックマーク」(笑) な感じですよ。

miyagawa: (笑)

naoya: まさに、ほんとに。

12:49

naoya: あの、エンジニアばっかりが(某ソーシャルブックマークを)使ってたような時期があったじゃないですか。

miyagawa: そうねー、僕は前の会社はY Combinatorに出資を受けてたような会社なんですけど。DotCloudっていう。そこのブログpostとかも、下手にプレスリリースとか出すのじゃなくて、ブログpost書いて、Hacker Newsでなんとか載せよう、みたいな。、そういう感じのマーケティングをやってた時期もありましたね。だから下手にプレスリリースなんかよりそっちの方が全然影響力も高いし、影響したいリーチのところに、ポンと行くっていう。

naoya: (そういう)のは、ありますね。

miyagawa: 昔、Hacker Newsとはまた違うなんかDiggとかあって。もう全然廃れちゃいましたけど。やっぱり、ターゲットをニッチなままで絞っておくっていうのは、結構大事なのかなっていう。

naoya: そうですね。その方が絶対面白いですからね。

miyagawa: そういう気がしてますね。最近は僕はiOSとかAndroidでFlipBoardとかそういうアプリを使ってて。もちろんRSSリーダーも使うんですけど、RSSリーダーは最近は流し読み的な感じが多くなってきてて。FlipBoardでHacker NewsのTOP100とか、あと、なんだろう、なんかそういうのを見ることが多いんですけど。naoyaさん的にはどういう情報を、どういう所を見ている感じですか。

naoya: 僕はあれですね、やっぱり、はてブの、あの、フォローっていうんですか、トップページとかじゃなくて。あれで結構エンジニアの人をフォローしているっていうのが多分一番見てるところで。RSSリーダーは僕もほとんど流し読みですね。そんな見てない。あとTwitter流れてくるの。Hacker Newsは時々見るみたいな感じですけど。そうそう、なんか、Hacker Newsの、日本語版みたいなのがあったら面白いなーと思ってるんですけどね。

miyagawa: うんうん、最初っからこう、もうターゲットをすごい絞っちゃって。

naoya: そうそうそう、エンジニアリングとその周辺くらいに絞って、うまくそのコミュニティを維持できると結構楽しいなーとは思っているんですけど。

miyagawa: 多分はてブが昔はそうだったていうのは、使ってる層がそういう人が使ってたから。多分。

naoya: うん。まあ最近ね、人が増えちゃったので、良くも悪くも、あんまりエンジニアリングと関係の無い話題の方が多いので、それだけに絞ったものがあってもいいかなーとは思います。

miyagawa: なんかRedditとかだと、SubRedditってのがあって。

naoya: なんかあのタグきれるやつですよね。

miyagawa: そうそうそう、例えばReddit/Perlとかやったら、Perlのネタしかpostできないっていう。というふうになっているから、はてブとかも多分、そういうふうにしていくって方法は多分あったと思うんですけどね。

naoya: うん、けどその、なんていうのかな、Hacker Newsみたいにあんまり難しいこと考えなくても、そこに行くと全部あるみたいな状況の方が分かりやすいし、トラフィックも集まりやすいから、Redditみたいにその分散しちゃうと、結構ニッチというか。、2ちゃんねるみたいな感じになっちゃうんで。

miyagawa: 確かに。

naoya: だから、そこのバランスみたいなのはあると思うんですけど。

miyagawa: Redditは、なんていうか、サブコミュニティになって本当狭い感じなんですよね。

naoya: うん、そう。LTSVは、たまたまそういう感じで乗っかってったっていう。で、それ以外に、普通に、エンジニアリングしてて、やっぱり、このへんがっていうのが、まあなんだかんだいってやっぱクラウドと。あと最近RubyMotionていうあのiOSのやつをよく触ってるんですけど。RubyMotionとクラウドと、あとなんですかね。でもその2本がやっぱり大きいかなって気はしますね。

16:49

miyagawa: クラウドの話っていうのは多分、ひとりで開発してると、大きな会社でDevOpsとかITとかシスアドミンと呼ばれるような人たちがいるようなところを含めてひとりでカバーできる、多分、時代になってきてるから。

naoya: そうそうそう。

miyagawa: その辺を、こう、手を出してみてるって感じですか。

naoya: そう、実際は、あの、自分で作ったサービスをEC2でも動かすのであって、で、今いろいろいじってるとノウハウもたまってくるので。それを吐き出したりというのもあるし。あとAmazonは動きがすごい早いんで、追いかけているうちにどんどん知識がたまっていくみたいなのもありますけどね。

miyagawa: うん。

naoya: あとは、実際そのchefとか、そういう自動化とかもするじゃないですか。その辺、単純にクラウドを、EC2を使ってるっていうんじゃなくて。、さっきDevOpsていうのがありましたけど、それをこうガーッと1人でやってくと、なんか「楽しい感じだな」みたいな。

miyagawa: 結構、3、4年前と今とじゃもう全然違う感じでしょ。

naoya: 違う違う。だから、3、4年前は言ってもその、オンプレというか、自分で持ってるサーバーを、リプレースするためのクラウドみたいな感じだったんですけど。今、なんていうのかな、クラウドが実際のそのプログラムの一部品みたいな概念じゃないですか。

miyagawa: うんうんうん。

naoya: で、自分はそこまでやらないですけど、完全に、サーバーを増やして減らすみたいなのを、プログラミング側の、部品としてコードの中から操作みたいなことを普通にやるようになってきたし、そういう所は結構あるかなーと。

miyagawa: そうですね。昔って本当に、10年前とかだったら、例えばPerlを使ったとして、Perlをインストールもそうだし、なんか、CPANモジュールですらインストールはシスアドミンの人がするみたいな。

naoya: そうそう(笑)

miyagawa: (笑) 感じですよね、だったですよね。

naoya: 昔あれですよね、だから、手でCPANをインストールしちゃうとそのあとの管理が大変だから、インフラやってる人たちにRPMパッケージにしてくださいってお願いして。で、入ったパッケージができましたって言ってからインストールするみたいなことをやってましたからね。(笑)

miyagawa: (笑) いちいちね、そう、CPANのモジュールいっこいっこRPMにして、RPMとか使うととりあえず依存関係とか全部やってくれるから、ていう。

naoya: まあでもそこの間に人手が介してたのが、今そもそもmiyagawaさんが作ってるネタのcartonにもあるし、Perlに限らずどの言語もだいたいそういうシステムが全部あるので、全部自動化してできるっていうのがすごい楽しいですね。

miyagawa: そうなんですよね、だからやっぱりもう、依存モジュールっていうのも含めてアプリケーションの一部になるっていうのがすごく自然だと思うし、その考え方がなんか、依存してるライブラリのバージョンアップをしたら、シスアドミンの人が勝手にバージョン上げたから動かなくなったとかていうのも、そういうのを防げるようになるし、すごく自然な考え方ですよね。

naoya: そうですよね。うん、だからなんか、この辺のニュアンスがね、意外とクラウドをやってない人にあんまり伝わらないっていうのがあるんですけど。クラウドって言ったときに、みんなどうしてもその負荷分散ができるとか、簡単にサーバーが立ち上げられるって所ばかりに目が行きがちなんですけど、実際、クラウドを中心にしたエコシステムっていうと大げさですけど、クラウドに乗っけるからって前提で色んなものが自動化されたり、改善されたりしているって大きいな流れがあるじゃないですか。

miyagawa: うん。

naoya: それがね、結構、積み重なってきて。最近結構すごいなーと思って見ている感じですね。

20:34

miyagawa: こないだ紹介してたやつは、vagrantでしたっけ。

naoya: そうですね、はい。

miyagawa: あれとかも、VM自体をもバージョン管理して、立ち上げて、それの中でもchefとか、puppetとかを走らせて、みたいな。そこらへんも含め全てスクリプト化して、再現できるようにするみたいな感じですよね。

naoya: そうそうそう、あのvagratはなんか、berkshelfっていうのかなー、なんかそのBundlerみたいなのがセットになってくっつけられて、それを使うともうコマンド一発でVMを立ち上げた層だから、そのchefのレシピも元から全部持ってきて、インストールして、立ち上げる所まで、一気通貫で、やるとかっていうこともできるので。ここまで来るとなんかもう、仮想化とか、ハードウェアとか、全く存在を感じないみたいな、感じになってきてますからね。

miyagawa: うん。

naoya: いやー、すごいと思います。

miyagawa: そこでやっぱり、chefとか、そこに行くっていうのはなんか凄いと思って。大抵の人は多分、そういう存在は多分知っているのも、そうじゃないのも、もしかしたらあるかもしれないけど、herokuとか、DotCloudみたいに、そういう環境を提供してくれる、PaaSですよね、Platform as a serviceの方を使って、「あーなんだこれ便利じゃん、これでいいじゃん」て、大体の人が。それでラクしすぎて、「あーこれ以外で自分でデプロイすんのも面倒くさいわ」ってなると思うんだけど。

naoya: 自分の場合はあれですよね、昔、そういうオンプレミスで自分でそういうところをやってたんで。なんていうのかな、それがこう、これだけ自動化されるっていうことはスッゲーな、みたいな。もう興味が強いっていうのはありますけどね。

miyagawa: 僕も前、今、cpanminusっていうソフトウェア、CPANのモジュールをインストールするソフトなんですけど、これがもともとのCPANクライアントよりすごく動作が軽くて速いひとつの原因は、mirrorの部分を、今までの、元々のクラアントだとmirrorのファイルをまず全部ダウンロードしてきて、tarballをまず展開して全部parseして、で、ローカルのDB、フラットファイルだったりsqliteだったりするんですけど、そこに入れるっていうのが毎回やっていて。それがだいたい15秒とか30秒とかかかるんですけど。それを全部クラウド側っていうか、サーバー側にしたっていうのがあって。で、そのサーバーは、最初はGoogleのApp Engineで動かしてたんですね。Pythonで書いて(笑)

naoya: うん。

miyagawa: 当時それしかなくて、Herokuはあったと思うんだけど、なんとなく、Pythonを仕事でやってたっていうのもあったから。、App Engineでいいじゃんと思ってずーっと走らせてたんですけど、ある日、App Engineが有料化することになっちゃって(笑)

naoya: (笑)

miyagawa: で、無料のだとほとんどトラフィック捌(さば)けないから、Googleの知り合いの人にQuota上げてって言ったんだけど、ちょっと、駄目で(笑)

naoya: (笑)

miyagawa: しゃーないっつって重い腰を上げてPerlで書いて、まあ、コード自体はほんと、1時間くらいで書けたんで。さあどこにdeployしようと思って、そのときはまだDotCloudとかherokuがPerlをサポートしてなかったから、うーんっつっって、linodeにインスタンスを立てて。でもそのときはまだchefとか、puppetとか知ってたんだけど、そこまで便利にできるものって知らなかったんで。自分で、rootアカウントを作って、アプリを動かすようなユーザーを作って、Perlの最新版をインストールしてとかやって。

今考えるとスゲー面倒くさい、そのときも面倒くせーと思ってたんですけど(笑) その辺も含めて全部自動化できたと思うし、やっぱりそういうふうになってきているんだろうな、っていう。

naoya: そうですよね。こないだなんかのドキュメントを読んでたら、そういうDevOpsの自動化の文脈って、自動化したら便利だからっていうのもあるんだけど、一方でクラウドになって色んなものが複雑になったりとか繰り返しやらなきゃいけなくなったから、っていうのも背景に、逆にあるんですよ。

miyagawa: うん。

naoya: うん、だから、やっぱクラウドで、EC2とかを触ってるとインスタンスを止めたり立ち上げたりとかしまくるんで。そうするとその一回一回そのユーザー作ったりとか、アホくさくなってくるんですよね、やっぱり、やってると。だからその自動化しようっていうモチベーションが湧きやすいっていうのも、絶対あると思うんですよね。

miyagawa: でしょうね。

naoya: でも昔ね、僕も、はてなにいたときに、stanakaさんがpuppetを使い始めたときに、全然わかんなくってw 複雑で。「こんなもん使うか!」って思ってたんですけど、まああれから年月が経ったら結構みんな使うようになったなーみたいな(笑)

miyagawa: (笑) やっぱりでもシスアドミン系の人とかは多分そういうのを昔から、puppetとかcfengineとか(笑)

naoya: cfengine(笑)

miyagawa: cfengineとかほんと地獄みたいな感じだけど。そういうのと、多分、デスクトップで開発していたサーバーサイドのエンジニアの人たちのマインドセットが、合流して、ああいうツールがどっちからも使いやすいみたいなのが、多分、できたのかなっていう。

naoya: ああ、それがまさにDevOpsっていう言葉だと思うんですけどね。

miyagawa: うん。

25:42

miyagawa: さっきなんかRubyMotionの話してましたけど。イメージっていうか、実際に使ってる感じですか。

naoya: あ、使ってますね。

miyagawa: うん。

naoya: RubyMotionが何かっていうのを軽く説明すると、iOSのアプリをRubyに書けるっていうやつなんですけど。、そもそもやっぱり僕Objective-Cがどうしても苦手というか、Xcodeでコードを書かせられるのが辛いのかもしんないんですけど。で、なんか他の言語でうまく書けないかなーと思って、そういうもの昔からよく触ってて。

で、一時期Titanium Mobileって、JSで書けるやつを使ってたんですよね。なんですけど、あれ、Titaniumとか他にも色々そういう似たようなやつがあって全部そうなんですけど、全部そのブリッジしてるというか。Objective-Cのコードを途中で吐き出す為のジェネレーターになってたりとか、そういう感じのアーキテクチャなんですよ。でもRubyMotionはそうじゃなくて、もうObjective-Cのランタイムの上でRubyをもう一回再実装…昨日その開発者の人にインタービューがありましたけど、実装してるから、直接そのバイナリを吐くんですよね、iOSの。だから速いし、あとすごいのが、iOSの、Objective-Cで書かれたライブラリと、RubyMotionで書かれたコードを直接リンクできるんで、なんていうのかな、既存の資産を全部、こう、活かせるっていう、そういう処理系なんですよね。で、それでRubyで書けるってことなんですよね。

miyagawa: やっぱりTitaniumとかより、そっちの方が筋がいい感じがしますよね。

naoya: そうですね。Titaniumもね、結構、最近AlloyっていうフレームワークをオフィシャルでMVCフレームワークみたいなのをサポートしてて、それを使うとそのXMLでユーザーインターフェースの定義書いて、CSSみたいな、JSで定義されたCSSもどきみたいなDSLがあるんですけど。それでこうコードを書けたりするので、開発スタイル的には結構モダンな感じなんですけど、いかんせんやっぱ速度とか、変なとこで落ちたりするんですね。こうこと言うとTitaniumの人に怒られるかも(笑)

miyagawa: (笑)

naoya: で、RubyMotionはそういうとこが、まあ少ないっていうのと、あとiOSのアーキテクチャそのままなんで、わりと素直に書けるっていうのは結構いいですね。

miyagawa: やっぱりブリッジ通しちゃうと、中のものを直接触れないっていうもどかしさもあるし、あとバージョンアップとかAPIの変更とかに追従しづらいっていうのが。

naoya: Titanium、それ結構ね、しどかったっすね。結構バージョン1から2に上がった時に、UIの定義の後方互換性がなくなって、バージョンアップしてコンパイルしたら、見た目はぐちゃぐちゃになっちゃったりとか、結構あってですね。そういうのがないっていうのがありますね。

miyagawa: たぶんブリッジ方式はほんとうまくいけば、そういった差異とか、あとほんとにうまくいけばAndroid版とiOS版とかをある程度同じコードベースでできるみたいな、たぶん、メリットが本当はあるんだろうけど。

naoya: なかなかね、しかもiOSもAndroidもプラットフォームの、なんていうかアップデートスピードが異常に早いんで、それにそのブリッジ側がこうついていかなきゃいけないみたいなとこがあるじゃないですか。結構、単純にiOS、Androidのプラットフォームの変化についていくだけでも大変なのに、ブリッジしたもの使ってると、それにもついてかなきゃいけない、****みたいなのがあって、あんまり現時点ではちょっと辛いかなっていう感じですね。

miyagawa: 逆にそのPhoneGapみたいな、HTML5で、ネイティブのコントロールをつけるみたいなのはどうなんですかね。

naoya: あれもね、僕一時期触ったんですけど、ちょっとやっぱHTML5でUIを作るっていうこと自体がやっぱまだ厳しいっていうのが結論で。速度がまず出ないし、あとこないだもなんかで話題になってましたけど、とにかくワークアラウンドみたなのすげーたくさん入れないと、DOM操作を普通にやらないとか。そこまでこう自分はHTML5に詳しいわけじゃないんで、使いこなせない感じがしたんですよね。だからちょっとなんていうのかな、ワンポイントのアプリというか。例えば、ネイティブの機能を使わないと実現できない、キャンペーンサイトとか。そういうのもポンと立ち上げる時ぐらいはPhoneGapとかでもいいと思うんですけど。例えばTwitterのクライアントみたいなのを真面目に作ろうと思ったら、さすがに難しいんじゃないかなって気もしますね。

miyagawa: 僕らが働いてるCOOKPADとかのAndroidアプリは今、PhoneGapではないけど同じようなアプローチをたぶん使っていて。HTML5でUIは作って。それに側であのコントロールを、ネイティブのコントロールを付けるっていう感じなんですけど。たぶん今言ったようなメリット・デメリットがあって、一個メリットとして考えてるのは、開発者がHTML5のそのバッドノウハウとかワークアラウンドは結構あると思うんですけど、サーバーサイドのRailsの普通のアプリなんで、そこら辺のこう出し入れとか更新は、あまりネイティブの知識に依存しないでいいっていうメリットはあるのかなっていう気はするんですけどね。

naoya: そうですね、そういうとこはありますね。だから結局その辺のバッドノウハウは結構詳しくって、使いこなせる人がそばにいるとか、あるいは自分自身がそうであるみたいなのが条件としてあるんでしょうけど、僕そんなにねそこまで詳しく(ないというか)。

miyagawa: (笑) でもRubyMotionはRubyで書けるっていうメリットはあるけど結局はiOSのAPIは知らないといけないんだよね。

naoya: あ、そうそう。だからRubyで書けるって言って、なんていうのかな、Rubyのメタプログラミングみたいなの想像して触ると、結構ちょっとがっかりするみたいなとこが実はあって。普通にiOSの、なんだろ、例えば、”setModalDialongなんとかかんかDismissTrue”みたいな、そういうAPIを追わなきゃいけないんで、っていうのはありますけど。ただ一応なんかね、BubbleWrapって有名なラッパーがあって、それを使うと、よりRubyっぽく書けるとか、っていう感じのはあったりしますけど、基本的にはiOSのプログラミングの作法みたいな取ってやる感じですね。

miyagawa: なんかObjective-Cのちょっと気持ち悪い方が、Rubyのシンタックスで書けるからいいみたいな。

naoya: そうですね。あと、そうです。例えばObjective-Cだと、Grand Central Dispatchってスレッドみたいな、並行処理をする処理があるんですけど、その辺とか素で書くとシンタックス全然覚えらんないんですよね。なんだけど、RubyMotionだとその辺がかなりシンプルになっていて、ブロック渡すだけでいいんで、綺麗に書けたりとかっていうのはあります。大っきいのが、開発のスタイルがやっぱりWebっぽくなるんですよ。あの僕の場合Emacsで、新しい人みんなSublimeとか使ってますけど。

miyagawa: (笑)

naoya: Emacsでコンソールで、Rakeでデバッグでして、Rspecでテスト書くみたいな感じなので、Xcodeの補完が効かないってのはありますけど、あのなんかよくわかんないIDEを一生懸命使うくらいだったらこっちの方がみたいなの結構あって。

miyagawa: そうそう。あのRubyのそのRailsに限らないんだけど、RubyGemsとかRakefile使って、なんかあとPryとかirbとかでコンソール立ちあげてっていうのが、すごくそういうそのエコシステム的な部分がそっくりRubyMotionでも、全部は使えないかもしんないけど、そういう考え方があって、それが面白いなと思ったんですよね。

naoya: ああ、そうですね。それですそれ。そこが個人的には大っきい。なんか例えば企業とかで、それだけが理由でそのRubyMotion採用するなんてことはたぶんないんでしょうけど、個人で作るってなるとやっぱそういうところの楽しさみたいなのってかなり重要なので。っていうのはありますね。

miyagawa: なんかやっぱり僕、PerlとPythonとRubyと、この2,3年ぐらい仕事とか趣味とかで色々行ったり来たりしてやってるんだけど、なんかそのRubyの、Rubyが全部100%素晴らしいっていうことではないんだけど、Rakeとか、あとコンソールとかってすごいUNIX的な開発手法がスタンダードになっていて。Macとかで開発する人がほとんだし、なんかその辺の、シェルプロンプト使ってごにょごにょっていうのが、普通にワークフローとして入ってるっていうのがすごく気持ちいいなと思って。そこがRubyMotionにも入ってるっていうのがすごくいいところだなと思ったんですよね。

naoya: そうですそうです。そこですね。ほんとにその通りですね。

miyagawa: RubyMotionでも結構お高い感じすよね(笑)

naoya: あ、値段ですか?

miyagawa: うん。

naoya: 値段、そう、ライセンスね、1万6000円ぐらいかな。ちょっと今(円安?)になってきてますけど。

miyagawa: (笑) なかなか最初の投資が結構必要ってのはあるけど。

naoya: そうですね。一応なんかそのRubyMotionのコミッターのWatsonさんっていう人が一人、日本人の人がいて。コミッターっていうか実際もう今一緒に作って働いてるんですけど、Watsonさん東京にいるんでよく会うんですよ。で、これなんかライセンスフリー版とか作んないんですかって言うと、仕組み作ればできなくはないけど、今そっちよりも他にやることがたくさんあるんだとか言ってました(笑)

miyagawa: たぶん教育用とか、学生向けとかっていうのでは、安いライセンスのもの出したりとかっていうのはしてるみたいな、問い合わせ先みたいなのはあったんで。

naoya: あ、そうですか。

miyagawa: うん。たぶん、あとサイトライセンスみたいな感じで、その大きい企業がもし100人単位のエンジニアがいて、それを100人分買うのはたぶんすごい出費になっちゃうけども、っていう部分はたぶんやったりとかしてるんだろうけど。でも個人でもね、まあ100ドル、iOSのディベロッパーになるのにAppleにいくらか払わなきゃいけないわけだし、そこら辺の生産性を上げてくれると考えれば、妥当かどうかはわからないけどそういう出費を勿体無いと思ってもしょうがないっていうのは、ケチってもしょうがないっていうのはありそうですけどね。

naoya: 一応その開発者のインタビューがあって、なんでその有料なのかとか、オープンソースじゃないのかみたいな話しが載ってて、昔MacRubyを作ってた人なんですよね、Appleで。なんだけど、MacRubyのスポンサーがMacRubyにもう投資し続けるの、興味がなくなって、で、それでMacRubyプロジェクト自体がどうしようかみたいな状態になったらしいんですよ。それがきっかけで会社を辞めて、RubyMotionやるかどうかっていうところにいって。

36:36

naoya: で、その時にまた投資とかスポンサーを見つけてやると同じ目に遭っちゃうから、そうじゃなくて、自分が書いたソフトウェアから直接、自分たちがそのプロジェクト続ける為の資金を得て続けていきたいっていうので今のこうスタイルになったとか書いてあったんで。だからそういうのを見ると、自分が使い続けるならお金払ってもいいかなっていう気にはなりますけどね。

miyagawa: 確かに外部の資金とかに依存するよりは、ブートストラップして自分でソフトウェアのライセンス料で人を雇ったりもしてるわけだから、そういうふうになってる方が健全っていう感じですよね。

naoya: そうそうそう。うん。で、逆にお金払ってるんで、結構安心して使えるっていうのもあるんですよね、一方で。Titaniumとかちゃんとあの会社がああやって上手い感じで、なんていうのかな、軌道に乗ってるっぽいので、大丈夫なんですけど。そうじゃない、いつこのプロジェクト止まっちゃうのかなみたいなのあるじゃないですか。

で、全部オープンソースなってればじゃあいいかって言うと、その人も書いてたんだけど、さすがにねコンパイラとかになると、オープンソースだからっていってそのプロジェクト止まったから引き継ごうとか言っても簡単に引き継げないんですよね。ハードルが高くて。それがそのWebフレームワークとかで直して使ったりできるんでしょうけど。だからそういう意味でRubyMotionぐらいのものだったらお金払ってもいいかなってのが僕の感覚ではあるんですよね。

miyagawa: なんか昔PerlでCocoaのGUIを書くCamel Bonesとかいうのがあって(笑)

naoya: ありましたね(笑)

miyagawa: あれもでも作者の人がやる気なくなって、誰もメンテしてなくなっちゃったりしたから、オープンソースだからいいってもんでもないってのは、その通りなんですよね。

naoya: なんかオープンソース、MacRubyが6年ぐらいオープンソースにしてたけど、結局コントリビューターがなんか4人か5人ぐらいしか6年でいなかったって言ってて、オープンソースになってれば、それだけでソフトウェアが発展してくなんてことはないんだっていうのはその人のインタビューに書いてましたけど。

miyagawa: なるほど。

naoya: ほんとその通りだなとは思いますね。

miyagawa: ただSublime Textとかも僕最初ちょっと試したんですよ。まあ1日2日ぐらい(笑) なんかでもエディタに金を払うっていうのが、今までの話とすげー矛盾してるんだけど、なんか若干気に食わなくて(笑)

naoya: (笑) それはあれじゃないですか、代替するものがたくさんあるからだと。

miyagawa: もうすでにEmacsで慣れちゃってるからってのはあるんですけどね。

naoya: Sublime Text、使ってます?

miyagawa: いや、今真面目には使ってないです、全然(笑) 1日,2日ぐらい使って。

naoya: (笑) もう何回使ってもスイッチできないですよ。

miyagawa: Pythonでプラグイン書けるのいいなと思いましたね。

naoya: 確かに。Lisp書くぐらいだったら。

miyagawa: やっぱりElispは、Elispでコード書くのもそうだし、設定ファイルがElispっていう時点でかなり、萎えるわけですよね。

naoya: 止めます、Emacsの話(笑)

miyagawa: (笑)

naoya: 全然こう2013年に相応しくない話。

miyagawa: 相応しくない(笑)

naoya: (笑)

39:44

miyagawa: Rubyの話出てきたから、先週Rubyの新しいVMのTopazっていうのが出てて。これは何をするものかっていうと、Rubyって今、Matzの作ったMRIっていうCRubyとも呼ばれてるんですけど、本家のRubyと、JVMで走るJRubyっていうのと、あとはRubiniusっていう、えーと、最初はこれはRubyで書かれたVMなのかな、Ruby自体は。だけどもう最近はそれをもっと超えて。あとCレベルの互換性も多少あるっていうVMがあって、で、新しく出てきたTopazっていうのが、これはPythonのPyPyと同じ仕組を使っていて、実際にRPythonっていう、PythonってのはPythonで書かれたPythonVMなんですけど、実際にこのコンパイルしたものを動かす為のRPythonっていうサブセット言語があって、でTopazはそのRubyをこのRPythonにコンパイルするっていうVMなんですね。

naoya: RPythonってあれなんでしっけ。JITが、Just –IN-Timeコンパイラ、あれが載ってる。

miyagawa: そうそう。だからPyPyは今。

naoya: 速くなるっていうあれなんですよね。

miyagawa: そう、実際の今CのPythonよりも、ものによっては速くなることがあって。JITが効くから。で、だからRubyのTopazも、単純なそのフィボナッチの計算とか、そういうものRubyで書いてTopazでコンパイルしてRPythonで動かすと、Cよりも、JRubyよりも全然速いっていうのがあって。

41:21

miyagawa: なんかそういうふうにいろんな実行系が出てきてるのがいいなあと思っていて。なんでいいなあと思うかっていうと、Perlっていうのは僕らのホーム言語なんですけど、今はまだ一個Perl5しか実行系がないんですよね。で、Perl6の方はいくつか実装があって、昔あのAudrey Tangが作ってたPugsってHaskellで書かれた実行系があって、これはもうちょっと最近はもうメンテナンスされていない状態なんですけど。

今メインなのはRakudoっていうCで書かれたParrotの上で動くものと、あとはNieczaだったかな。っていうもう一個あって。Perl6はそういうふうに複数の処理系が出てきてるんですけど。Perl5はなかなかそういうふうにならないと思っていたところに、1ヶ月ぐらい前に、あのStevan LittleっていうあのMooseを作った人が新しくVMを書き始めていて、これがScalaで書かれている、Moeっていう、エム・オー・イーと書いて。

naoya: ちょっとね、日本人的にググラビリティが(笑)

miyagawa: (笑) ちょっと萌え~みたいな感じになっちゃうんすけどね、そうそう。それが今ちょっと盛り上げてかけてる感じかなっていう。実際これが成功するかどうかはすごく疑問点はもちろんあるんですけど、やっぱりその、Perlの一個弱いところの一つにその並行処理、並列処理っていうのがあって。

スレッドとかPerl5、5.6、5.8とかでいろんなネイティブスレッド使う方法とか、ithreadsって言って、forkしてエミュレータを立ちあげて、なんかスレッドをエミュレートするとかいろんなやり方があったんだけど、このMoeはScalaを使ってるイコールJVMなんで、Javaのスレッドがそのまま使えるっていう。

naoya: ああ、それは大っきいですね。

miyagawa: うん。

naoya: そうなんです。

miyagawa: そこは今面白い。一個盛り上がってる点の一つはParrotとかRakudoとかと違う、やり方、アプローチが違うのはそのJVMがホストをするっていうところ、になってて。まあ上手くいくかどうかちょっとわかんないんですけど、こういうのがPerl5にもやっとできてちょっと、いい感じかなっていうふうに。

naoya: なるほど、そっか。スレッドが作れるのは大っきいですね。ほんとにPerlのithreadsとか、あれは何だったんだっていう(笑)

miyagawa: (笑)

naoya: あれ一応なんか言語標準の機能として。

miyagawa: うん、ありますよ。で、だからthreads.pmってのがあって、それを使うと一応そのその辺は隠蔽してくれるんだけど。

naoya: いや、全然でもまともに動かないじゃないですか。

miyagawa: 動かない、うん。

naoya: なんか変数も全部コピーしてるし。

miyagawa: で、Rubyのスレッドっていうのも、ちょっと多少、いつもRubyのスレッドの話をすると、なんかグリーンスレッドだから、ジャイアントロックがあって一個しか同時には動かないとか、いろいろあるんですけど、でも、プログラマーの視点から言うととりあえずスレッドで書けるじゃないですか、なんとなく。

naoya: そのー、そうですね。っていうかちゃんとバランスが取れてるというか、それトレードオフもちろんあるだけど、一応ちょっとしたことやる時に使えるレベルではあるんですよ、これは。

miyagawa: そうそう、実際にその並列処理ネイティブとマルチスレッド書こうと思ったら、そのRubyの本家のスレッドでは無理なのかもしれないけども、なんとなく並列した処理をこう一個のプログラムの中で、例えばプロデューサーコンシューマーみたいなことをやりたい時には簡単にできるんですけど。Perlだとそれがね、なかなかできなくて、変な自分でforkするプロセッサー書いたりとか、あるいはイベントモジュール書いて、イベント・ドリブンで書き直すとかなっちゃうんで、なかなか辛いとこがあるんですよね。

naoya: しかもithreadsなんかあれ、裏っ側でpthreadsとリンクしてて、普通にネイティブスレッド立ち上げようとするんでよね。

miyagawa: それたぶんコンパイラオプションかなんかあるんですよね。

naoya: あ、そうか。

miyagawa: ビルドする時にその辺も指定できて。

naoya: 変にだから、そういうところその、グリーンスレッドじゃないふうにこう実装しようとしたりして頑張り過ぎちゃって、あれってその、バランスの悪いものができちゃってるっていう印象だったんですけど。

miyagawa: 確かに。ま、たぶんそういう感じだと、だから誰もみんなスレッドをシリアスに捉えないというか、Perlのスレッドなんて誰も使ってないっていうスタンスな感じですよね、だいたいが。まあそこら辺も含めてなんかJVMでホストするっていうのが現実的にもしなってきたら、面白いなあっていうふうに思っていたりしますね。

naoya: 実際その、なんていうか僕そういうものほとんど作ったことないのでわかんないんですけど、Rubyとかの方がそういうサードパーティの実装が出やすくって、Perlとかはあんまり出ないっていうのはやっぱparserのあそこの処理を再現するのが難しいとかそういうのが原因なんですかね。

miyagawa: 一つはあるでしょうね、それがね。たぶん。

naoya: parserが非常に大変だって話をよく聞くんですけど。

miyagawa: PerlのparserはPerlしかできないっていう(笑)。

naoya: (笑)

miyagawa: のがあるから。一応ね、Yaccで文法は定義されてはいるみたいですけど。あと、Perlの実験的なオプションでビルドをすると、コンパイル、parseした後のツリーをXML形式で吐くっていうオプションはあるんですよ。だからそれをまずやって、そっからビルドツリーからは自分で別の言語にコンパイルするっていうのが、やり方としてあると思うんですよね。

46:43

miyagawa: で、なんかPerlがらみ、最後になると思うんですけど、Perlがらみでなんか先週ぐらいにちょっと炎上した話があって。

naoya: 炎上。

miyagawa: うん。なんかPerlの話が例えば、Hacker NewsとかRedditとかSlashdotとかなんでもいいんですけど、出ると、だいたいみんなPerl6いつ出るんだって話になるんですよね(笑)

naoya: (笑) ああ、そうなんですか(笑)

miyagawa: で、この話たぶん去年のYAPCのパネルディスカッションで、naoyaさんと僕が出たやつで似たような話したんですけど、要はPerlコミュニティの外の人から見ると、Perlの次のバージョンはPerl6だって思われてるんですよね。

で、Perl6っていうのは2000年ぐらいに開発が始まって、もう13年経ってるけど、まだ使えないと。だからもうPerlは終わったってみんな言う(笑)

naoya: (笑)

miyagawa: わけですよ(笑) で、それがみんなPerlコミュニティの人はすごくそれがフラストレーションだから、3、4年ぐらい前にPerl5の開発コミュニティとPerl6コミュニティがちょっと話をして、Perl5と6は別の言語だよねっていう合意というか、みたいなのをして、要はPerl5っていう言語はそのまま開発が続けられていて、今も毎年リリースされていて、Perl6っていうのは姉妹みたいな、別言語であって、5の次が6じゃないよねっていうのはPerlの人たちの間では結構知れてきてるんですよ、だいぶ。

だけどそれも、その合意についても外の人は知らないし、相変わらず毎回その話になるから、っていって。毎年この話が盛り上がるのは、じゃあPerl5の次の、Perl5、今5.16が最新バージョンなんですけど、次じゃあ5.18、で次が5.20って、一応奇数番号が開発版で、偶数が安定版なんですけど、じゃあ5.18とかやめて5.20やめて、Perl7にしちゃえばいいんじゃないかっていう。

naoya: (笑)

miyagawa: 話が毎年出て。あるいは7じゃなくて、2013とか、要はOfficeみたいに。

naoya: (笑)

miyagawa: 年号をバージョン番号にして。

naoya: ださいな、それ(笑)

miyagawa: っていうのはどうだみたいな話になって。で、例えばLinuxって、この間3になったじゃないですか。

naoya: はい。

miyagawa: だけど別になんか大きな機能が追加されたわけじゃなくて、なんかもう3でいいよね,、みたいな感じで。なんかLinusが適当に次3だって言って3にしたって感じがあって。で、一応それによってこうメディアもちょっと、「あ、3が出た、メジャーバージョンアップだ」っつって、ちょっと記事が出たりとかするから。例えば、Perl5の次のメジャーバージョンを7にしたら、今まで6が出ないって馬鹿にしてた人もとりあえず、あ、7が出たんだっていうふうに(笑)

naoya: (笑)

miyagawa: なるんじゃないかっていう。これはその思考実験みたいな感じで、やったんですけど。当然、かなり炎上して、Perl5の開発本家の人たちはもうそんな子供騙しみたいなことをするよりも、ちゃんとこう良くしてく方が大事だとか、7になったからってこう見るような人は、もとからもうPerlのことなんか気にしてないから、そこにやっても無駄だみたいな意見とか、いろいろあって。結局収束して7はやめようみたいなことになったんですけどね(笑)

naoya: (笑) なるほど。まあね。Perlっていうこう言語の未来というか、マーケティング的な意味での未来って結構不安なところがたくさんありますからね。

miyagawa: 一応そのPerl5って、-v って打つと、Perl 5 Version 16って出るんですよね。だからPerl5が言語名で、バージョンは16っていうふうに一応なってるんですよ(笑)

naoya: なるほど(笑)

miyagawa: そう。

naoya: そんなのわかんないですよね(笑)

miyagawa: だけど、リリースする時はだいたい5.16って言ってリリースするから。

naoya: それあれですよ。僕、最近Python全然見てないんですけど、Python3と2.6でしたっけ。が、どう状況なのかが全く外から見てるとよくわかんないけど、時々未だに3がまともに使われてないみたいなのが揶揄されてるのを見て、えーって思うみたいなのと全く同じ状況ですよね。

miyagawa: そうそうそう。でも例えばRubyの話で言うと、Rubyって、Perlよりも更に言語のそのメジャーバージョンアップが一桁更に小さくて、1.9.2から1.9.3がメジャーバージョンアップだったりすんですよね(笑)。で、1.8から1.9ん時はものすごく変わったし。で今度2.0が、次が2.0なんですけど、これはほとんど1.10みたいな感じで。だけど、なんか、二桁目に二桁の数字、10を使いたくないっていう理由でたぶん2.0にすると思うんですけど。だからあんまりね、こうバージョンで一瞬だけアテンションは惹けるかもしれないけど、結構なんかそれ名前を変えるだけでは難しいのかなっていう気もしていて。

naoya: (笑)

miyagawa: なんかでも、たぶん、Perlの場合、結構後方互換性にものすごい気使ってるから。昔、例えば10年前に書いた5.6用に書いたスクリプトとかも普通に動くわけじゃないですか。いつそこをやめれるかっていうのが結構でかいんじゃないかなと思ってて。そのバグ互換性みたいなところとか、シンタックスをこれ以上拡張できないとか、そこら辺を捨てた実装が、例えばさっきのMoeみたいなところから出てくると、もうちょっと面白くなるのかなっていう気はしているんですよね。

naoya: 逆にだから本体がそういうこうアグレッシブなことをするんではなくて、そのJVM系の実装とか、そっち側でそういうものを使いたい人が上手くこう移っていくというか、できればわりといいんでしょうけど、本体でそのそういう後方互換性切り捨てたアップグレードとかはやった瞬間に、なんかもうPerlを使う理由すらもうないわ、みたいな人がたぶんたくさん出てくるんですよね。

miyagawa: いや出てきますよ、絶対、うん。

naoya: それってたぶん絶対言語コミュニティにとってマイナスなんで、そこはやっぱり無視できないとは思うですよ。うん。

miyagawa: ですなー。

naoya: うん。


Transcribed by: @akiyan http://www.akiyan.com/