BT

Scalaの開発が加熱する

| 作者: Michael Redlich フォローする 15 人のフォロワー , 翻訳者 小林 健一 フォローする 0 人のフォロワー 投稿日 2016年8月25日. 推定読書時間: 8 分 |

原文(投稿日:2016/08/02)へのリンク

2015年、Scala周辺は比較的静かだった。 これに対し、Scalaの父、Martin Odersky氏は、2016年5月9日のScala Days New York基調講演にて、 今年はScalaの開発が“加熱する”と述べた。 Odersky氏(現在École Polytechnique Fédérale de Lausanne(EPFL)のプログラミング研究グループ教授、 かつLightbend社の会長兼共同創設者)は、“ここ最近起こったことと直近に起こること”をまとめた。

 

  • The Scala Center
  • Scala 2.12
  • Scalaライブラリ再検討計画
  • 新ターゲットプラットフォームの開発
  • DOTおよびDotty

Scala Center

Odersky氏は新たにScala Centerを紹介した。 これは “すべてのScalaコミュニティにとって利益をもたらす責任あるプロジェクト”として設立されたものだ。 Scalag技術者の市場が拡大し、さらにはscala tutorialに対するGoogleサーチも増加している。 これは、Scalaへの関心が継続的に高まっていることを示している。 そんな中、Scala Centerはオープンソース・コミュニティと教育にフォーカスした組織として設立された。 また、Scala Centerのブログ記事(2016年3月14日)によれば、カスタマ・サポート対応の役割も担っている。

巨大なユーザ層やScalaで開発されたプロジェクトの拡大をみると、 言語やツールセットに対して更なる要求が存在しているものと考えられます。 また、技術力と熱意を兼ね備えた協力者もたくさんいます。 Scala Centerの最初のミッションは、ユーザ・コミュニティとの協力です。 共通のゴールを定義し、ゴール達成のために、コントリビューションとリソースを編成するのです。

Lightbend社のケース・スタディによると、62の企業がScalaおよび関連技術にコミットしているとのことである。

Scala CenterはEPFLに設置される。 科学者で、事務局長のHeather Miller氏がリードする。 Adriaan Moors氏(Lightbend社でのScala技術リード)はScala Centerの取締役会を組織する。 氏は、InfoQに対し、Lightbend社の成長は、Scala Centerとともにあると語った。 Lightbend社の日々の活動がScala Centerにより影響を受けるのではないか、との質問に対し、Moors氏は、次のように答えた。

Scala Centerは私たちの計画に影響を与えるでしょう。 しかし、私たちの日々の仕事に与える影響を語るにはまだ時期尚早です。 Lightbend社のScalaチーム全員が、数週間後にリリース予定の2.12.0-RC1に集中しています。 これは、私たちがまさに責任を持つべきことです(もちろんコミュニティからの多大な協力を受けています)。

Scala 2.12

Scala 2.12への道のりは、ほぼ2年経過しており、2016年中のリリースが計画されている(Scala 2.12.0 milestone 5は2016年6月29日に公開された)。 今回初めて、Java8に向けて最適化された。Java8のラムダ式を利用することで、より短いコードで高速な実行を実現した。 Scala2.12は33の新機能を掲げている(ScalaのGitHubリポジトリに文書がある)。 Lightbend社は、Java6/7で稼働するアプリケーションに配慮し、Scala2.11のメンテナンス期間を延長した。

DOT

DOTが開発されてから8年が経過し、DOT(ドキュメント・オブジェクト型(document object types)の計算(calculus))は、Scalaのすぐれた基盤であることが証明された。 Odersky氏はブログ記事(2016年2月3日)にて、以下のように述べている。

計算(calculus)は、形式的な研究を行えるほどに小さい、ミニ言語の一種と考えられます。 Scala表記に変換すると、DOTによりカバーされる言語は、以下のような抽象文法として記述できます。

DOT 計算のGitHubリポジトリに定義されている内容によると、上の抽象文法は、以下のことを表している。

これは依存オブジェクト型(dependent object types)の最小完全版(minimally complete version)です。 計算は関数、ラベル型(labeled types)および、項からなります。 これらは交差(intersection)、再帰束縛(recursive bindings)により結合されます。 それ以外はありません。

DOT計算を選択したことにより、形式記述の作成と証明に加え、これ以外の言語のエンコーディングが可能になる。 これは、将来のScala開発をさらに安定させる。 計算により、型健全性が与えられる。 型付けルールは型を項に代入し、評価ルールはプログラムの評価が正しいことを保証する。 以下の例はそのデモンストレーションである。

もし、項tが型Tを持ち、tの評価が終了するならば、結果は型Tの値vとなる。

このことの重要性に対し、Odersky氏は次のように述べている。 “これは、ほかの言語機能の正しさを証明する技術を与えているということなのです”。

Dotty

Dottyは、DOTを内部データ構造とする、新コンパイラである。 Dottyのコードベースは現行のnscコンパイラの半分ほどのサイズしかなく、一方で2倍高速である、とうたっている。 Dottyはいくつもの新機能を含んでいる。

  • 交差型(Intersection types)(可換でない型に対する問題を解決する)
  • ユニオン型(Union types)(巨大な構築オーバーヘッドを回避する)
  • 関数アリティ適応(Function arity adaption)(さらに効率の良い引数マッピングを行う)
  • トレイトパラメータ(トレイトは、Javaのインタフェースと同義になる)
  • @staticメソッドとフィールド
  • マルチバーサル同一性(==や!=というオペレータは、型安全になった)
  • 名前付き型パラメータ

これらの新機能が導入された理由は、より安全かつ簡単に言語を利用できるようにするための基礎となるためである。 これらの機能の現在の状況はDottyのウェブサイトを参照のこと。

言語をシンプルに保つため、Scalaの機能のうち、いくつかを廃止する、とOdersky氏は述べた。

  • プロシージャ文法(Procedure Syntax)(特に効率が良い、というわけではないため)
  • DelayedInitクラス(使われなかったため)
  • マクロ(もともと実験的実装であり、長期計画にも入っていなかったため)
  • 早期初期化(Early initialize)(トレイトパラメータに置き換えられた)
  • 存在型(Existential types)(Scalaとは相いれなかったため)
  • General Type Projection(型健全でないことが分かったため)

これらの機能のうちいくつかは、新機能で置き換えられるか、単純に廃止される。

Dottyの応用的な機能には、以下がある。

  • sbtビルドツールとの基本的な統合
  • シンタックスハイライト付きの対話的REPL(read-eval-print-loop)
  • 新しいIntelliJ Dottyプラグイン
  • ドキュメント生成(クロスリンクされているライブラリのための動的ハイパーリンク)
  • より効率的でロバストなリンカ

Dottyは以下の図に示したように構成されている。

新しい、シリアライズド型抽象構文木(serialized typed abstract syntax tree)であるTASTYが導入された。 TASTYは、コンパクト、遅延評価、拡張可能で、より正確になるように設計されている。 DottyはEPFLにて開発が行われている。 しかしLightbend社のScalaチームは、インフラストラクチャや、レビュー、助言に対して責任を持っている。 ソースコードはDottyのGitHubリポジトリから取得できる。

Scala 2.12そしてそれ以降

Scala 2.13の計画に向けて、ライブラリの改造が焦点になっている。 特殊ケースを排除することで、より使いやすくするのである。 Odersky氏によると、これはSparkのコレクション実装(遅延構築型コレクション操作のために、Resilient Distributed Datasets(RDDs)を用いている)に着想を得たとのことである。

Scalaライブラリをさらに適切にモジュール化するため、Odersky氏はScalaのstdlibの分割を提案している。

Odersky氏は、既存のライブラリや、新しいたたき台に対して、開発者に協力を求めている。

結論

Moors氏は、Scalaプログラミング言語のために公式GitHubリポジトリをメンテナンスしている。 これにより、ソースコードおよび開発者が協力するための情報が公開される。

Lightbend社は、InfoQに対し、次のように語った。 今年の夏の終わりごろ、彼らは“JavaやScalaの開発者数千人の研究成果を公開し、コンテナ、マイクロサービス、クラウドネイティブアプリケーション、さらにそれ以外の最新の話題を共有する計画”を立てている。

 
 

Rate this Article

Relevance
Style
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

過熱ではなく加熱とした意図は? by Chiba Masaomi

どういう意図なのでしょうか? 言葉遊び感も伝わってこないので誤訳に感じてしまいます。

Re: 過熱ではなく加熱とした意図は? by Kobayashi Kenichi

ご指摘ありがとうございます。
これは誤訳です。
失礼いたしました。

Re: 過熱ではなく加熱とした意図は? by Kobayashi Kenichi

Chiba様
改めまして、ご指摘ありがとうございました。
先ほど「誤訳」と返答いたしましたが、改めさせていただきます。

本記事に関しては「加熱」とするのが適切と考えております。

原文は、"heating up"です。

heating = 加熱(熱を加えること)
overheating = 過熱(度を超した状態になること。「議論が過熱する」など(kotobank.jp/word/%E9%81%8E%E7%86%B1-45954)

Oderskey氏は基調講演にて、"今年はScala開発に対する諸活動が活発化する"という意図の発言をしています。"過熱"ですと、制御できない意味が発生すると考えます。
"加熱"であれば、直訳の上でも、諸活動が"加わる"意味でも適切かと考えます。

これからもお気づきの点がありましたらご指摘いただけるとありがたいです。

Re: 過熱ではなく加熱とした意図は? by Chiba Masaomi

『Scalaの開発が加熱される』ならまだ分かりますが、
ことの成行きを表現して『加熱する』とはいわないですよね。
日本語表現として違和感がありますが、その辺りの違和感を含めて、あえて表現をされていると思いましたので『言葉遊び感』と表現させて頂きました。
適切とお考えとのこと了解致しました。ご返信ありがとうございます。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

4 ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT