Meet-up, May 28, 2015, Launchpad, Bangkok. http://www.meetup.com/Software-Engineering-Thailand/events/222548484/. Apologies for the rendering quality not matching the presentation, I did these with Apple Keynote and Slideshare does not support this format. I will try to edit them when there is more time. Thanks to Bangkok LaunchPad (https://www.facebook.com/launchpadhq) for generously hosting this event!

1. Programming with Scala
Brian Topping
Mauswerks LLC

2. About Me
• Globally experienced dev with over 25 years professional experience
• Have led teams of three to fifteen developers as lead developer,
architect, general manager. Start projects first, then hire when ten
fingers are not enough.
• Have been using Scala since 2012, JDK Open Source since 2001
• Interests: Functional Reactive Programming, financial markets,
machine learning, Javascript, travel, motorcycles
• Shameless plug: Available for investment or work in BKK
• http://github.com/briantopping
http://twitter.com/briantopping
http://linkedin.com/in/briantopping

3. Why Scala?

4. What is wrong with this picture?

5. • "Looks good to me, ship it!"

6. • "Looks good to me, ship it!"
• We're at the wrong level of zoom to see problems

7. • "Looks good to me, ship it!"
• We're at the wrong level of zoom to see problems
•

8. • "Looks good to me, ship it!"
• We're at the wrong level of zoom to see problems
•
• Solutions at a global level must factor problems at the
local level.

9. • "Looks good to me, ship it!"
• We're at the wrong level of zoom to see problems
•
• Solutions at a global level must factor problems at the
local level.
• Complexity is the natural tradeoff

10. What is Scala?
• Object Oriented / Functional hybrid
• Compiled to JVM bytecode
• Statically typed (compile time)
• Strongly typed (types must match)
• Growing ecosystem
• Language is stable and mature

11. (a few) Benefits of Scala
• Seamless Java / JDK ecosystem interoperability
• Type Inferencing & Parameterization
• Concurrency & Distribution
• Collections Classes
• Pattern Matching
• Obvious Correctness

12. Standard Example

13. Standard Example
• Java "Bean"

14. Standard Example
• Java "Bean"

15. Standard Example
• Java "Bean"
• Scala Case Class

16. Standard Example
• Java "Bean"
• Scala Case Class

17. Standard Example
• Java "Bean"
• Scala Case Class

18. Java / JDK Interoperability

19. Java / JDK Interoperability
• Scala classes are JVM classes

20. Java / JDK Interoperability
• Scala classes are JVM classes
• Groovy, Clojure, JRuby, Jython – 40+ in all!

21. Java / JDK Interoperability
• Scala classes are JVM classes
• Groovy, Clojure, JRuby, Jython – 40+ in all!
• Scala is a mixed Object + Functional language

22. Java / JDK Interoperability
• Scala classes are JVM classes
• Groovy, Clojure, JRuby, Jython – 40+ in all!
• Scala is a mixed Object + Functional language
• It is possible and common for young teams to start
writing Scala with Java style (OOD) and API, test
with existing tools

23. Java / JDK Interoperability
• Scala classes are JVM classes
• Groovy, Clojure, JRuby, Jython – 40+ in all!
• Scala is a mixed Object + Functional language
• It is possible and common for young teams to start
writing Scala with Java style (OOD) and API, test
with existing tools
• Take advantage of Java libraries

24. Java / JDK Interoperability
• Scala classes are JVM classes
• Groovy, Clojure, JRuby, Jython – 40+ in all!
• Scala is a mixed Object + Functional language
• It is possible and common for young teams to start
writing Scala with Java style (OOD) and API, test
with existing tools
• Take advantage of Java libraries

25. Type Inference &
Immutability Focus

26. Type Inference &
Immutability Focus
• Compiler knows the type of an assignment, yet most
languages require the developer to prove it

27. Type Inference &
Immutability Focus
• Compiler knows the type of an assignment, yet most
languages require the developer to prove it
• Java:

28. Type Inference &
Immutability Focus
• Compiler knows the type of an assignment, yet most
languages require the developer to prove it
• Java:
• Scala:

29. Type Inference &
Immutability Focus
• Compiler knows the type of an assignment, yet most
languages require the developer to prove it
• Java:
• Scala:
• Built for immutability!

30. Type Inference &
Immutability Focus
• Compiler knows the type of an assignment, yet most
languages require the developer to prove it
• Java:
• Scala:
• Built for immutability!
• Use the var keyword for mutable variables

31. Type Inference &
Immutability Focus
• Compiler knows the type of an assignment, yet most
languages require the developer to prove it
• Java:
• Scala:
• Built for immutability!
• Use the var keyword for mutable variables
• One finds themselves using it less and less often!

32. Type Parameterization

33. Type Parameterization
• Types allow you to denote function domain & codomains. For example, from
mathematics, we are used to seeing:
this tells us that function “f” maps values from the set of real numbers to values
of the set of natural numbers

34. Type Parameterization
• Types allow you to denote function domain & codomains. For example, from
mathematics, we are used to seeing:
this tells us that function “f” maps values from the set of real numbers to values
of the set of natural numbers
• In the abstract, this is exactly what concrete types are. Type systems give us
some more powerful ways to express these sets

35. Type Parameterization
• Types allow you to denote function domain & codomains. For example, from
mathematics, we are used to seeing:
this tells us that function “f” maps values from the set of real numbers to values
of the set of natural numbers
• In the abstract, this is exactly what concrete types are. Type systems give us
some more powerful ways to express these sets
• Given these annotations, the compiler can now statically (at compile time) verify
that the program is sound

36. Type Parameterization
• Types allow you to denote function domain & codomains. For example, from
mathematics, we are used to seeing:
this tells us that function “f” maps values from the set of real numbers to values
of the set of natural numbers
• In the abstract, this is exactly what concrete types are. Type systems give us
some more powerful ways to express these sets
• Given these annotations, the compiler can now statically (at compile time) verify
that the program is sound
• Variance annotations allow you to express relationships between class
hierarchies & polymorphic types

37. Type Parameterization
• Types allow you to denote function domain & codomains. For example, from
mathematics, we are used to seeing:
this tells us that function “f” maps values from the set of real numbers to values
of the set of natural numbers
• In the abstract, this is exactly what concrete types are. Type systems give us
some more powerful ways to express these sets
• Given these annotations, the compiler can now statically (at compile time) verify
that the program is sound
• Variance annotations allow you to express relationships between class
hierarchies & polymorphic types
• Reference: http://twitter.github.io/scala_school/type-basics.html

38. Concurrency & Distribution

39. Concurrency & Distribution
• Futures and Promises – Long history across platforms

40. Concurrency & Distribution
• Futures and Promises – Long history across platforms
• Factory objects look like integral part of language

41. Concurrency & Distribution
• Futures and Promises – Long history across platforms
• Factory objects look like integral part of language
• Remember that functions are parameters!

42. Concurrency & Distribution
• Futures and Promises – Long history across platforms
• Factory objects look like integral part of language
• Remember that functions are parameters!
•

43. Concurrency & Distribution
• Futures and Promises – Long history across platforms
• Factory objects look like integral part of language
• Remember that functions are parameters!
•
• Don't return values, return a Future!

44. Concurrency & Distribution
• Futures and Promises – Long history across platforms
• Factory objects look like integral part of language
• Remember that functions are parameters!
•
• Don't return values, return a Future!
• Akka-HTTP is a perfect example, you can return a value, but then your
code manages the concurrency. Return a Future to the caller and let it
manage it instead!

45. Concurrency & Distribution
• Futures and Promises – Long history across platforms
• Factory objects look like integral part of language
• Remember that functions are parameters!
•
• Don't return values, return a Future!
• Akka-HTTP is a perfect example, you can return a value, but then your
code manages the concurrency. Return a Future to the caller and let it
manage it instead!
• Unlike Node, full access to all cores.

46. Collections Classes

47. Collections Classes
• Scala Collections are what brought me to the language

48. Collections Classes
• Scala Collections are what brought me to the language
• Designed to consistently behave as a collections DSL

49. Collections Classes
• Scala Collections are what brought me to the language
• Designed to consistently behave as a collections DSL
• Immutable by default, great for parallel deployments

50. Collections Classes
• Scala Collections are what brought me to the language
• Designed to consistently behave as a collections DSL
• Immutable by default, great for parallel deployments
• Java

51. Collections Classes
• Scala Collections are what brought me to the language
• Designed to consistently behave as a collections DSL
• Immutable by default, great for parallel deployments
• Java
•

52. Collections Classes
• Scala Collections are what brought me to the language
• Designed to consistently behave as a collections DSL
• Immutable by default, great for parallel deployments
• Java
•
• Scala

53. Collections Classes
• Scala Collections are what brought me to the language
• Designed to consistently behave as a collections DSL
• Immutable by default, great for parallel deployments
• Java
•
• Scala
•

54. Collections Classes
• Scala Collections are what brought me to the language
• Designed to consistently behave as a collections DSL
• Immutable by default, great for parallel deployments
• Java
•
• Scala
•
• Don't get the wrong idea here! Rolling a one-liner into a println is not what I'd call
"good style". Instead, note how the functional transparency and type inferencing
allows us to inline functions as easily as we can assign them to variables.

55. Pattern Matching

56. Pattern Matching
• Partial Functions – A function that is only defined for
specific input values

57. Pattern Matching
• Partial Functions – A function that is only defined for
specific input values
•

58. Pattern Matching
• Partial Functions – A function that is only defined for
specific input values
•
• Regular Expressions – Please enjoy them now! 😉

59. Pattern Matching
• Partial Functions – A function that is only defined for
specific input values
•
• Regular Expressions – Please enjoy them now! 😉
•

60. Obvious Correctness

61. Obvious Correctness
• Trick question: Which of these is more obviously correct?

62. Obvious Correctness
• Trick question: Which of these is more obviously correct?
• Java:

63. Obvious Correctness
• Trick question: Which of these is more obviously correct?
• Java:
• Scala:

64. Obvious Correctness
• Trick question: Which of these is more obviously correct?
• Java:
• Scala:
• Depends on experience!!

65. Team Evolution w/ Scala

66. Team Evolution w/ Scala
• Start with this:

67. Team Evolution w/ Scala
• Start with this:
• To get to this:

68. Team Evolution w/ Scala
• Start with this:
• To get to this:
• Make the transition gradually! Do it together as a team!

69. What does all this buy us?

70. What does all this buy us?
• Pure functions have no side effects... data in, data out

71. What does all this buy us?
• Pure functions have no side effects... data in, data out
• Objects maintain state. This is why Scala is not
considered a purely functional language!

72. What does all this buy us?
• Pure functions have no side effects... data in, data out
• Objects maintain state. This is why Scala is not
considered a purely functional language!
• When objects are immutable though, the state acts as
constants in the functions. Constants are thread-safe!

73. What does all this buy us?
• Pure functions have no side effects... data in, data out
• Objects maintain state. This is why Scala is not
considered a purely functional language!
• When objects are immutable though, the state acts as
constants in the functions. Constants are thread-safe!
• Immutable objects do not need to be locked. Locking is
actually very expensive and error prone

74. What does all this buy us?
• Pure functions have no side effects... data in, data out
• Objects maintain state. This is why Scala is not
considered a purely functional language!
• When objects are immutable though, the state acts as
constants in the functions. Constants are thread-safe!
• Immutable objects do not need to be locked. Locking is
actually very expensive and error prone
• Immutable state is updated by replacing the object!

75. But it looks so complex!

76. But it looks so complex!
• Scala actually has a smaller grammar than Java

77. But it looks so complex!
• Scala actually has a smaller grammar than Java
• Functional composition (the ability for one function to feed
another) allows intermediate variables to be removed.

78. But it looks so complex!
• Scala actually has a smaller grammar than Java
• Functional composition (the ability for one function to feed
another) allows intermediate variables to be removed.
• Scala ends up looking complex because developers collapse
code that maybe shouldn't be collapsed.

79. But it looks so complex!
• Scala actually has a smaller grammar than Java
• Functional composition (the ability for one function to feed
another) allows intermediate variables to be removed.
• Scala ends up looking complex because developers collapse
code that maybe shouldn't be collapsed.
• Program so your code is readable, not so it fits in as few
lines as possible.

80. But it looks so complex!
• Scala actually has a smaller grammar than Java
• Functional composition (the ability for one function to feed
another) allows intermediate variables to be removed.
• Scala ends up looking complex because developers collapse
code that maybe shouldn't be collapsed.
• Program so your code is readable, not so it fits in as few
lines as possible.
• Occam's Razor: We should reduce to the simplest possible
outcome, and no simpler!

81. Some things haven't changed

82. Some things haven't changed
• TDD – Use it! Create unit tests for everything, use them as documentation

83. Some things haven't changed
• TDD – Use it! Create unit tests for everything, use them as documentation
• One liners should have a simple comment describing what they do

84. Some things haven't changed
• TDD – Use it! Create unit tests for everything, use them as documentation
• One liners should have a simple comment describing what they do
• Frequent code reviews! Pull requests that receive no comments are to be
avoided.

85. Some things haven't changed
• TDD – Use it! Create unit tests for everything, use them as documentation
• One liners should have a simple comment describing what they do
• Frequent code reviews! Pull requests that receive no comments are to be
avoided.
• Avoid learning a new technique and immediately using it everywhere.

86. Some things haven't changed
• TDD – Use it! Create unit tests for everything, use them as documentation
• One liners should have a simple comment describing what they do
• Frequent code reviews! Pull requests that receive no comments are to be
avoided.
• Avoid learning a new technique and immediately using it everywhere.
• If you are the only person that can maintain your code, you will be cursed
to own it forever.

87. Some things haven't changed
• TDD – Use it! Create unit tests for everything, use them as documentation
• One liners should have a simple comment describing what they do
• Frequent code reviews! Pull requests that receive no comments are to be
avoided.
• Avoid learning a new technique and immediately using it everywhere.
• If you are the only person that can maintain your code, you will be cursed
to own it forever.
• If you can inspire others to read your code because it is both short and
people "learn one new thing" (only one!), you will be able to move the team
forward with new techniques, do more with less, have fun!

88. I'm not sold yet...

89. I'm not sold yet...
• Take Coursera's Scala class taught by Martin Odersky

90. I'm not sold yet...
• Take Coursera's Scala class taught by Martin Odersky
• You will become a better Scala programmer

91. I'm not sold yet...
• Take Coursera's Scala class taught by Martin Odersky
• You will become a better Scala programmer
• You will become a better Java programmer

92. I'm not sold yet...
• Take Coursera's Scala class taught by Martin Odersky
• You will become a better Scala programmer
• You will become a better Java programmer
• You will become a better programmer

93. I'm not sold yet...
• Take Coursera's Scala class taught by Martin Odersky
• You will become a better Scala programmer
• You will become a better Java programmer
• You will become a better programmer
• Apple's Swift language is a bit of a knockoff

94. I'm not sold yet...
• Take Coursera's Scala class taught by Martin Odersky
• You will become a better Scala programmer
• You will become a better Java programmer
• You will become a better programmer
• Apple's Swift language is a bit of a knockoff
• Get two platforms for the price of one!

95. How Do I Get Started?

96. IDEs: IntelliJ vs. Eclipse

97. IDEs: IntelliJ vs. Eclipse

98. IDEs: IntelliJ vs. Eclipse

99. IDEs: IntelliJ vs. Eclipse
• They both have advantages. Each team should "bake off" and doc the results

100. IDEs: IntelliJ vs. Eclipse
• They both have advantages. Each team should "bake off" and doc the results
• Don't be restricted to one, but a common denominator of skills is helpful

101. Testing

102. Testing
• ScalaTest is standard

103. Testing
• ScalaTest is standard
• Behavior Driven Development

104. Testing
• ScalaTest is standard
• Behavior Driven Development
• Use with TDD, just works!

105. Testing
• ScalaTest is standard
• Behavior Driven Development
• Use with TDD, just works!
• The power is in the Matchers

106. Development Environments

107. Development Environments
• REPL (Read-Eval-Print Loop) is an interactive shell

108. Development Environments
• REPL (Read-Eval-Print Loop) is an interactive shell
• scalac compiler can be run from command line like javac

109. Development Environments
• REPL (Read-Eval-Print Loop) is an interactive shell
• scalac compiler can be run from command line like javac
• SBT is Scala's own build tool, allows Scala code to be used within build, but not
very IDE friendly.

110. Development Environments
• REPL (Read-Eval-Print Loop) is an interactive shell
• scalac compiler can be run from command line like javac
• SBT is Scala's own build tool, allows Scala code to be used within build, but not
very IDE friendly.
• Maven has a Scala plugin, but comes with all of Maven's idiosyncrasies.

111. Development Environments
• REPL (Read-Eval-Print Loop) is an interactive shell
• scalac compiler can be run from command line like javac
• SBT is Scala's own build tool, allows Scala code to be used within build, but not
very IDE friendly.
• Maven has a Scala plugin, but comes with all of Maven's idiosyncrasies.
• SBT can use Maven central repository, but is designed for Ivy repositories. Both
end up being required, which is a pain point.

112. Development Environments
• REPL (Read-Eval-Print Loop) is an interactive shell
• scalac compiler can be run from command line like javac
• SBT is Scala's own build tool, allows Scala code to be used within build, but not
very IDE friendly.
• Maven has a Scala plugin, but comes with all of Maven's idiosyncrasies.
• SBT can use Maven central repository, but is designed for Ivy repositories. Both
end up being required, which is a pain point.
• All the cool kids use SBT, but it's not as mature and harder to use with projects
that span multiple source repositories, also not as simple for tagged release
environments.

113. Development Environments
• REPL (Read-Eval-Print Loop) is an interactive shell
• scalac compiler can be run from command line like javac
• SBT is Scala's own build tool, allows Scala code to be used within build, but not
very IDE friendly.
• Maven has a Scala plugin, but comes with all of Maven's idiosyncrasies.
• SBT can use Maven central repository, but is designed for Ivy repositories. Both
end up being required, which is a pain point.
• All the cool kids use SBT, but it's not as mature and harder to use with projects
that span multiple source repositories, also not as simple for tagged release
environments.
• Verdict: If you already use Maven, stick with it, otherwise use SBT.

114. Concurrency & Distribution
Part 2

115. Concurrency & Distribution
Part 2
• Use Akka – http://akka.io

116. Concurrency & Distribution
Part 2
• Use Akka – http://akka.io
• Scala and Java APIs, Scala easier to use via immutables

117. Concurrency & Distribution
Part 2
• Use Akka – http://akka.io
• Scala and Java APIs, Scala easier to use via immutables
• Message passing pattern without all the JMS overhead

118. Concurrency & Distribution
Part 2
• Use Akka – http://akka.io
• Scala and Java APIs, Scala easier to use via immutables
• Message passing pattern without all the JMS overhead
• 50 million msg/sec on a single machine + small memory footprint; ~2.5
million actors (message endpoints) per GB of heap

119. Concurrency & Distribution
Part 2
• Use Akka – http://akka.io
• Scala and Java APIs, Scala easier to use via immutables
• Message passing pattern without all the JMS overhead
• 50 million msg/sec on a single machine + small memory footprint; ~2.5
million actors (message endpoints) per GB of heap
• Remoting can scale to tens of thousands of machines

120. Concurrency & Distribution
Part 2
• Use Akka – http://akka.io
• Scala and Java APIs, Scala easier to use via immutables
• Message passing pattern without all the JMS overhead
• 50 million msg/sec on a single machine + small memory footprint; ~2.5
million actors (message endpoints) per GB of heap
• Remoting can scale to tens of thousands of machines
• Akka Streams focuses on streaming messages, uses standard TCP
facilities to throttle clients, avoid buffer overflows

121. Concurrency & Distribution
Part 2
• Use Akka – http://akka.io
• Scala and Java APIs, Scala easier to use via immutables
• Message passing pattern without all the JMS overhead
• 50 million msg/sec on a single machine + small memory footprint; ~2.5
million actors (message endpoints) per GB of heap
• Remoting can scale to tens of thousands of machines
• Akka Streams focuses on streaming messages, uses standard TCP
facilities to throttle clients, avoid buffer overflows
• 2014Q1 test reached 2400 nodes as well as starting up a 1000 node
cluster in just over four minutes on Google App Engine.

122. Who's using it?

123. Who's using it?
Just about every major player
has something in Scala:
• Apple
• Intel
• Twitter
• Agoda
• Airbnb

124. Who's using it?
Just about every major player
has something in Scala:
• Apple
• Intel
• Twitter
• Agoda
• Airbnb
And any company using
these scaling technologies:
• Apache Spark
• Apache Scalding
• Apache Kafka
• Twitter Finagle
• Typesafe Akka

125. Lessons?

126. • Every developer has the power to enlighten or obfuscate

127. • Every developer has the power to enlighten or obfuscate
• Complexity has many different measures at many
different levels. The solution of least overall complexity
often hides behind greater surface complexity!

128. • Every developer has the power to enlighten or obfuscate
• Complexity has many different measures at many
different levels. The solution of least overall complexity
often hides behind greater surface complexity!

129. • Every developer has the power to enlighten or obfuscate
• Complexity has many different measures at many
different levels. The solution of least overall complexity
often hides behind greater surface complexity!
• On first glance, Functional Programming looks difficult,
but hundreds of years of proven advanced math are
what built society – bridges, buildings, cars, computers

130. • Every developer has the power to enlighten or obfuscate
• Complexity has many different measures at many
different levels. The solution of least overall complexity
often hides behind greater surface complexity!
• On first glance, Functional Programming looks difficult,
but hundreds of years of proven advanced math are
what built society – bridges, buildings, cars, computers
• Why reinvent that wheel? Allow mathematical induction
to help your efforts.

131. • Every developer has the power to enlighten or obfuscate
• Complexity has many different measures at many
different levels. The solution of least overall complexity
often hides behind greater surface complexity!
• On first glance, Functional Programming looks difficult,
but hundreds of years of proven advanced math are
what built society – bridges, buildings, cars, computers
• Why reinvent that wheel? Allow mathematical induction
to help your efforts.
• Moore's Law has given us blessings, including the ability
to use increasingly complex compilers.

132. References + Q&A
• Scala Course:
https://www.coursera.org/course/progfun
• Please read chapter 1, available for free:
http://manning.com/kuhn/
• Twitter's Scala School:
http://twitter.github.io/scala_school/
• Scala Cheat Sheet :
http://mbonaci.github.io/scala/
• Deeper insight:
http://danielwestheide.com/scala/neophytes.html