きしだのはてな

■Webアプリで動的型付言語や開発管理が流行りIDEが流行らなかった理由などなど 18:19

考えてみた。

ここんところ静的型付けなんか不要な空気になってたり、プログラムの内容よりも品質だとか開発管理の話題のほうが盛んだったり、IDEはあると便利だけどなくても大丈夫って雰囲気だったりする理由。

この10年Webアプリケーション花盛りだから、その理由はWebアプリケーションの構造にあるとして考えた。

Webアプリケーションの構造

で、まずはWebアプリケーションの構造。

字が汚いけど、左からブラウザ、アプリケーション、セッション、DB。

赤文字は、左がプログラム実行、右がデータの永続と書いてある。つもり。

Webアプリケーションでは、ブラウザからのリクエストを受けて、プログラムが動き、データベースの情報を処理して返す。

ブラウザ側でプログラムが動くことはあるけど、入力補助程度であまりたいしたプログラムは書かないので、主にサーバー側のプログラムを組む。

このとき、サーバー側のプログラムは、リクエストに対して返答すれば終わりなので、実行期間は非常に短い。

Webアプリケーションでのデータ管理

アプリケーション上必要なデータは、データベースが管理するし、リクエストにまたがるデータは、セッション情報として管理する。ここで大事なのは、データベースにせよセッション情報にせよプログラム言語の機構とは別の枠組みでデータを管理するということだ。

Webアプリケーションではセッションとデータベースが状態を管理することになるので、つまりは、プログラム言語としては状態を管理しないということになる。状態はプログラムの外で管理される。

やりとりするデータも型変換がある程度で、ほぼ無加工のままやりとりされる。

そうすると、プログラムでデータを管理する必要がほとんどないのだから、データに型をつけることのメリットがなくなる。

静的型付けが邪魔になる理由

これだけでは、動的型付けが有利、静的型付けは邪魔とまではいかない。

ここで、リクエスト一回ずつの処理を見てみる。

プログラムは、HTTPのパラメータを受け取り、データベースとやりとりし、テンプレートエンジンにデータを渡す。独立したテンプレートエンジンを使わない場合もあるけど、そのときはプログラム中でHTMLにデータを流し込む処理が書かれる。

注意する点は、プログラムはHTTPパラメータ、DB、テンプレートエンジンとデータのやりとりをするという点。

静的型付けの場合は、このやりとりのパターンの数だけクラスを定義して型として解決できるようにしておく必要がある。けれども、このときのデータは、単にプログラムを素通りしていくだけで、特に管理をする必要がない。そうすると、手間ばかり増えて静的型付けのメリットがなくなるということになる。

プログラミング能力より開発管理が重要になる理由

ここまで見て、プログラムの処理では状態の管理をする必要がなく、データに対する処理もほとんどないことがわかった。データに対する処理はデータベースが行い、データベースのスキーマ定義の段階で仕事が終わっている。

もうひとつ、Webアプリケーションで面白いのは、最初のほうの図に示しているように、プログラムが受け取るデータは、一つ前のプログラムが生成した画面で入力されたデータということだ。そして、次のプログラムに渡すデータを入力する画面を生成する。

このように、Webアプリケーションでは、ひとつひとつは小さくて単純な多数のプログラムを、画面生成側と処理側の連携だったり、データベースだったりといった、プログラムの外での連携を行って全体を構築する。

そうなると、ひとつのプログラムを作る能力よりも、プログラム同士が連携できるように設計しながら多数の小さなプログラムを作成するという開発管理能力のほうが大切になる。

IDEがあまり重要ではない理由

Webアプリケーションでのプログラムは小さい単純なプログラムの集まりになる。

ひとつのプログラムが扱うデータは、HTTPパラメータとそこからのやりとりによるデータベースのデータ、それからテンプレートエンジンに渡すデータということになる。そして、これらのデータはほとんど共通の構造になることが多い。また、動的型付けであれば、HTTPパラメータやテンプレートエンジンに渡すデータに関してはわざわざクラスを作る必要もない。実質、扱うのはDBとのやりとりのデータになる。

そうすると、ひとつのプログラムが関わるファイルも多くて３つというレベルになってくる。そうであれば、わざわざIDEを使ってプログラムの管理をするまでもなく、ちょっと気の利いたエディタがあれば十分になる。

プログラムの状態を扱うようなデータはデータベースで管理するので、データベースのスキーマのエディタが便利だとなおよい。

もちろん、Javaや.NET以外では使い物になるIDEがしばらく出なかったというのもあるけど、それもIDEが求められなかったから出なかったという面があると思う。

いろいろなスクリプト言語が流行った理由

最近はいろいろな言語が出て、実際に使われてきた。

その理由のひとつとしては、Webアプリケーションでは小さなプログラムをたくさん作る必要があるということがあげられる。「手にあった」プログラム言語でいかに短時間でプログラムを書けるかということが大事になる。「手にあった」という基準は人それぞれで、さまざまなアプローチのプログラム言語が考えられた。

ただ、そういったプログラム言語が実用化されたのは、Webアプリケーションの単純さに追うものが大きいと思う。

Webアプリケーションのプログラムは、HTTPリクエストデータを文字列として受け取り、データベースに文字列でSQLを発行し、そのデータをもとにHTMLという文字列を生成して返す。そうなると、プログラム言語や標準的ライブラリなどの処理系に求められるのは、文字列とデータベースを扱えて、ちょっとしたデータ構造が扱えれば十分ということになる。

GUIのように重たいライブラリは不要で、IDEによるサポートも必要がない。そうすると、言語処理系はパーサーやコンパイラと標準的なライブラリを用意すれば十分ということになって、いろいろな言語が実用的に使われやすい土壌ができた。

これからのWebアプリでは

さて、これからは、JavaScriptが高速化したりHTML5が出たりで、ブラウザ側で処理を行うアプリケーションが多くなっていく。ユーザーインタフェースに対する要求の高まりへのJavaScriptでの対応の難しさから、Flexなどの出番も増えると思う。ここではFlexなどのリッチクライアントも便宜上「ブラウザ側」に含める。

構造としてはこのようになる

図ではブラウザ側でのプログラムの寿命が長くなることを示している。そうするとブラウザ側のプログラムで状態を管理することになる。

サーバー側は、データベースへのアクセスを代理して行うだけになって処理はもっと単純になる。ただし、ブラウザ側の処理と密接に連携することになる。

状況が逆転するかもしれない。

要するに、ここまでに状況がいままでとは逆になる可能性が出てくるということだ。

ブラウザ側で、プログラムによって状態を管理するようになる。そうすると静的な型付けのメリットが出てくる。IDEによる補完を考えると、動的型付けで補完が効きにくいとプログラムが組みにくいということにもなる。また、GUIツールキットは多数のクラスを連携させることになりがちなので、ここでも渡すべきオブジェクトを静的に決めれるのはありがたい。

プログラムが連携するクラスやファイルが多くなり、サーバー側プログラムとクライアント側プログラムの同期も必要になるので、IDEの重要性が出てくる。

GUIツールキットや、実行環境が必要になるので、どんな言語でも使えるというようにはなりにくい。

プログラムの作成自体が難しくなり、開発管理による制御がやりにくくなる。プログラムが難しくなると、プログラム作成に対する予測が立てにくいからだ。そしてプログラム作成能力の重要性はあがる。

つまり、クラウドサーバーによる従量課金などもあわせて、アプリケーション作成にかかる力学が変わってくる可能性があるということだ。

少なくとも、Webアプリケーションのプログラムとしての特徴は、プログラム一般の特徴ではないと考えておいたほうがいいと思う。