パーソナルツール
現在の場所: ホーム Users YAMADA Masaki 2015 1508 ソリューション記述言語からプロブレム記述言語へ
ログイン


パスワードを忘れた?
 

ソリューション記述言語からプロブレム記述言語へ

— カテゴリー: , ,

「エンタプライズ系におけるモダンプラグラミング言語Groovy」Spring in Summer ~ 夏なのにSpring 講演

2015年8月28日 日本Springユーザ会 (JSUG) 主催のイベント "Spring in Summer ~ 夏なのにSpring" に日本Grails/Groovyユーザーグループ (JGGUG) も協賛させていただき, 3つのセッション (今日から始めるGradle入門ハンズオン, Grails 3で生まれ変わったGrailsの今) を行いました.
 
そのひとつ, 山田が担当した「エンタプライズ系におけるモダンプラグラミング言語Groovy」のスライドを公開します.
 
表のタイトルは無難なものですが, その裏にある本当のタイトルは「ソリューション記述言語からプロブレム記述言語へ」です.
 
Javaが立ち上がった20年前 (1995年頃) の話から始めて, Javaのような「ソリューション」(解法, How-to) を記述するのが得意な言語から, Javaとすごく似ているけれど「プロブレム」(問題, What-to-do) を記述するのが得意なGroovyのような言語への移行の必要性を, Groovyが使われているソフトウェア・ツールの多くの例 (Jenkins, Gradle, Grails, Spock, Geb) を挙げながらお話ししました.
 
ソフトウェアを作るのに, 今までは日本語やExcel語で問題を書き (山のようなドキュメント!), その答をJavaのようなプログラミング言語で書く (山のようなソース・コード!) のが一般的でした. しかし, これをいつまでも繰り返していても大変です. かと言って, 問題を書くことも答を書くことも重要なことで, やらないわけにも行きません.
 
問題は, 問題をいつまでも日本語やExcel語で書き続けているところにあります. 問題の一部は形式的仕様で書くことができます. VDMやEvent-Bなど実際に使えるツールや手法も増えてきています. とは言え, (特にエンタプライズ系のようにそもそも矛盾を含むシステムでは) すべてを形式的に書くことはできません. ドキュメントから日本語などの自然言語を完全に排除することもできないでしょう.
 
しかし, 今「ドキュメント」と称して日本語やExcel語で書かれている情報の多くを, 人間にも読み書きでき, ソフトウェアにも読み書きできる言語で記述することは十分に可能です.
 
それによって, 「日本語で曖昧な問題を大量に書き, その答をその都度大量のプログラミング言語で書き」続けるサイクルを変えることができます.「プロブレム記述言語で問題を明確な実行可能な形式で書き, その実行系のみをソリューション記述言語で書くことによって, ソリューションの汎用化, 抽象化, 再利用化を図る」ことが可能になります. もっと言えば, 「問題の答を書く言語」から「問題の解き方を書く言語」と言えるかもしれません.
 
もちろんソリューション記述言語とプロブレム記述言語は同じ言語であっても構いません. むしろソリューション記述言語とプロブレム記述言語が同じであり, 緩やかにつながっており, 同じ場所に書ける方がいいだろうと考えています.
 
もちろん, GroovyはJavaに較べて極めて生産性が高い - 少ないコード量 (おおよそ数分の一) で書きやすく, 読みやすく, 意図の伝わりやすい - 言語でもあります. Java8の出現によって, Javaもこの領域に近付いてる面もありますが, それでもやはり「官製」言語的な「臭い」はつきまとっています.
 
ともあれ, まずはGroovyという, Javaに似た, しかしプロブレムを記述しやすい, そのための環境 (Grails, Spring Boot, Dropwizard, Vert.x, Ratpackなど) やツール (Jenkins, Gradle, Spock, Gebなど) が揃っているグルーヴィーな言語を使ってみませんか?
関連コンテンツ