The Evolution Of Scala презентация

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

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

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 (!).

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

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.

History of Programming Languages)

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

assignment rules

Statements:
break
continue
synchronized
assert
for (C-style)
try (resource)
super(...)
Expressions:
primitive operators
cast syntax
conditional x ? y : z
array selection a[i]

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.

“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]) {...}

“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]) {...}

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:

def f() = ...

Eta-expand only if
expected type is a function
or
missing parameters are specified with `_’

{ 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 }

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.

(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

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

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.

> implicit classes > extension methods

where “>” means more general.
Implicit conversions are very powerful
But they can be misused, in particular if there are too many of them.

the end, that’s the most productive combination.
But there are challenges.
Some combinations of language features might be less desirable than others.
How to avoid feature misuse?
Idea: Have a mechanism that demands that some problematic features are explicitly imported (Haskell uses something similar).

String): Int =
Integer.parseInt(x)
}

Compiling gives:

warning: there were 1 feature warnings; re-run with -feature for details
one warning found

String): Int =
Integer.parseInt(x)
}

Compiling with –feature gives:
letsSimulateJS.scala:8: warning: implicit conversion method foo should be enabled
by making the implicit value language.implicitConversions visible.
This can be achieved by adding the import clause 'import scala.language.implicitConversions'
or by setting the compiler option -language:implicitConversions.
See the Scala docs for value scala.language.implicitConversions for a discussion
why the feature should be explicitly enabled.
implicit def foo(x: String): Int = Integer.parseInt(x)
^
one warning found

identifier

scala.language.implicitConversions

into scope, usually, using an import:

import language.implicitConversions

types
Higher-kinded types

From language.experimental
Macros

compilation
Stronger:
Lots of bug fixes, tooling improvements

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.

essential traits that make Scala what it is?

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.

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.

are about flexibility, less so about safety.

2nd Invariant: It’s about the Types

Flexibility / Ease of Use

Safety

Scala

Trend in Type-systems

Goals of PL design

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.

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?

understand,
more robust,
better performing
Want to continue to make it the language of choice for smart kids.

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.

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.

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.

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 } ✗

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.