将来の視点から言語を眺めてみよう

これまで「現場が要請する言語選択のワケ」ということで、いろいろな選択基準について述べてきた。最後に、将来の開発現場ではどうようなプログラミング言語が求められるかを考えてみたい。

筆者は、そもそも「プログラミングという行為は楽しくなければならない」と考えている。もちろん実際のビジネスの現場では、楽しいことばかりではないということも承知している。

それでもあえてそう主張したいのは、プログラミングが本来高度に知的な作業であり、それを効率的に行うには何らかの動機付けが必要であると考えるからだ。そして「楽しさ」というのは、知的作業における最高の動機付けである。

では、プログラミングにおける楽しさとは何だろうか。

筆者は、それを抽象化の力だと考える。抽象化とは、さまざまな処理から共通のパターンを見出すことであり、きわめて創造的な行為だ。処理パターンを言語の中で定義して、再利用できるような力があったらうれしいと思うだろう。原始的なところでは、C言語のマクロがある。もう少し進化するとC++のテンプレート機能になる。

この流れをさらに進化させたのが、このところ関心の高まりつつある関数型言語である。従来の手続き型の言語では「処理をどう実現するか」を記述していたのが、関数型言語では実現手法を抽象化することによって「何をしたいか」という意図を記述するのがプログラミングの中心課題になっている。

関数型言語はまだ主流にはなっていないが、普及のための突破口の1つはCPUのマルチコア化であろう。近い将来、マルチプロセッサ構成を抽象化して扱えるようになり、スレッドの同期のような低レベルの処理からプログラマを解放して、並列処理をエレガントに記述できる関数型言語が登場したときに、一気に普及するのではないかと筆者は夢想している。

実際の開発の現場においては、今回の記事にもあったようにすでに開発環境やプログラミング言語が決まってしまっているところも多いだろう。将来の保守性への配慮から、設計標準やプログラミング標準などが厳格に決められ、極力単純なビジネスロジックだけで実装するように制約されている場合もあり、まったく自由度がない世界かもしれない。

自由度がないというのは、パターンを固定して誰がやっても同じ結果を得られるようにするためだ。つまり、いずれは「抽象化される」ということである。これはそんなに遠い将来の話ではない。

そうなったときに、抽象化を駆使した「楽しい」プログラミングができる世界に移行できるよう、今から新しい言語にも触れておくことをお勧めしたい。

タイトルへ戻る