Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Scala With Style
Martin Odersky
This Talk
I’ll argue that we are at a transition period between two
programming paradigms:
Imperative/OOP  Functional.
In...
How OOP got started
First popular OO language:
Simula 67
Second popular OO language:
Smalltalk
3
Why Did OOP become popular?
Encapsulation?
Code Re-use?
Dynamic Binding
Dependency inversion?
Liskov substition
principle?...
How OOP got started
Traditional approach: Linked List
Two cases: Empty, NonEmpty
Unbounded number of operations:
– map
– r...
How OOP got started
New challenge: Simulation
Fixed number of operations:
nextStep
toString
aggregate
Unbounded number of ...
How OOP got started
New challenge: GUI widgets
Fixed number of operations:
redraw
boundingRectangle
move
Unbounded number ...
What Simulation and GUIs have in common
Both need a way to execute a fixed API with an unknown
implementation.
It’s possib...
What does this have to do with FP?
Just like OOP did then, FP has lots of methodological
advantages:
– Fewer errors
– Bett...
FP on the Rise
• In Computer Science:
Compare #attendees of OOP conferences: OOPSLA, ECOOP
with FP conference: ICFP
12 yea...
A Catalyzer
• Two forces driving software complexity:
• Multicore (= parallel programming)
• Cloud computing (= distribute...
Triple Challenge
Parallel – how to make use of multicore, GPUs,
clusters?
Async – how to deal with asynchronous events
Dis...
The Essence of Functional Programming
13
Concentrate on transformations
of immutable values
instead of stepwise modificati...
14
What about Objects?
So, should we forget OO and all program in
functional programming languages?
No! What the industry ...
15
New Objects
Previously:
“Objects are characterized by state, identity,
and behavior.” (Booch)
Now:
Eliminate or reduce ...
Can FP and OOP be combined?
16
OOP
FP
Lot’s of misunderstandings in both
communities
How many OOP
people see FP
How many F...
17
Would prefer it to be like this:
But need to get rid of some baggage
first
Bridging the Gap
• Scala acts as a bridge between
the two paradigms.
• To do this, it tries to be:
– orthogonal
– expressi...
A Question of Style
• Because Scala admits such a broad range of styles,
the question is which one to pick?
• But what is ...
Some Guidelines
20
#1 Keep it Simple
21
#2 Don’t pack too much in one expression
• I sometimes see stuff like this:
jp.getRawClasspath.filter(
_.getEntryKind == I...
Find meaningful names
• There’s a lot of value in meaningful names.
• Easy to add them using inline vals and defs.
val sou...
#3 Prefer Functional
24
Prefer Functional ...
• By default:
– use vars, not vals.
– use recursions or combinators, not loops.
– use immutable coll...
#4 ... But don’t diabolize local state
Why does mutable state lead to complexity?
It interacts with different program part...
“Var” Shortcuts
Example:
var interfaces = parseClassHeader()....
if (isAnnotation) interfaces += ClassFileAnnotation
Could...
A Question of Naming
As so often, it comes down to naming.
Do the additional intermediate results of the functional soluti...
More local state examples
• Here’s another example where local state is useful.
• Say you have a sequence of items with pr...
More local state examples
The canonical functional solution uses a foldLeft:
val (totalPrice, totalDiscount) =
items.foldL...
#5 Careful with mutable objects
Mutable objects tend to encapsulate global
state.
“Encapsulate” sounds good, but it does n...
When is an Object Mutable?
If it contains vars?
But then how about this one:
class BufferProxy[T](buf: ArrayBuffer[T]) {
d...
When is an Object Mutable?
Or this one:
class Memo[T, U](fn: T => U) {
val memo = new mutable.WeakHashMap[T, U]
def apply(...
#6 Don’t stop improving too early
• You often can shrink code by a factor of 10, and make it
more legible at the same time...
Choices
35
Choice #1: Infix vs “.”
Scala unifies operators and method calls.
Every operator is a method
Every method with at least on...
Infix vs “.”
• If the method name is symbolic, always use infix.
• For alphanumeric method names, one can use infix if
the...
Choice #2: Alphabetic vs Symbolic
Scala unifies operators and methods.
Every operator is a method.
Identifiers can be alph...
Alphabetic vs Symbolic
Recommentation: Use symbolic only if
1. Meaning is understood by your target audience
2. Operator i...
Choice #3: Loop, recursion or combinators?
Often, for the same functionality you can use a loop:
var i = 0
while (i < limi...
How About This One:
xs map f ?
var buf = new ListBuffer[String]
for (x <- xs) buf += f(x)
xs.toList ?
def recur(xs: List[S...
And How About This One:
42
xs.grouped(2).toList.map {
case List(x, y) => x * y
}
var buf = new ListBuffer[Int]
var ys = xs...
Why does Scala have all three?
• Combinators: Easiest to use, are done in the library.
• Recursive functions: bedrock of F...
Recommendation
• Consider using combinators first.
• If this becomes too tedious, or efficiency is a big
concern, fall bac...
Choice #4: Procedures or “=“
Scala has special syntax for Unit-returning procedures.
def swap[T](arr: Array[T], i: Int, j:...
Why Scala has both
• Historical accident.
• I was concerned to have to explain Unit too early to Java
programmers.
• Probl...
Recommendation
Don’t use procedure syntax.
47
Choice #5: Private vs nested
Say you have an outer method that uses a helper method for
some of its functionality:
def out...
Private as an alternative
private def isJava(sym: Symbol): Boolean =
sym hasFlag JAVA
def outer() = {
if (symbols exists i...
When to Use Nesting
You definitely want to nest if that way you avoid passing
parameters by capturing a value in the envir...
Recommendation
1. Prefer nesting if you can save on parameters.
2. Prefer nesting for small functions, even if nothing is
...
Choice #6:
Pattern matching vs dynamic dispatch
Say you have a class hierarchy of shapes.
class Shape
case class Circle(ce...
Alternative 1: Pattern matching
Could could write a single method area and match over all
possible shapes:
def area(s: Sha...
Alternative 2: Dynamic Dispatch
Or, you could add an area method to each Shape class.
class Shape {
def area: Double
}
cas...
Why Scala has Both
Pattern matching: functional, convenient
Dynamic dispatch: core mechanism for extensible systems.
55
Recommendation
• It depends whether your system should be extensible or
not.
• If you foresee extensions with new data alt...
Extensibility in both dimensions
Here’s one way to do it:
class ShapeHandler {
def area(s: Shape) = s match {
...
}
}
clas...
Choice #7:
Type parameters vs abstract members
Do you choose
class Animal[+Food] class Animal {
or type Food
def p: Animal...
Type parameters look more concise here.
But: Less pleasing to talk about Animal’s irrespective of
their food.
Animal[_] vs...
Parameter Duplication
The Scala library contains these traits:
trait Map[Key, Value] { ... }
trait SynchronizedMap[Key, Va...
Abstract Members avoid Duplication
If Map were defined like this:
class Map {
type Key
type Value
}
we could define Synchr...
What About Value Parameters?
The same question exists for value parameters, but we
have better tools to reach a synthesis....
Type Parameters = Type Members?
It would be nice if we could apply the same trick to type
parameters:
class Map[type Key, ...
Recommendation
1. By default, use type parameters.
2. Use abstract type members if the normal use case is
generic in the t...
The Future
Goal:
Make Scala the language of choice for smart kids
Bring out the simplicity in Scala
Focus on the beautiful...
Thank You
Upcoming SlideShare
Loading in …5
×

ScalaDays 2013 Keynote Speech by Martin Odersky

12,733 views

Published on

Scala gives you awesome expressive power, but how to make best use of it? In my talk I will discuss the question what makes good Scala style. We will start with syntax and continue with how to name things, how to mix objects and functions, where (and where not) to use mutable state, and when to use which design pattern. As most questions of style, the discussion will be quite subjective, and some of it might be controversial. I am looking forward to discuss these topics with the conference attendees.

Published in: Technology

ScalaDays 2013 Keynote Speech by Martin Odersky

  1. 1. Scala With Style Martin Odersky
  2. 2. This Talk I’ll argue that we are at a transition period between two programming paradigms: Imperative/OOP  Functional. In the end, we will see a fusion of these. In light of this development, many questions of programming techniques and style have to be revisited. 2
  3. 3. How OOP got started First popular OO language: Simula 67 Second popular OO language: Smalltalk 3
  4. 4. Why Did OOP become popular? Encapsulation? Code Re-use? Dynamic Binding Dependency inversion? Liskov substition principle? Open-closed principle? It was because of the things you could do with OOP! 4 No Don’t think so Not directly Came much later You gotta be kidding!
  5. 5. How OOP got started Traditional approach: Linked List Two cases: Empty, NonEmpty Unbounded number of operations: – map – reverse – print – get elem – insert – ... 5
  6. 6. How OOP got started New challenge: Simulation Fixed number of operations: nextStep toString aggregate Unbounded number of implementations: Car, Road, Molecule, Cell, Person, Building, City, ... 6
  7. 7. How OOP got started New challenge: GUI widgets Fixed number of operations: redraw boundingRectangle move Unbounded number of implementations: Window, Menu, Letter, Shape, Curve, Image, Video, ... 7
  8. 8. What Simulation and GUIs have in common Both need a way to execute a fixed API with an unknown implementation. It’s possible to do this in a procedural language such as C. But it’s too cumbersome, so people wanted object-oriented languages instead. 8
  9. 9. What does this have to do with FP? Just like OOP did then, FP has lots of methodological advantages: – Fewer errors – Better modularity – Higher-level abstractions – Shorter code – Increased developer productivity But these alone are not enough for mainstream adoption (after all FP has been around for 50 years) Need a catalyzer, something that sparks initial adoption until the other advantages become clear to everyone. 9
  10. 10. FP on the Rise • In Computer Science: Compare #attendees of OOP conferences: OOPSLA, ECOOP with FP conference: ICFP 12 years ago : ECOOP ~ 3 x ICFP OOPSLA ~ 10 x ICFP 2012 : ICFP ~ 2 x ECOOP OOPSLA stopped existing as independent conf. • Developer interest: over 100’000 signed up for our #progfun course Functional Programming Principles in Scala. 10
  11. 11. A Catalyzer • Two forces driving software complexity: • Multicore (= parallel programming) • Cloud computing (= distributed programming) • Current languages and frameworks have trouble keeping up (locks/threads don’t scale) • Need better tools with the right level of abstraction 11
  12. 12. Triple Challenge Parallel – how to make use of multicore, GPUs, clusters? Async – how to deal with asynchronous events Distributed – how to deal with delays and failures? Mutable state is a liability for each one of these! – Cache coherence – Races – Versioning 12
  13. 13. The Essence of Functional Programming 13 Concentrate on transformations of immutable values instead of stepwise modifications of mutable state.
  14. 14. 14 What about Objects? So, should we forget OO and all program in functional programming languages? No! What the industry learned about OO decomposition in analysis and design stays valid. Central question: What goes where? In the end, need to put things somewhere, or risk unmanageable global namespace.
  15. 15. 15 New Objects Previously: “Objects are characterized by state, identity, and behavior.” (Booch) Now: Eliminate or reduce mutable state. Structural equality instead of reference identity. Concentrate on functionality (behavior)
  16. 16. Can FP and OOP be combined? 16 OOP FP Lot’s of misunderstandings in both communities How many OOP people see FP How many FP people see OOP
  17. 17. 17 Would prefer it to be like this: But need to get rid of some baggage first
  18. 18. Bridging the Gap • Scala acts as a bridge between the two paradigms. • To do this, it tries to be: – orthogonal – expressive – un-opinionated • It naturally adapts to many different programming styles. 18
  19. 19. A Question of Style • Because Scala admits such a broad range of styles, the question is which one to pick? • But what is it then? I expect that a new fusion of functional and object-oriented will emerge. 19 Certainly, Scala is: – Not a better Java – Not a Haskell on the JVM
  20. 20. Some Guidelines 20
  21. 21. #1 Keep it Simple 21
  22. 22. #2 Don’t pack too much in one expression • I sometimes see stuff like this: jp.getRawClasspath.filter( _.getEntryKind == IClasspathEntry.CPE_SOURCE). iterator.flatMap(entry => flatten(ResourcesPlugin.getWorkspace. getRoot.findMember(entry.getPath))) • It’s amazing what you can get done in a single statement. • But that does not mean you have to do it. 22
  23. 23. Find meaningful names • There’s a lot of value in meaningful names. • Easy to add them using inline vals and defs. val sources = jp.getRawClasspath.filter( _.getEntryKind == IClasspathEntry.CPE_SOURCE) def workspaceRoot = ResourcesPlugin.getWorkspace.getRoot def filesOfEntry(entry: Set[File]) = flatten(workspaceRoot.findMember(entry.getPath) sources.iterator flatMap filesOfEntry 23
  24. 24. #3 Prefer Functional 24
  25. 25. Prefer Functional ... • By default: – use vars, not vals. – use recursions or combinators, not loops. – use immutable collections – concentrate on transformations, not CRUD. • When to deviate from the default: – Sometimes, mutable gives better performance. – Sometimes (but not that often!) it adds convenience. 25
  26. 26. #4 ... But don’t diabolize local state Why does mutable state lead to complexity? It interacts with different program parts in ways that are hard to track. => Local state is less harmful than global state. 26
  27. 27. “Var” Shortcuts Example: var interfaces = parseClassHeader().... if (isAnnotation) interfaces += ClassFileAnnotation Could have written: val parsedIfaces = parseClassHeader() val interfaces = if (isAnnotation) parsedIfaces + ClassFileAnnotation else parsedIfaces But this is not necessarily clearer. 27
  28. 28. A Question of Naming As so often, it comes down to naming. Do the additional intermediate results of the functional solution help understanding? val parsedIfaces = parseClassHeader() val interfaces = if (isAnnotation) parsedIfaces + ClassFileAnnotation else parsedIfaces 28
  29. 29. More local state examples • Here’s another example where local state is useful. • Say you have a sequence of items with price and discount attributes. • Compute separately the sums of all prices and all discounts val totalPrice = items.map(_.price).sum val totalDiscount = items.map(_.discount).sum • Now, do the same with just one sequence traversal (maybe because items is an iterator). 29
  30. 30. More local state examples The canonical functional solution uses a foldLeft: val (totalPrice, totalDiscount) = items.foldLeft((0.0, 0.0)) { case ((tprice, tdiscount), item) => (tprice + item.price, tdiscount + item.discount) } } Whereas the canonical imperative solution looks like this: var totalPrice, totalDiscount = 0.0 for (item <- items) { totalPrice += item.price totalDiscount += item.discount } 30
  31. 31. #5 Careful with mutable objects Mutable objects tend to encapsulate global state. “Encapsulate” sounds good, but it does not make the global state go away! => Still a lot of potential for complex entanglements. 31
  32. 32. When is an Object Mutable? If it contains vars? But then how about this one: class BufferProxy[T](buf: ArrayBuffer[T]) { def put(x: T) = buf.append(x) def length = buf.length } 32
  33. 33. When is an Object Mutable? Or this one: class Memo[T, U](fn: T => U) { val memo = new mutable.WeakHashMap[T, U] def apply(x: T) = memo.getOrElseUpdate(x, fn(x)) } An object is mutable if its (functional) behavior depends on its history. new Memo { i: Int => i + 1 } // immutable var ctr = 0 new Memo { i: Int => ctr += i; ctr } // mutable 33
  34. 34. #6 Don’t stop improving too early • You often can shrink code by a factor of 10, and make it more legible at the same time. • But the cleanest and most elegant solutions do not always come to mind at once. • That’s OK. It’s great to experience the pleasure to find a better solution multiple times. So, keep going ... 34
  35. 35. Choices 35
  36. 36. Choice #1: Infix vs “.” Scala unifies operators and method calls. Every operator is a method Every method with at least one parameter can be used as an infix operator. How do you choose? items + 10 or items.+(10) ? xs map f or xs.map(f) ? xs flatMap or xs.flatMap(fun) ? fun filterNot .filterNot(isZero) isZero groupBy keyFn .groupBy(keyFn) 36
  37. 37. Infix vs “.” • If the method name is symbolic, always use infix. • For alphanumeric method names, one can use infix if there is only one alphanumeric operator in the expression mapping add filter • But prefer “.method(...)” for chained operators: mapping.add(filter).map(second).flatMap(third) xs.map(f).mkString 37
  38. 38. Choice #2: Alphabetic vs Symbolic Scala unifies operators and methods. Every operator is a method. Identifiers can be alphanumeric or symbolic. How do you choose? xs map f or xs *|> f ? vector + mx or vector add mx ? (xs.foldLeft(z))(op) or (z /: xs)(op) ? UNDEFINED or ??? ? 38
  39. 39. Alphabetic vs Symbolic Recommentation: Use symbolic only if 1. Meaning is understood by your target audience 2. Operator is standard in application domain, or 3. You would like to draw attention to the operator (symbolic usually sticks out more than alphabetic). (Reason 3 is risky) 39
  40. 40. Choice #3: Loop, recursion or combinators? Often, for the same functionality you can use a loop: var i = 0 while (i < limit && !qualifies(i)) i += 1 i Or you could use recursion: def recur(i: Int): Int = if (i >= limit || qualifies(i)) i else recur(i + 1) recur(0) Or you could use predefined combinators: (0 until length).find(qualifies).getOrElse(length) How do you choose? 40
  41. 41. How About This One: xs map f ? var buf = new ListBuffer[String] for (x <- xs) buf += f(x) xs.toList ? def recur(xs: List[String]) = xs match { case x :: xs1 => f(x) :: recur(xs1) case Nil => Nil } ? 41
  42. 42. And How About This One: 42 xs.grouped(2).toList.map { case List(x, y) => x * y } var buf = new ListBuffer[Int] var ys = xs while (ys.nonEmpty) { buf += ys(0) * ys(1) ys = ys.tail.tail } def recur(xs: List[Int]): List[Int] = xs match { case x1 :: x2 :: xs1 => (x1 * x2) :: recur(xs1) case Nil => Nil } recur(xs) Clearly the worst Great if you know the combinators... ... and everybody else does as well. Easier to grasp for newcomers, and they tend to be more efficient as well.
  43. 43. Why does Scala have all three? • Combinators: Easiest to use, are done in the library. • Recursive functions: bedrock of FP • Pattern matching: Much clearer and safer than tests and selections. • Loops: Because they are familiar, and sometimes are the simplest solution. 43
  44. 44. Recommendation • Consider using combinators first. • If this becomes too tedious, or efficiency is a big concern, fall back on tail-recursive functions. • Loops can be used in simple cases, or when the computation inherently modifies state. 44
  45. 45. Choice #4: Procedures or “=“ Scala has special syntax for Unit-returning procedures. def swap[T](arr: Array[T], i: Int, j: Int) { val t = arr(i); arr(i) = arr(j); arr(j) = t } or: def swap[T](arr: Array[T], i: Int, j: Int): Unit = { val t = arr(i); arr(i) = arr(j); arr(j) = t } Which do you choose? 45
  46. 46. Why Scala has both • Historical accident. • I was concerned to have to explain Unit too early to Java programmers. • Problem: This trades simplicity for ease of use/familiarity. • Also, opens up a bad trap: def swap(arr: Array[T], i: Int, j: Int): Unit { val t = arr(i); arr(i) = arr(j); arr(j) = t } 46
  47. 47. Recommendation Don’t use procedure syntax. 47
  48. 48. Choice #5: Private vs nested Say you have an outer method that uses a helper method for some of its functionality: def outer(owner: Symbol) = { def isJava(sym: Symbol): Boolean = sym hasFlag JAVA if (symbols exists isJava) ... ... } Do you write isJava inline, or as a separate private method? 48
  49. 49. Private as an alternative private def isJava(sym: Symbol): Boolean = sym hasFlag JAVA def outer() = { if (symbols exists isJava) ... ... } • Advantahe 49
  50. 50. When to Use Nesting You definitely want to nest if that way you avoid passing parameters by capturing a value in the environment. def outer(owner: Symbol) = { def isJava(sym: Symbol): Boolean = (sym hasFlag JAVA) || owner.isJava if (symbols exists isJava) ... ... } But if you do not capture anything it becomes harder to verify that fact if you have to scan lots of nested code. 50
  51. 51. Recommendation 1. Prefer nesting if you can save on parameters. 2. Prefer nesting for small functions, even if nothing is captured. 3. Don’t nest many levels deep. 51
  52. 52. Choice #6: Pattern matching vs dynamic dispatch Say you have a class hierarchy of shapes. class Shape case class Circle(center: Point, radius: Double) extends Shape case class Rectangle(ll: Point, ur: Point) extends Shape case class Point(x: Double, y: Double) extends Shape and you want to write a method to compute the area of a shape. 52
  53. 53. Alternative 1: Pattern matching Could could write a single method area and match over all possible shapes: def area(s: Shape): Double = s match { case Circle(_, r) => math.pi * r * r case Rectangle(ll, ur) => (ur.x – ll.x) * (ur.y – ll.y) case Point(_, _) => 0 } 53
  54. 54. Alternative 2: Dynamic Dispatch Or, you could add an area method to each Shape class. class Shape { def area: Double } case class Circle(center: Point, radius: Double) extends Shape { def area = pi * radius * radius } case class Rectangle(ll: Point, ur: Point) extends Shape { def area = (ur.x – ll.x) * (ur.y – ll.y) } Which do you choose? 54
  55. 55. Why Scala has Both Pattern matching: functional, convenient Dynamic dispatch: core mechanism for extensible systems. 55
  56. 56. Recommendation • It depends whether your system should be extensible or not. • If you foresee extensions with new data alternatives, choose dynamic dispatch. • If you foresee adding new methods later, choose pattern matching. • If the system is complex and closed, also choose pattern matching. • What if you want to extend in both dimensions? 56
  57. 57. Extensibility in both dimensions Here’s one way to do it: class ShapeHandler { def area(s: Shape) = s match { ... } } class ExtraShapeHandler { def area(s: Shape) = s match { case Triangle(...) => ... case _ => super.area(s) } “The expression problem”. 57
  58. 58. Choice #7: Type parameters vs abstract members Do you choose class Animal[+Food] class Animal { or type Food def p: Animal[Food] def p: Animal { type Food = this.Food } } class Cow class Cow extends Animal { extends Animal[Grass] type Food <: Grass } ? 58
  59. 59. Type parameters look more concise here. But: Less pleasing to talk about Animal’s irrespective of their food. Animal[_] vs Animal Also, sometimes parameters need to be duplicated. And, it gets complicated when there are bounds that refer to each other. 59
  60. 60. Parameter Duplication The Scala library contains these traits: trait Map[Key, Value] { ... } trait SynchronizedMap[Key, Value] extends Map[Key, Value] Duplication! And it does not stop there: new HashMap[String, Int] with SynchronizedMap[String, Int] 60
  61. 61. Abstract Members avoid Duplication If Map were defined like this: class Map { type Key type Value } we could define SynchronizedMap like this: class SynchronizedMap extends Map and we could create a map like this: new HashMap with SynchronizedMap { type Key = String type Value = Int } 61
  62. 62. What About Value Parameters? The same question exists for value parameters, but we have better tools to reach a synthesis. Example: Should I write class C(x: Int) or abstract class C { val x: Int } ? Can combine both using a val parameter. class C(val x: Int) 62
  63. 63. Type Parameters = Type Members? It would be nice if we could apply the same trick to type parameters: class Map[type Key, type Value] class SynchronizedMap extends Map new Map[String, Int] with SynchronizedMap This is currently not supported. But we are working on a design that would let us do that. 63
  64. 64. Recommendation 1. By default, use type parameters. 2. Use abstract type members if the normal use case is generic in the type. 3. (That, is, avoid wildcards such as Animal[_] 64
  65. 65. The Future Goal: Make Scala the language of choice for smart kids Bring out the simplicity in Scala Focus on the beautiful side, avoid over-complications 65
  66. 66. Thank You

×