the evolution of scala / scala進化論

37
The Evolution Of Scala Martin Odersky EPFL and Typesafe Scala 進化論

Upload: scalaconfjp

Post on 24-Jan-2015

1.970 views

Category:

Software


2 download

DESCRIPTION

Presentation material with Japanese subs, by Prof. Martin Odersky at ScalaMatsuri 2014 http://scalamatsuri.org/en/

TRANSCRIPT

Page 1: The Evolution of Scala / Scala進化論

The Evolution Of Scala

Martin Odersky

EPFL and Typesafe

Scala 進化論

Page 2: The Evolution of Scala / Scala進化論

10 Years of Scala

Scala も今年で 10才。

Page 3: The Evolution of Scala / Scala進化論

Pre History

1980s Modula-2, Oberon

1990-95 Functional Programming

1995-98 Pizza

1998-99 GJ, javac

2000-02 Functional Nets, Funnel

3

Scala 前史

Page 4: The Evolution of Scala / Scala進化論

4

Minimal programming language based on type members and functional nets (a

variant of join calculus)

Analogous to Pict (Pierce and Turner 2001) for Pi-calculus.

型メンバと関数型ペトリネット (join計算) に基づいた最小言語

Page 5: The Evolution of Scala / Scala進化論

A Minimal Language

• Idea of Funnel: Show that we can build a general

programming language that can be understood as thin

syntactic sugar over a core calculus.

– General: OO, functional + imperative, concurrent

– Core calculus: Functional nets

– Sugar: Records, Lambdas, Type members.

• Wrote some programs (including parts of the Funnel

library) in Funnel.

• Quickly became apparent that encodings suck:

– Confusing for beginners

– Boring to do them over and over again for experts

5

最小言語: コアの計算レイヤ+薄めの糖衣構文

初心者には難しい。上級者には退屈。

Page 6: The Evolution of Scala / Scala進化論

Motivation for Scala

• Grew out of Funnel

• Wanted to show that we can do a practical combination

of OOP and FP.

• What got dropped:

– Concurrency was relegated to libraries

– No tight connection between language and core calculus

(fragments were studied in the νObj paper and others.)

• What got added:

– Native object and class model, Java interop, XML literals (!).

6

Scala の動機: OOP と FP の実用的な組み合わせ

Page 7: The Evolution of Scala / Scala進化論

Why a New Language?

• The OO dogma ruled then: Encapsulate

mutable data with methods.

– Infamous example: Java beans.

– There was no place for functional

programming in this.

• New at the time: Webservices that

process immutable (semi-)structured

data.

– Service sees the data “from the outside”.

– Functional programming supports that view,

e.g. using pattern matching, recursion.

• Rationale given: Would be good to have

a new FP language for webservices

7

当時は、可変データをカプセル化したOO全盛

不変データを扱うwebサービスのための新FP言語

Page 8: The Evolution of Scala / Scala進化論

8

Really, Why a new Language?

The work on Scala was motivated by two hypotheses:

Hypothesis 1: A general-purpose language needs to be scalable; the same concepts should describe small as well as large parts.

Hypothesis 2: Scalability can be achieved by unifying and generalizing functional and object-oriented programming concepts.

仮説1: 汎用言語の記述能力はスケーラブルであるべき

仮説2: OOP と FP を統一すればそれが実現できる

Page 9: The Evolution of Scala / Scala進化論

How That Worked Out

9

(from:James Iry: A Brief, Incomplete, and

Mostly Wrong History of Programming

Languages)

「OO、FP両陣営の怒りを買うことになり、それぞれが即時に聖戦を宣言した」(不完全にしておよそ正しくないプログラミング言語小史より)

Page 10: The Evolution of Scala / Scala進化論

Scala and Pizza

• Pizza (Odersky and Wadler 96) was another language

on the JVM that added functional elements to Java:

– algebraic datatypes and pattern matching

– function values

– generics

• Scala was more ambitious:

– More innovation on the OOP side

– More functional, e.g. immutable values, by-name parameters,

– Better integration of functional/oop, e.g. case classes.

– Not backwards compatible with Java

10

Pizza: 代数的データ型、パターンマッチング

Scala: より意欲的に OOP、FP を改善

Page 11: The Evolution of Scala / Scala進化論

Java Features Not kept in Scala

public

static

void

Enumerations

Annotation Syntax

Wildcard types

Raw types

Primitive types

Array types

Definite assignment rules

11

Statements:

break

continue

synchronized

assert

for (C-style)

try (resource)

super(...)

Expressions:

primitive operators

cast syntax

conditional x ? y : z

array selection a[i]

Java から持ち込まなかったもの

Page 12: The Evolution of Scala / Scala進化論

Scala Beginnings

2003: First internal use

– to teach “Functional and Logic Programming Course” at EPFL.

(2nd year, ~ 150 participants),

– despite being not really ready for the task.

2004: Official announcement of Scala 1.0

– First vocal outside users: Miles Sabin, John Pretty @ Sygneca

– Together with Iulian Dragos and myself these are probably the

only people who have used Scala continuously for 10 years.

12

2003年に EPFL での講義で使用

翌2004年に Scala 1.0 を公表

Page 13: The Evolution of Scala / Scala進化論

Scala Reloaded

2006: Scala 2.0 released

– Compiler written in Scala

– Followed the cake-pattern described “Scalable Component

Abstractions [Odersky&Zenger 05].

A few new features:

– Semicolon inference (!)

– Generalization of implicits and traits

– Automatically added empty parameter lists ()

Additions in 2.1, 2.2:

– Qualified access: private[C], protected[C]

– Multi-line string literals: ”””this is a line

and this is another”””

– Procedure syntax: def sort(xs: Array[T]) {...}

13

2.0 コンパイラを Scala で書き換え

新機能: セミコロン推論、implicit と trait の汎用化

Page 14: The Evolution of Scala / Scala進化論

Scala Reloaded

2006: Scala 2.0 released

– Compiler written in Scala

– Followed the cake-pattern described “Scalable Component

Abstractions [Odersky&Zenger 05].

A few new features:

– Semicolon inference (!)

– Generalization of implicits and traits

– Automatically added empty parameter lists ()

Additions in 2.1, 2.2:

– Qualified access: private[C], protected[C]

– Multi-line string literals: ”””this is a line

and this is another”””

– Procedure syntax: def sort(xs: Array[T]) {...}

14

空のパラメータリスト() を自動で追加

Page 15: The Evolution of Scala / Scala進化論

Learning from Experience

Scala 1.x had

– Parameterless methods supporting the uniform access principle.

def length: Int = ...

– Partially applied functions that are always eta-expanded:

def sum(f: Int => Int)(bounds: Range) = ...

val sumSquares = sum(x => x*x)

The combination of these two was a source of common

pitfalls:

println(“abc”.length) // prints: <function>

15

1.x ではeta 展開された無パラメータメソッドがよくあるハマり所だった

Page 16: The Evolution of Scala / Scala進化論

Avoiding the Pitfalls

1. Auto-add () for references f is to nullary functions

def f() = ...

2. Eta-expand only if

– expected type is a function

or

– missing parameters are specified with `_’

16

f が無項関数の場合は、() を自動追加

期待型が関数か、_ 付きの場合のみ eta展開

Page 17: The Evolution of Scala / Scala進化論

The Growth Year

2007: Scala 2.3-2.7 add lots of new features:

Extractors object Email { def unapply ... }

case Email(name, domain) => ...

Tuples (1, “a”, true)

Assignment operators +=, *=, ...

“_” notation for functions (_ + 1)

Early initialization object Foo extends { val x = 3 } with SomeTrait

Lazy values lazy val rest = f()

Higher-kinded types class Functor[F[_]] { ... }

Structural types { val key: String }

Existential types Map[T, T] forSome { type T }

17

2007年: 抽出子などの機能が続々と追加

Page 18: The Evolution of Scala / Scala進化論

Why The Rapid Growth?

• People asked for it

– “If Scala only had this one new feature, I could use it in my

organization”

• People volunteered to do it

– Lots of thoughtful suggestions on the mailing list.

– PhD students were keen to see their thesis work applied.

18

「この機能さえあればウチで採用する」

ML や博士課程の院生も協力してくれた

Page 19: The Evolution of Scala / Scala進化論

Community Formation

2007: Lift web framework launched.

2008: First Scala liftoff unconference (50 particants)

– Twitter goes public with Scala, hype starts

2009: More Scala liftoffs.

2010-14: Scala Days

– 2010 EPFL 180 participants

– 2011 Stanford 280

– 2012 London 400

– 2013 New York 500 Scala Workshop Montellier

– 2014 Berlin 800 Scala Symposium Uppsala

Lots of other meetups and conferences

19

コミュニティの形成

Page 20: The Evolution of Scala / Scala進化論

Scala 2.8 and 2.9: Consolidation

2010: Scala 2.8, with

– New collections with bitrot prevention.

– Fixed leaky array model.

– New semantics of nested packages.

– Better type inference for implicit resolution

– Lots of bug-fixes

2011: Scala 2.9, with

– Parallel collections

– Special trait DelayedInit, used in App

– Trait Dynamic, to interface with dynamic languages

20

2010年: 2.8 新コレクションライブラリ

2011年: 2.9 並列コレクション

Page 21: The Evolution of Scala / Scala進化論

Scala 2.10: Differentiation

2012: Scala 2.10, with

• New features, added through the Scala Improvement

Process (SIPs):

– Value classes class Meter(x: Long) extends AnyVal

– Implicit classes implicit class StringOps(s: String)

– String interpolation s”you have $n new calls”

• Experimental features

– Macros def await(x: Future[T]) = macro ...

– Reflection

These are only enabled when compiling with –Xexperimental

• Language imports require explicit enabling of some features

available previously.

21

2012年は分化の年。SIP による新機能や

実験的機能であるマクロなどが追加

Page 22: The Evolution of Scala / Scala進化論

Features Controlled by SIP-18

From language:

– Implicit Conversions

– Dynamic

– Postfix Operators

– Dynamic dispatch on structural types

– Existential types

– Higher-kinded types

From language.experimental

– Macros

22

SIP-18 で制御される言語機能

Page 23: The Evolution of Scala / Scala進化論

Now: Scala 2.11

• Smaller:

– broke out parts of libraries into separate modules

• Faster

– Better incremental compilation

• Stronger:

– Lots of bug fixes, tooling improvements

23

Scala 2.11: 小さく、速く、強く

Page 24: The Evolution of Scala / Scala進化論

Now: Scala.JS

Why a Scala for Javascript?

– JS is becoming ubiquitous.

– Desire to use the same language on

client and server.

– But not everybody likes Javascript or

dynamic languages.

Scala.JS profits from Scala’s tradition of

interoperating with a host language through very general

abstractions.

Can combine JS DOM and Scala collections.

For the young age of the project, very mature and well-

received.

24

JS はいたるところにある

Scala.JS も Scala流に抽象化を通じてホスト言語との互換性を実現

Page 25: The Evolution of Scala / Scala進化論

Invariants

In all this evolution, what stays constant?

What are some of the essential traits that make Scala what

it is?

25

進化の過程でも変わらない不変条件は?

Scala を特徴付ける本質は?

Page 26: The Evolution of Scala / Scala進化論

1st Invariant: A Scalable Language

• Instead of providing lots of features in the language,

have the right abstractions so that they can

be provided in libraries.

• This has worked quite well so far.

• It implicitly trusts programmers and library designers to

“do the right thing”, or at least the community to sort

things out.

26

不変条件1: スケーラブルな言語

言語は抽象化に徹して、機能はライブラリで

Page 27: The Evolution of Scala / Scala進化論

Libraries on top of Scala

27

SBT Chisel

Spark

Spray

Kafka

Akka

ScalaTest

Squeryl Specs

shapeless

Scalaz

Slick

Scala 上のライブラリ群

Page 28: The Evolution of Scala / Scala進化論

Growable = Good?

In fact, it’s a double edged sword.

– DSLs can fracture the user

community (“The Lisp curse”)

– Besides, no language is liked

by everyone, no matter whether

its a DSL or general purpose.

– Host languages get the blame

for the DSLs they embed.

Growable is great for experimentation.

But it demands conformity and discipline for large scale

production use.

28

DSL も諸刃の剣

大規模な開発では規律と協調が必要

Page 29: The Evolution of Scala / Scala進化論

• Scala’s core is its type system.

• Most of the advanced types concepts are about

flexibility, less so about safety.

2nd Invariant: It’s about the Types

29

Flexibility / Ease of Use

Safety

Scala

Trend in Type-systems

Goals of PL design

不変条件2: 型の重要性

高度な型の概念は安全性よりも柔軟性寄り

Page 30: The Evolution of Scala / Scala進化論

Stunted Evolution

null - “The Million Dollar Mistake”

• Why does Scala not have null-safety?

• We had plans to do it

you can see the traces in the stdlib with marker trait NotNull.

• But by then everybody was using already Option.

• So NPEs are actually quite rare in Scala code.

• Don’t want two ways to do the same thing.

30

実は、null 対策をする案もあったけど、

気づいたら皆 Option を使っていた

Page 31: The Evolution of Scala / Scala進化論

What’s Next?

• Scala 2.12 will be a fairly conservative evolution of 2.11

• Main feature: Java 8 interop.

– Scala and Java lambdas can understand each other

– SAM method convention added to Scala

– Should make use of Java 8 streams

– Default methods for traits?

31

2.12 の主な機能は Java 8 interop

Page 32: The Evolution of Scala / Scala進化論

And After That?

Main Goals: Make the language and its libraries

• simpler to understand,

• more robust,

• better performing

Want to continue to make it the language of choice for

smart kids.

32

より分かりやすく、堅固で、高速な

言語とライブラリを目指す

Page 33: The Evolution of Scala / Scala進化論

Scala “Aida”

Will concentrate on the standard library.

– Reduce reliance on inheritance

– Make all default collections immutable (e.g. scala.Seq will be an

alias of scala.immutable.Seq)

– Other small cleanups that are possible with a rewriting step (e.g.

rename mapValues)

Projects which might make it if they mature fast enough:

– scala.meta, the new, simplified approach to macros and

reflection.

– Collection fusion in the style of ScalaBlitz

– Better specialization through miniboxing.

33

コードネーム: Aida

標準ライブラリの強化に集中

Page 34: The Evolution of Scala / Scala進化論

Scala “Don Giovanni”

Concentrates on the language

• Simple foundations:

– A single fundamental concept - type members – can give precise

meaning to generics, existential types, and higher-kinded types.

– Intersection and union types.

– Theoretical foundations given by minimal core calculus (DOT).

• Cleaned-up syntax:

– Trait parameters instead of early definition syntax

– XML string interpolation instead of XML literals

– Procedure syntax is dropped.

– Simplified and unified type syntax for all forms of information

elision, forSome syntax is eliminated.

34

コードネーム: Don Giovanni

DOT計算の理論に基づいた言語

Page 35: The Evolution of Scala / Scala進化論

Scala “Don Giovanni”

• Removing puzzlers:

– Result types mandatory for implicit definitions.

– Inherited explicit result types take precedence over locally-

inferred ones.

– String “+” needs explicit enabling.

– Avoid surprising behavior of auto-tupling.

• Backwards compatibility:

– A migration tool will upgrade sources automatically.

– Should work for almost all commonly used code.

– Will not generally work for code using –Xexperimental

– But we aim to have features that can support analogous

functionality.

35

ハマりやすい機能の改善

後方互換性にも気をつける

Page 36: The Evolution of Scala / Scala進化論

The Growth Year, Revisited

Extractors object Email { def unapply ... } ✔ case Email(name, domain) => ...

Tuples (1, “a”, true) ✔ Assignment operators +=, *=, ++= ✔

Annotations @volatile, @deprecated ✔

“_” notation for functions (_ + 1) ✔

Early initialization object Foo extends { ✗ val x = 3 } with SomeTrait

Higher-kinded types class Functor[F[_]] { ... } ≈ Structural types { val key: String } ≈ Lazy values lazy val rest = f() ✔ Existential types Map[T, T] forSome { type T } ✗

36

成長期に入った機能の見直し

事前初期化いらない

Page 37: The Evolution of Scala / Scala進化論

Conclusion

• Languages are not cast in stone; they evolve whether

you like it or not.

• Community matters

• Community will take a language where you never

expected it to go.

In the end languages are as much social phenomena as

technical ones.

37

言語は常に進化し続ける

言語を動かすのは技術じゃなくて人