コンピュータプログラミング小史とこれから
独断と偏見に基づく個人の考察でプログラミング小史と、現状のWebプログラミングについての不満と課題についてです。
長文なので先に言いたかったことを書くと
「Railsって、クライアントサイドも自由に扱えない限りDRYにはなり得ないよね」
ってことです。
もし打開策が存在していれば教えて頂ければ幸いです。
小史
昔々〜 アセンブラ(僕の知らない時代）〜
1950年代頃の時代は、ソースコードはアセンブラのような人が読めないもので、フローチャートがなければプログラムの意味が理解できないものだった。後にFortranや ALGOLといった高級言語が現れ、1970年代に入り、デニス・リッチーとブライアン・カーニハンによってC言語が誕生した。これらの高級言語の登場によって、フローチャートと同じかそれ以上の内容を直接コードに書く事が可能となった。（といってもコンピュータは高価だったので、今のように気楽にコードは書くことができなかった）
〜1970年代 〜アセンブラからC言語〜
高級言語が出ると同時にデータ構造とアルゴリズムについての理解が深まり、さらにダイクストラによる構造化プログラミングなどの方法論が誕生した。それと同時期に初期のオブジェクト指向が登場した（Simula67やSmalltalk、Cにクラスの概念を取り入れたC++の初期版は1979年には開発が始まっている）。
※このあたりの時代順は記憶に基づいています。
1980年〜90年代 〜メモリ管理の問題とJavaの出現〜
80年代〜90年代になりC/C++がソフトウェア開発の主流になるにつれ、メモリ管理が大きな問題となった（これは個人の経験に基づく）。C/C++で作成されたプロセスは、プロセス内のメモリ空間に自由にアクセスできてしまうため、簡単にメモリ破壊を起こしたり、メモリリークといった問題が多発した。90年代半ばになると、オブジェクト指向言語Javaが登場し、この問題に対して２つのアプローチがとられた。１つはメモリ空間を直接扱えなくする言語的制約、もう一つは以前からLisp,Simulaによってガベージコレクションという仕組み。Java以降の言語では、ガベージコレクションの仕組みが当たり前になった（マシンスペックの向上により可能になったのかもしれない） 。特に多くのオブジェクト指向言語では、オブジェクトの生存・破壊の実装を動的メモリに依存している事が多いため(C++,Objective-C,Java,C#,Rubyなどなど）、オブジェクト指向の実践が容易となった。
※ Wikipedia情報によるとガベージコレクションなどはSimula67の時点で既に取り入れられていたらしい。
1990年代〜オブジェクト指向の普及〜
90年代〜2000年にかけてオブジェクト指向の方法論が洗練されていった。デザインパターンが登場し、リファクタリング、ユニットテストが登場し、様々な図示化の方法(後にUMLに統一された。最近はよく分からない）が誕生した。これらの技術は主にSmalltalk、NextStep(Objective-C)で登場し、C++/Javaの世界に普及していった。
2000年代前半〜オブジェクト指向に基づいたWebフレームワークの普及〜
オブジェクト指向の技術とWebの台頭により、フレームワークという概念が一気に広まった。GUIアプリでは、既にNextStepやWindowsではMFCというフレームワークが台頭していたが、Webの時代になりJavaのStrutsを始め、オブジェクト指向に基づいたWeb独自のフレームワークが出現し始めた。またオープンソースなどの普及により 、高度な開発環境(javaコンパイラ、Eclipse VSExpress、など）がより手軽に利用できるようになった。
2003年~2013年 〜暗黒期（僕にとって）〜
･･･2003年〜2013年にかけては僕にとって暗黒期で所謂IT土方をしていた。そのためプログラミング環境がどのように発展したいたのかは正直分からない。しかしWebサービスの開発は、重量級のJavaから軽量なスクリプト言語PHPへシフトし、開発プロセスも（少なくともWebでは）重たいウォーターフォールからXPを始めとするアジャイル開発などの軽量的プロセスにシフトしていった（のではないかと思う。最近のScrumの普及具合からの推測です）。又仮想化技術やAWSなどのクラウドサービスが登場し、Webサービスのあり方が大きく進歩した（のではないか・・・と思う）。
2013年。 〜気づいたらGithubやらCI(継続的インテグレーション）の時代になっていた〜
2013年、気づいたらJavaは影を潜め、Webフレームワークの主流はPHP(CakePHP)やRuby on railsといったスクリプト言語に移行していた。開発においてもGithubによるソーシャルコーディングが普及し、個人が開発したライブラリをGithubで取得して利用するのが当たり前の時代になった。またCI（継続的インテグレーション）という単体テストとデプロイを自動的に行う方法も生み出されたり、VagrantやChefといったサーバー構築や仮想環境の構築といった事も自動化され、今までは手順や手順書により属人的に行われた作業が自動化され、開発から運用に必要な時間と人が減った（減っていく）のではないかと思う。
小史は以上です。
おまけ 〜そして2014年〜
2014年、僕は10年に及ぶIT土方をやめて、所謂ITエンジニアの世界の入り口に足を踏み入れた。会社ではsvnだったりアンチクラウドだった環境が、gitへ置き換わったりクラウドサービスを利用するようになった。スマホのアプリをObjective-Cやcocos2d-xで書き、ruby on railsでサーバサイドのプログラミングを作成するようになった。所謂ITエンジニアの入り口に立つことができた。これから5年、どのようなサービスを作るのか楽しみでもあるし怖くもある。
〜Webプログラミングに対する不満。 HTTP, JSの限界〜
いささか唐突だけど、Webプログラミングを始めて３つ不満がある。 もしかしたら既に打開策があるようなものもあるかもしれないけど、僕は知らない。
1つ目 HTTPプロトコル
Webプログラミングは、HTTPというプロトコルに縛られている。C/C++でBSDソケットやWinsockを利用していた頃は、HTTPという制約がなかった。サーバーからもクライアントからも要求ができたし、文字列しか扱えないという事もなかった(昨今はWebソケットがあるから双方向の通信可能だと思うけど、未調査）。 Ruby on Railsのようにレールに従うように「HTTPに従え」と言うことなのかもしれないけど、自由度が低い気がする。
2つ目 Javasciprt
クライアントサイドの言語がJavascriptに縛られている。これは僕には致命的に感じる。つまりサーバーサイドがJavascript(例えばNode.js)である場合を除いて、サーバーサイドとクライアントサイドで異なる言語を利用する必要がある。例えばサーバーサイドで記述された内容をクライアントで利用したい場合、それぞれの言語で２つ書くか、サーバーかクライアント（恐らくサーバー側）側に処理を統一する仕組みを設ける必要がある。何よりも今後生産性の高い言語が現れサーバーサイドにその言語を利用しても、クライアントサイドは必ずJavascriptに束縛される。これは最悪だと僕は思う。他の人はどう思うのだろうか？
3つ目 サーバーサイドとクライアントサイドで同一のオブジェクトを扱えない
2つ目の問題の延長だけど、サーバーとクライアント間でオブジェクトがシームレスに相互作用を発揮できない。オブジェクト指向設計において、一番理想的な環境はサーバーで作成したオブジェクトがクライアント側でも操作できて、その操作の結果がサーバーに反映される事だと思う。つまり通信が完全に隠蔽されていて、サーバーとクライアントのオブジェクトが1つになっている様な状態が、理想的な状況だと思う(書いていて思い出したけど、J2EEにそんな感じのモデルがあったような・・・）。例えばGUIアプリケーションのMVCモデルというのは、modelがいてviewがいて、その両者を中継するcontrollerがいた。けどWebプログラミングでは、modelとcontroller(web側(通信も担当)）, view(クライアント側）,controller(view側(たまに通信も担当)）といった層に分けて管理している。この２つのcontrollerはサーバサイドとクライアントサイドのオブジェクトが独立しているために発生していて、本来は不要なものだと思う。
現時点で良いと思うもの
クライアントサイドの言語の多様化
クライアントサイドがJSしかないという状況は、ある意味クライアントサイドの開発者にとっては良いかもしれないけど、今後、どんなに生産性の高い言語が出現してもJSを使い続けなければならない。それを打開するためにも、ブラウザには複数のクライアント言語を処理する仕組みがあっても良いと思う。CSSを外部のサイトから取り込めるように、rubyやpythonの処理系を外部から取り込む仕組みがブラウザにほしい。
サーバーサイドとクライアントサイドのオブジェクトの一元化
例えばサーバーサイドで生成したrubyオブジェクトをクライアントサイドに渡して、クライアント側からメソッドを呼び出すとサーバー側に反映される。といったRPC的なプログラミングがより手軽に可能になればと思う。もちろん同期や並列性において別の問題を生み出す可能性があるけど。
ブラウザに代わるもの
クライアントサイドがより柔軟になれば、HTMLにすら縛られないWebサービスという事も可能になるかもしれない。これについてはセキュリティ的な制約や、具体的にブラウザの代わりをどのように実現するかなど、今は言ったもの勝ち的なアイディアだけど、今後ブラウザという存在がネックになるのではないかな〜と思う（ブラウザとＯＳが歩み寄り、ブラウザがよりＯＳに近くなり、さらに言語の多様化が進めばブラウザの制約は薄れるかもしれない）。といってもこの場合、結局汎用性かOS依存かという問題がまた発生しそうだけど。
結論
最初にも書きましたが、この文章を書くきっかけで、自分が感じている事を端的に述べるなら
「Railsって、クライアントサイドも自由に扱えない限りDRYにはなり得ないよね」
って事から始まりました。
最後まで読んで頂き、ありがとうございました。
