miyagawa naoyaさん、最近は結構ブログが活発になってきている感じですね。
naoya はいはい、そうですよね。
miyagawa なんか、心境の変化があったんですか。
naoya 心境の変化(笑)
miyagawa (笑)
naoya いやずっとドラクエしかしてなかったんですけど(笑)
miyagawa (笑)
naoya いやそれで、最近ちょっと、まあなんか作ったりしてるので。結構一人で作ってるんで、あんまり「こういうことやった」みたいなことを、他人に共有する機会が無いんですよ。
miyagawa うんうん。
naoya そうすると、なんかブログに書いてみようかなって気になって。久しぶりにブログを更新してみたら、案外面白いな、みたいな。そういう心境ですね。
miyagawa うん。あれですよね、大きい企業とか、特にGoogleなんかに入ると、急にブログのアウトプットが無くなるみたいなの、よくありますよね。
naoya ああ、そうそう。ありますねぇ。まあ単純に、僕の場合は前職で忙しかったっていうのはあるんですけど、Googleとかだと、話を聞いてると、職場の中で承認されちゃうっていうか。
miyagawa うんうん。
naoya 技術的にもすごいねって話をみんなでしちゃうから。
miyagawa そうなんですよね。なんかね。
naoya なんかね、コードの隅々まで見てもらって満足しちゃうみたいなのはあるかと。
miyagawa その逆パターンで、職場とかで満たされないものが出てくると「ブログに書いてアウトプットしたくなってくる病」みたいなのは、結構ありますよね。
naoya そうそう。そうですよね、まさにそんな感じです。
miyagawa (笑)
naoya (笑)
miyagawa あれですねー、僕も最近、podcastとかをね、海外のpodcastを、まあ昔からずっと聴いてたんですけどpodcastが最初に出てきたのって2004年とか5年くらいなんですよね。
naoya そうですね。
miyagawa で、当時はCNETとか英語のブログとかのpodcastを聴きつつ、まあ日本でも盛り上がってきたのがここ3,4年くらいで。でも、盛り上がってるのが個人のpodcastとかじゃなくて、大体がニッポン放送とかTBSラジオとか、なんかそういうのの、ラジオ番組のおまけみたいなのをやってるのが多くて。
naoya うん。
miyagawa なんかもうちょっと、いい使い方ないかなーと思っていたところに、ここ半年くらいアメリカのほうで、個人とかがやってるインディーpodcastネットワークみたいなのがいくつか出てて。あとでこの記事をアップするときに、リンクを貼っとくんですけど、5/5っていうネットワークとかミュールラジオとかっていう、なんか、著名なブロガーの。例えば、マルコアーモンドっていう元tumblrのCTOで、今はinstapaperとか作ってる彼とか。あとジョンシラキューサっていうのが、アンステクニカでMac OSXの記事を書いてる人で、そういうなんかブロガーの人とかが結構、個人のpodcastで、色々と、週に1時間とか30分とか話してて、結構面白くって。そういうのを日本語でもあったらいいのになーと思って。
naoya なるほど。彼もあれですよね、instapaperの人も一人で開発とかやってるんですよね。色々読みましたけど。
miyagawa うん、ほとんど一人で、自分で開発をしているみたいです。特にiOSのアプリとか、ウェブサイトに関しては全部一人でやってて、こないだinstapaperのAndroid版が出たやつに関しては、「自分でAndroidの開発は絶対にやりたくない」って言ってて。
naoya (笑)
miyagawa だから、レベニューシェア的なのでアウトソースしてるみたいですね。
naoya あ、そうなんだ。
miyagawa やっぱりその、(彼は)個人的にはすごいiOSのファンというのもあると思うんだんだけど、まあ、ユーザーベースが増えてきて、だんだん無視できなくなってきたけど自分でやりたくないみたいな、そういう感じだったんでしょうけどね。
naoya そういう人がpodcastとかやってる感じなんですね。
miyagawa 僕の他のpodcastを見てくれてた人がいるかもしれないですけど、僕、他にも、ドリキンがやってるドリキンTVっていうの(podcast)にも出てて。これ別に、なんか問題があって別の(このpodcast)を始めたっていうんじゃなくて、全然なんか違う感じでやってみようかなと思って。オーディオのみってのもあるし。あと、ネタとかももうちょっと開発寄りとか、techとか。向こうの番組はなんか、techネタもそうだけど、ガジェットとかが中心なんですけど。もうちょっとなんか、ウェブサービス全般とか、開発に突っ込んだ話とかそういうのもできたらいいなーとか、思ったりしているわけです。
naoya はい。
miyagawa 最近の、naoyaさん的に盛り上がってるのは、LTSVってのに盛り上がってるぽいですね。
naoya LTSV、盛り上がってましたねw あれなんででしょうね(笑)
miyagawa (笑) 簡単に説明してもらっていいですか。
naoya LTSVは、まあ、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をパースしたあとに型をマッピングさせるのがすげーめんどくさいとか思ってたんですけど。まあ最近こういう感じでダイナミックにできるんだなーとか、面白かったです、見ていて。
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 結構、炎上マーケティング的なやり方をしようとしてたけどw
naoya (笑) ま、でもね、実際こう、英語のニュアンスで、どこまで、なんていうか、こう、ひどいタイトルをつけるというのも自分ではよく分かんなくって。
miyagawa いやでも本当ね、Twitterできょうと(？)さんとかが言ってたけど、そういう釣りタイトルでHacker Newsにpostするってよくやってる人いるんですよね。
naoya あーそうなんですね。
miyagawa それで釣られて読めば儲けモンみたいな。
naoya うん。
miyagawa でも最近Hacker Newsって、まあ、最近に始まったことじゃないんですけど、Geek向けはもちろん、スタートアップ関係の人たちとか、すごい、読者層が(厚くて)、リーチが多いんで。Hacker Newsのトップページに、ちょっと何十分、一時間載るだけで、やっぱりものすごい露出にはなるみたいですね。
naoya そうですね。まあ、昔の、某は(ry「某ソーシャルブックマーク」(笑) な感じですよ。
miyagawa (笑)
naoya まさに、ほんとに。
naoya あの、エンジニアばっかりが（某ソーシャルブックマークを）使ってたような時期があったじゃないですか。
miyagawa そうねー、まあ僕は前の会社はY Combinatorに出資を受けてたような会社なんですけど。ドットクラウドっていう。そこのブログ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とかだと、サブRedditってのがあって。
naoya なんかあのタグきれるやつですよね。
miyagawa そうそうそう、例えばReddit/Perlとかやったら、Perlのネタしかpostできないっていう。というふうになっているから、まあはてブとかも多分、そういうふうにしていくって方法は多分あったと思うんですけどね。
naoya うん、けどその、なんていうのかな、Hacker Newsみたいにあんまり難しいこと考えなくても、そこに行くと全部あるみたいな状況の方が分かりやすいし、トラフィックも集まりやすいから、Redditみたいにその分散しちゃうと、結構ニッチというか。まあ、2ちゃんねるみたいな感じになっちゃうんで。
miyagawa 確かに。
naoya だから、そこのバランスみたいなのはあると思うんですけど。
miyagawa Redditは、なんていうか、タグコミュニティになって本当狭い感じなんですよね。
naoya うん、そう。？？？(聞き取りできず)は、たまたまそういう感じで乗っかってったっていう。で、それ以外に、まあ普通に、エンジニアリングしてて、やっぱり、このへんがっていうのが、まあなんだかんだいってやっぱクラウドと。あと最近RubyMotionていうあのiOSのやつをよく触ってるんですけど。RubyMotionとクラウドと、あとなんですかね。まあでもその2本がやっぱり大きいかなって気はしますね。
miyagawa クラウドの話っていうのは多分、ひとりで開発してると、大きな会社でデブオプスとかITとかシスアドミンと呼ばれるような人たちがいるようなところを含めてひとりでカバーできる、多分、時代になってきてるから。
naoya そうそうそう。
miyagawa その辺を、こう、手を出してみてるって感じですか。
naoya そう、実際は、あの、自分で作ったサービスをEC2でも動かすのであって、で、今いろいろいじってるとノウハウもたまってくるので。それを吐き出したりというのもあるし。あとAmazonは動きがすごい早いんで、追いかけているうちにどんどん知識がたまっていくみたいなのもありますけどね。
miyagawa うん。
naoya あとは、実際そのchefとか、そういう自動化とかもするじゃないですか。その辺、単純にクラウドを、EC2を使ってるっていうんじゃなくて。まあ、さっきデブオプスていうのがありましたけど、それをこうガーッと１人でやってくと、なんか「楽しい感じだな」みたいな。
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 それがね、結構、積み重なってきて。最近結構すごいなーと思って見ている感じですね。
miyagawa こないだ紹介してたやつは、vagrantでしたっけ。
naoya そうですね、はい。
miyagawa あれとかも、VM自体をもバージョン管理して、立ち上げて、それの中でもchefとか、puppetとかを走らせて、みたいな。そこらへんも含め全てスクリプト化して、再現できるようにするみたいな感じですよね。
naoya そうそうそう、あのvagratはなんか、berkshelfっていうのかなー、なんかそのbundlerみたいなのがセットになってくっつけられて、それを使うともうコマンド一発でVMを立ち上げた層だから、そのchefのレシピも元から全部持ってきて、インストールして、立ち上げる所まで、一気通貫で、やるとかっていうこともできるので。まあここまで来るとなんかもう、仮想化とか、ハードウェアとか、全く存在を感じないみたいな、感じになってきてますからね。
miyagawa うん。
naoya いやー、すごいと思います。
miyagawa そこでやっぱり、chefとか、そこに行くっていうのはなんか凄いと思って。大抵の人は多分、そういう存在は多分知っているのも、そうじゃないのも、もしかしたらあるかもしれないけど、herokuとか、.cloudみたいに、そういう環境を提供してくれる、まあPAASですよね、Platform as a serviceの方を使って、「あーなんだこれ便利じゃん、これでいいじゃん」て、大体の人が。それでラクしすぎて、「あーこれ以外で自分でデプロイすんのも面倒くさいわ」ってなると思うんだけど。
naoya まあ自分の場合はあれですよね、昔、そういうオンプレミスで自分でそういうところをやってたんで。なんていうのかな、それがこう、これだけ自動化されるっていうことはスッゲーな、みたいな。もう興味が強いっていうのはありますけどね。
miyagawa 僕も前、今、cpan minusっていうソフトウェア、CPANのモジュールをインストールするソフトなんですけど、これがもともとのCPANクライアントよりすごく動作が軽くて速いひとつの原因は、mirrorの部分を、今までの、元々のクラアントだとmirrorのファイルをまず全部ダウンロードしてきて、tarballをまず展開して全部parseして、で、ローカルのDB、フラットファイルだったりsqliteだったりするんですけど、そこに入れるっていうのが毎回やっていて。まあそれがだいたい15秒とか30秒とかかかるんですけど。それを全部クラウド側っていうか、サーバー側にしたっていうのがあって。で、そのサーバーは、最初はGoogleのApp Engineで動かしてたんですね。Pythonで書いてw
naoya うん。
miyagawa まあ当時それしかなくて、Herokuはあったと思うんだけど、なんとなく、Pythonを仕事でやってたっていうのもあったから。まあ、App Engineでいいじゃんと思ってずーっと走らせてたんですけど、ある日、App Engineが有料化することになっちゃって(笑)
naoya (笑)
miyagawa で、無料のだとほとんどトラフィック捌(さば)けないから、Googleの知り合いの人にQuota上げてって言ったんだけど、ちょっと、駄目で(笑)
naoya (笑)
miyagawa しゃーないっつって重い腰を上げてPerlで書いて、まあ、コード自体はほんと、1時間くらいで書けたんで。さあどこにdeployしようと思って、そのときはまだ.cloudとかherokuがPerlをサポートしてなかったから、うーんっつっって、まあlinodeにインスタンスを立てて。でもそのときはまだchefとか、puppetとか知ってたんだけど、そこまで便利にできるものって知らなかったんで。自分で、rootアカウントを作って、アプリを動かすようなユーザーを作って、Perlの最新版をインストールしてとかやって。今考えるとスゲー面倒くさい、まあそのときも面倒くせーと思ってたんですけど(笑) その辺も含めて全部自動化できたと思うし、やっぱりそういうふうになってきているんだろうな、っていう。
naoya そうですよね。こないだなんかのドキュメントを読んでたら、そういうデブオプスの自動化の文脈って、自動化したら便利だからっていうのもあるんだけど、一方でクラウドになって色んなものが複雑になったりとか繰り返しやらなきゃいけなくなったから、っていうのも背景に、逆にあるんですよ。
miyagawa うん。
naoya うん、だから、やっぱクラウドで、EC2とかを触ってるとインスタンスを止めたり立ち上げたりとかしまくるんで。そうするとその一回一回そのユーザー作ったりとか、アホくさくなってくるんですよね、やっぱり、やってると。だからその自動化しようっていうモチベーションが湧きやすいっていうのも、絶対あると思うんですよね。
miyagawa でしょうね。
naoya でも昔ね、僕も、はてなにいたときに、stanakaさんがpuppetを使い始めたときに、全然わかんなくってw 複雑で。「こんなもん使うか！」って思ってたんですけど、まああれから年月が経ったら結構みんな使うようになったなーみたいな(笑)
miyagawa (笑) やっぱりでもシスアドミン系の人とかは多分そういうのを昔から、puppetとかcfengineとか(笑)
naoya cfengine(笑)
miyagawa cfengineとかほんと地獄みたいな感じだけど。そういうのと、多分、デスクトップで開発していたサーバーサイドのエンジニアの人たちのマインドセットが、合流して、ああいうツールがどっちからも使いやすいみたいなのが、多分、できたのかなっていう。
naoya ああ、それがまさにデブオプスっていう言葉だと思うんですけどね。
miyagawa うん。
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の、なんだろ、例えば、”set modal dialong なんとかかんかdismiss true”みたいな、そういう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のコミッターのワトソンさんっていう人が一人、日本人の人がいて。コミッターっていうか実際もう今一緒に作って働いてるんですけど、ワトソンさん東京にいるんでよく会うんですよ。で、これなんかライセンスフリー版とか作んないんですかって言うと、まあ仕組み作ればできなくはないけど、今そっちよりも他にやることがたくさんあるんだとか言ってました(笑)
miyagawa たぶん教育用とか、学生向けとかっていうのでは、安いライセンスのもの出したりとかっていうのはしてるみたいな、問い合わせ先みたいなのはあったんで。
naoya あ、そうですか。
miyagawa うん。たぶん、あとサイトライセンスみたいな感じで、そのまあ大きい企業がもし100人単位のエンジニアがいて、それを100人分買うのはたぶんすごい出費になっちゃうけども、っていう部分はたぶんやったりとかしてるんだろうけど。まあでも個人でもね、まあ100ドル、まあiOSのディベロッパーになるのにAppleにいくらか払わなきゃいけないわけだし、そこら辺の生産性を上げてくれると考えれば、妥当かどうかはわからないけどそういう出費を勿体無いと思ってもしょうがないっていうのは、ケチってもしょうがないっていうのはありそうですけどね。
naoya 一応その開発者のインタービューがあって、なんでその有料なのかとか、オープンソースじゃないのかみたいな話しが載ってて、昔MacRubyを作ってた人なんですよね、Appleで。なんだけど、まあAppleが（聞き取れず）、MacRubyのスポンサーがMacRubyにもう投資し続けるの、興味がなくなって、で、それでMacRubyプロジェクト自体がどうしようかみたいな状態になったらしいんですよ。それがきっかけで会社を辞めて、RubyMotionやるかどうかっていうところにいって。
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 (笑)
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よりも全然速いっていうのがあって。
miyagawa なんかそういうふうにいろんな実行系が出てきてるのがいいなあと思っていて。まあなんでいいなあと思うかっていうと、Perlっていうのは僕らのホーム言語なんですけど、今はまだ一個Perl5しか実行系がないんですよね。で、Perl6の方はいくつか実装があって、昔あのAudrey Tangが作ってたPugsってHaskellで書かれた実行系があって、これはもうちょっと最近はもうメンテナンスされていない状態なんですけど。今メインなのはRakudoっていうCで書かれたParrotの上で動くものと、あとはNieczaだったかな。っていうもう一個あって。まあPerl6はそういうふうに複数の処理系が出てきてるんですけど。Perl5はなかなかそういうふうにならないと思っていたところに、１ヶ月ぐらい前に、あのStevan LittleっていうあのMooseを作った人が新しくVMを書き始めていて、これがScalaで書かれている、Moeっていう、エム・オー・イーと書いて。
naoya ちょっとね、日本人的にググラビリティが(笑)
miyagawa (笑) ちょっと萌え～みたいな感じになっちゃうんすけどね、そうそう。それが今ちょっと盛り上げてかけてる感じかなっていう。実際これが成功するかどうかはすごく疑問点はもちろんあるんですけど、やっぱりその、Perlの一個弱いところの一つにその並行処理、並列処理っていうのがあって。
miyagawa まあスレッドとか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のスレッドなんてまあ誰も使ってないっていうスタンスな感じですよね、だいたいが。まあそこら辺も含めてなんかAVMでホストするっていうのが現実的にもしなってきたら、面白いなあっていうふうに思っていたりしますね。
naoya 実際その、なんていうか僕そういうものほとんど作ったことないのでわかんないんですけど、Rubyとかの方がそういうサードパーティの実装が出やすくって、Perlとかはあんまり出ないっていうのはやっぱparserのあそこの処理を再現するのが難しいとかそういうのが原因なんですかね。
miyagawa 一つはあるでしょうね、それがね。たぶん。
naoya parserが非常に大変だって話をよく聞くんですけど。
miyagawa PerlのparserはPerlしかできないっていう(笑)。
naoya (笑)
miyagawa のがあるから。一応ね、Yaccで文法は定義されてはいるみたいですけど。あと、Perlの実験的なオプションでビルドをすると、コンパイル、parseした後のツリーをXML形式で吐くっていうオプションはあるんですよ。だからそれをまずやって、そっからビルドツリーからは自分で別の言語にコンパイルするっていうのが、やり方としてあると思うんですよね。
** miyagawa ** で、なんかPerlがらみ、最後になると思うんですけど、Perlがらみでなんか先週ぐらいにちょっと炎上した話があって。
naoya 炎上。
miyagawa うん。なんかPerlの話が例えばまあ、ハッカーニュースとかエディットとかスラッシュドットとかなんでもいいんですけど、出ると、だいたいみんなPerl6いつ出るんだって話になるんですよね(笑)
naoya (笑) ああ、そうなんですか(笑)
miyagawa で、この話たぶん去年のYAPCのパネルディスカッションで、naoyaさんと僕出たやつで似たような話したんですけど、要はPerlコミュニティの外の人から見ると、Perlの次のバージョンはPerl6だって思われてるんですよね。
miyagawa で、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 って打つと、Perl5 Version16って出るんですよね。だから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 うん。
[終わり]
さんろんかん(？意味わからず)
→ 3年間