Your SlideShare is downloading. ×
ScalaDays 2013 Keynote Speech by Martin Odersky
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

ScalaDays 2013 Keynote Speech by Martin Odersky


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 …

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

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Scala With Style Martin Odersky
  • 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. How OOP got started First popular OO language: Simula 67 Second popular OO language: Smalltalk 3
  • 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. How OOP got started Traditional approach: Linked List Two cases: Empty, NonEmpty Unbounded number of operations: – map – reverse – print – get elem – insert – ... 5
  • 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. 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. 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. 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. 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. 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. 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. The Essence of Functional Programming 13 Concentrate on transformations of immutable values instead of stepwise modifications of mutable state.
  • 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 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. 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 Would prefer it to be like this: But need to get rid of some baggage first
  • 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. 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. Some Guidelines 20
  • 21. #1 Keep it Simple 21
  • 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. 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. #3 Prefer Functional 24
  • 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. #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. “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. 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. 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 = val totalDiscount = • Now, do the same with just one sequence traversal (maybe because items is an iterator). 29
  • 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 + } } Whereas the canonical imperative solution looks like this: var totalPrice, totalDiscount = 0.0 for (item <- items) { totalPrice += item.price totalDiscount += } 30
  • 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. 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. 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. #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. Choices 35
  • 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 flatMap or xs.flatMap(fun) ? fun filterNot .filterNot(isZero) isZero groupBy keyFn .groupBy(keyFn) 36
  • 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) 37
  • 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. 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. 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. 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. And How About This One: 42 xs.grouped(2) { 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. 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. 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. 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. 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. Recommendation Don’t use procedure syntax. 47
  • 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. Private as an alternative private def isJava(sym: Symbol): Boolean = sym hasFlag JAVA def outer() = { if (symbols exists isJava) ... ... } • Advantahe 49
  • 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. 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. 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. 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. 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. Why Scala has Both Pattern matching: functional, convenient Dynamic dispatch: core mechanism for extensible systems. 55
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Thank You