これから業務で使うならRubyかPythonか
いままでWebやScripingなんかのアプリケーションはなんとなくプラグインが
揃っているという理由でRubyで作ってた。
が、業務で使うアプリケーションが私が趣味的にプログラミングしたものだらけ
になってしまい、引き継ぎが発生した場合にちょっとまずいなぁと。
今後はアプリ開発の業務も増えそうなので、この機会にサーバーサイドの
スクリプト言語を考え直そうと思った。
このままRubyを公式採用するのはどうだろうか。
Rubyはとにかく（複雑なことが）簡潔に書けるのが魅力だ。情報量も多い。
しかし例えばJavaのプロジェクトしか業務経験のない新人をアサインする場合、
RubyやRailsの学習コストや将来的なことを考えると微妙だ。
「私はRubyが大好きで夢中です！ 仕事以外でも家でアプリ作ってます！」みたいな
優良な人が常に揃うなら別だが、人材採用という再現性が不確定な要素に依存する
のは避けたい。さらに私の知り合いの会社では、その会社はRuby on Rails開発に
おいて実績があり優秀なRubyエンジニアが揃っているのだが、実際はRailsの
品質管理が難しくGemが込み入ってしまって原始的なオペレーションにならざるを
えないと嘆いていた。 それは何事も機械的に済ませて17時30分（定時）に
帰りたい私が最もイライラする事象だ。
ちょっと調べたら、この記事があった。
THE HOMOGENIZATION OF SCIENTIFIC COMPUTING, OR WHY PYTHON IS STEADILY EATING OTHER LANGUAGES’ LUNCH
Pythonだ。
たしかに海外では最も普及しているスクリプト言語なのでドキュメントの心配はない。
私の周りでもスマートフォンアプリのサーバー側の言語にPythonを採用している
企業が増えてきている。
サーバー通信用途だけでなくRと並んで科学計算用のライブラリが揃っているので、
他業務でも使えそうだし、実際に会社に導入実績がある。
なによりエンジニアごとの癖が出にくそうなのが魅力。
Rubyのような動的型言語の場合、静的型言語のJavaと違って設計の柔軟性が魅力
なのだが、人によって実装にばらつきが出てしまう。まぁRubyのようにちょっと
マニアックな言語を使っているエンジニアはそれなりのスキルが望めるのだが、
例えばPHPのようにエンジニア単価が安いから使われている言語の場合、残念な
ことになる。*1
なので研究がてら、しばらくPythonを強制的に業務で使ってみようかと思う。
