「私がJuliaを推す理由」（翻訳）
Juliaについて書かれた海外のブログ記事でとても共感したものがあったのでブログ主に無断で翻訳したものを掲載します。（もし問題ありましたらご連絡ください。）
このブログの著者はEvan Miller氏というソフトウェア開発者でWizardというかなりイケてそうな統計分析パッケージソフトを専業で開発している人みたいです。フリーランスなのかな。考え方も環境もそしてもしかしたら年齢も僕と似ている人なのかもしれない。
「私がJuliaを推す理由」（2014/1/23）
殆どのプログラミング言語の問題はそれらが言語ギークによってつくられていることだ。彼らは私ならほとんど気にしないようことに傾注しがちだ。安全性、型システム、同図像性、などなど。私はそういうものが確かに素晴らしいと思ってはいるが、新しい（訳注：そういう新プログラミング言語とかの）プロジェクトを興味本位で漁ってみる際に関心があるのは（１）役に立つか（２）速いか の2点だ。私にとってはコードは車みたいなものだ。つまりそれは目的値への手段なのだ。コード片が持つ”expressiveness(表現力)”はいわば排気ガスの三元触媒がもつ"expressiveness（訳注：一石三鳥的な意味合い）"みたいな重要さだ。
このアプローチでのプログラミング（訳注：一行のコードの表現力が高いことを重視してコードのかさを減らすようなスタイルのことだと思われる）はしばしばカウボーイスタイルだなんていわれたりする。カウボーイってのは私は正確なイメージじゃないと思うんだ。だってカウボーイは馬を相手にするから馬の都合で時々休んだりしなければならないじゃないか（訳注：こういうウィット好き）。もっと向上心を感じさせるイメージ、それは精巧につくられた機械装置、それも出来たばっかりで最初に使った人が火を被るようなもの、それに数週間も取りつかれちゃった研究者がラボの中で目が充血し疲れ果てて青白くなっているような感じかな。
まぁ私の好みについての話はもういい。普段私は何かを作る言語を第一言語として、それと作ったものを高速化する言語を第二言語として、そしてちょっとそれを悲鳴を上げるほど面白くするための言語を第三言語として使っている。そういう使い分けは、なかなか良くあるパターンだ。多くのプログラマにとってプロトタイピング用の言語はPython,Ruby,もしくはRだ。いったんコードが動いたら、こんどは遅いところをCやC++で書き直す。おかしい人になるとCのループをアセンブラやCUDAやOpenCLで書き直しちゃったりする。
しかし好ましくないことに、プロトタイピング用の言語とC/C++の間には大きな壁があるそしてC言語とアセンブラの間にもまた大きな壁がある。職を得るために３つ言語を習得した上に、それらの壁を超える時に意識のスイッチが必要になる。もっと身近なケースでいうと、壁を超えるためにグル―コード（訳注：複数のプログラミング言語のコードをつなぐためだけに使うコード）をたくさん書く必要があるし、ソースファイルやエディタやデバッガもそれぞれ別で切り替えなければならなかったりする。
私が少し前にJuliaについて読んで、これはクールだと思ったんだけど、すぐに使わなければいけないものでもないと思った。Juliaはパフォーマンスがグレートな動的言語だ。それはいいと思ったが、既に私はフォルクスワーゲンのビートルみたいな車にフェラーリのエンジンを搭載するようなことをさんざんやってきているから、なぜ新車が必要なんだ？みたいなことを思った。それに今は色んなプラットフォーム いくつか挙げるならJava HotSpot, PyPy, asm.js、そういうのがC言語と同等のパフォーマンスを他の言語でも実現するとうたっている。
そのちょっと後で、私はJuliaが他の言語と決定的に違う点に気づいた。Juliaは２番目の壁を打ち破る、つまり高い抽象度のコードとネイティブアセンブリの間の壁を超えるものだということだ。C言語と同等のパフォーマンスを出すコードをJuliaで書けるだけじゃなく、どんな関数でもLLVMの中間言語コードとさらにそれがアセンブリコードにどう翻訳されるかを見れるのだ。しかもREPL（インタプリタの対話環境）。ちょっと試してみよう。
emiller ~/Code/julia (master) ./julia
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_) | Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type "help()" to list help topics
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.3.0-prerelease+261 (2013-11-30 12:55 UTC)
_/ |\__'_|_|_|\__'_| | Commit 97b5983 (0 days old master)
|__/ | x86_64-apple-darwin12.5.0
julia> f(x) = x * x
f (generic function with 1 method)
julia> f(2.0)
4.0
julia> code_llvm(f, (Float64,))
define double @julia_f662(double) {
top:
%1 = fmul double %0, %0, !dbg !3553
ret double %1, !dbg !3553
}
julia> code_native(f, (Float64,))
.section __TEXT,__text,regular,pure_instructions
Filename: none
Source line: 1
push RBP
mov RBP, RSP
Source line: 1
vmulsd XMM0, XMM0, XMM0
pop RBP
retうぉ、１行の関数を書いてからLLVMで最適化されたx86アセンブラコードを確かめるまで２０秒もかからずに出来てしまった。
なのでJuliaについて調べると出てくる型システムや多重ディスパッチや同図像性などの特徴のことは忘れちゃっていい。そういうのはクールだと私も思ってるけど、私と似たタイプの人にとっては最初にプロトタイプを作ってからマルチコアやSIMDでパフォーマンスを最適化するまでをJuliaだけで出来ちゃうのが現実的なベネフィットなのだ。
端的に言えば、私がJulia推しなのはそういうわけだ。この話を他と対比させるのはあんまり気が進まないのだけど、いってみればこれはNode.jsがWebシステム開発でやっていること、つまり全然違うグループのプログラマが同じ言語を使ってるということ、それと同じことを科学技術計算でやるということだ。Node.jsのおかげでフロントエンドのデザイナとバックエンドの開発者が一緒に仕事できる。Juliaがあればドメインエキスパートと実行速度厨が一緒に仕事できる。それは大きなことだ。
そういう点ではJuliaの欠点はライブラリが不足していることだろう。けどこの言語は他とは違って圧倒的に簡単にCのライブラリを呼び出すことができる。他の言語にあるネイティブインタフェースとは違って、C側にそれ用のコードを全く書かずにJuliaからCのコードを呼び出せる。なのでJulia対応ライブラリはかなり早く揃っていくんじゃないかとふんでいる。個人的に使ってみた感じだと５千行のCのコードを、C側のコードを全く改変せずにJulia側で１５０行書くだけでJulia用のライブラリにすることができた。
もし貴方がPython,C,C++,Fortran,Rをつなぐような眩暈がする類の技術グループで仕事してたり、私のように「shoot-from-the-hip Lone Ranger」に出てくるはやてのカウボーイみたいな速度厨だったら、Juliaをダウンロードしてちょっと転がしてみることをお勧めする。仮に貴方が知らないプログラミング言語なんかで職業生活を複雑化したくない人だとしても、Juliaを使えたら最終的には貴方がかかわることになるプロジェクトで必要になってくるプログラミング言語が少なくて済むようになるんだってことを考えてほしいのだ。
あとここまで敢えていわなかったんだけど、パフォーマンスのことを抜きにしてもJuliaは実際にいい言語だ。私はプログラミング言語を見る目が肥えてるわけじゃないが、学ぶにあたって頭を悩ますようなリスクは殆どないといえる。今現在、私の中でJuliaはお気に入りトップ３の言語だ。
最後に、活発でサポート手厚いJuliaコミュニティがあることについて。私がこのコミュニティで好きな部分は頭が良くでフレンドリーな数学・科学タイプの人たちであふれていること。それはJuliaが言語オタクによってつくられた言語じゃなく、MITの数学や科学や技術に携わる学生たちがCやFORTRANに代わる速くて実践的な言語が欲しくて作ったものだからだ。なので言語自体の美しさではなく答えを速く出すことのために設計されている。私にとってそれはまさにコンピューティングの本質なんだ。
