InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

将来のシステムにおけるプログラミング言語

作者 Niclas Nilsson , 翻訳者 編集部 投稿日 2008年1月9日

セクション
デベロップメント,
設計/アーキテクチャ
トピック
Architecture ,
動的言語 ,
Domain Specific Languages ,
プログラミング
タグ
JVM ,
CLR

トレンドが明確になって来ているようだ。来る数年間で新たなプログラミング言語の採用が増えるだろう。その一番の目的は私達が現在使用している言語と置き換える事ではなく、言語をミックスして問題を解決する適した言語を使用するためである。

しかしながらある特定の問題に対する適切な言語とは何だろうか?最近のブログ掲載の中でJRubyのデベロッパであるOla Bini氏(ブログ・英語)が新たな側面から(source)その課題に立ち向かっている。ポーリグロットプログラミングとしても知られている多言語プログラミングは以前InfoQが取り 上げているが(参考記事・英語)、Bini氏は私達がどのように将来のシステムを構築するのかという点においてその現象について語っている。

Bini氏は3つの異なる層と言語、かもしくはその層に適合する言語の種類を解説している。従来のプレゼンテーション、ビジネス、データレイヤーではなく、Bini氏はその世界を異なるやり方で切り開いている。

  • 安定層-静的言語で構築されたほどほどの量のアプリケーション機能
  • 動的層-動的言語で構築されたたくさんのアプリケーション機能
  • ドメイン層-ドメイン仕様言語で構築されたたくさんのアプリケーション機能

Bini氏は安定層を下記のように説明している。

最初の層は私が安定層と呼んでいるものです。機能の点においてはそれはアプリケーションの大きな部分ではありません。しかし他の全てがその上に成り立っているという大変重要な部分なのです。このレイヤーが静的タイプの安全性が大変有益となる層なのです。

動的層はほとんどのアプリケーション機能が存在している場所である。

二つ目の層は動的層です。これが多分半分のアプリケーションコードが備わっているところです。ここの言語タイプは主に動的で強く定型化された言語です・・・

また動的層を考える際に彼は下記のように付け加えた。

それは環境の良い生産性に優れた場所であり、また私はJVMに強い興味を持っているので、これがこの層と大変強力な安定層との相互作用であると信じています。

ドメイン層においてBini氏はDSLムーブメントが起こると踏んでいる。

3つ目の層はドメインレイヤーです。それは一つかそれ以上のシステムのニーズに依存しているDSLに実装されるべきです。ほとんどのケースにおいて動的層内で内部DSLとしてそれを実装するのに十分であり、そのような場合において二つ目と三つ目のレイヤーは簡単に区別できるものではありません。しかしながらいくつかの場合において相互作用可能な外部DSLを所有する事が警告されます。典型的な例はルールエンジンのようなものかもしれません(Drools のような)。

David N.Welton氏(サイト・英語)はBini氏の掲載に対する返答記事を書き、この進化論に関する彼の疑念(source)をあらわにした。

私はこれに関して半信半疑ですね。そして彼はこの変化を後押しする根底に存在している社会的、経済的要因が何であると考えているのか知りたいですね。プログラミング言語は最終的には人間の奇異さに宿っているので、言語がこの先どうなるか理解するには人的要因を考える必要があるのです。

Welton氏は自身が2年前に記したプログラミング言語の経済的な側面(source)を分析した記事を参照している。その記事においてWelton氏はほとんどの言語実装が今日無償なので、新たな言語を使用してより良い経済をもたらすただ一つの方法はコードを作るかどうかということであると述べている。

  • 書き易い-より多くの人が使用できる
  • より効率的-リソースの保存
  • より良い品質-より少ないバグフィックス
  • より生産的-複雑なことを簡単に成し遂げるのを可能にする

Ola Bini氏は彼が一つの層内においてでさえも、次なる言語を信じていないことを説明するのと共に幕を閉じている。

しかし一つ明確にしたいことがあるのです。これらの層で勝者が出るとは思いません。実はどれかの層で一つの言語が勝つとなると悪い影響がもたらされると思うのです。というのも私はJython、JRuby、Rhinoと他のいくつかの言語が一つの層に共存するという将来を見据えているのです。競合も言語戦争もそこには存在しないのです。

Bini氏は自身の努力によってJRubyにおいてバーチャルマシンレベルで言語をミックスするのを可能にする事に多大に貢献し、また他の言語でもそれを成し遂げた。もう一つのバーチャルマシーンプラットフォームにおいて、Microsoftは共通言語ランタイムのためのVB.NET、C#とC++実装を提供することによって一から多言語に備えていた。また最近彼らはIronPythonIronRubyの上に成り立っている動的言語ランタイムをリリースし、.NETが多言語プラットフォームであることを強調している。

しかしその記事は興味深い疑問を提示している。

  • 異なる層と言語に関するOla Bini氏の見解は将来の展望となるのだろうか?
  • 一つのバーチャルマシーン内で多言語をミックスすることの良い点と悪い点は何なのか?
  • 言語をミックスする他の方法はより良い選択となるだろうか?(その例はそれぞれのサービスが最も適した言語で実装されているか、もしくはRestfulなWebアプリケーションの場合におけるサービス指向のアプリケーションであるかもしれない。URLレベルでそれを垂直に小さなアプリケーションに切り崩すと いうことである。)  

要は将来のシステムがどのようにプログラミング言語を活用するのかということだ。

原文はこちらです:http://www.infoq.com/news/2008/01/languages-in-future-systems

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。