Scala Days 2013

by Hung Lin @hunglin

Scala the **** out of NYC

  • 3 days event @ NYC
  • Scala Sunday @ meetup HQ: 8 talks
  • Shapeless workshop on Monday

Hot Topics

  • Scala 2.10
  • Style of Scala*
  • Asynchronous Programming - akka
  • Big Data / Streaming Data - Spark
  • Macro
  • Play

Keynote: Scala with Style

by Martin Odersky, creator of scala

What is OOP good for?

  • Fixed APIs with unknown implementations. e.g. Simula67 for simulation, Smalltalk for GUI
  • Objects are characterized by state, identity and behavior - Grady Booch

OOP v.s. FP

Guideline #1
Keep it simple

Simple Made Easy - Rich Hichey

Guideline #2
Don't pack too much in one expression

find meaningful names for the intermediate results. It's not easy but it's important

Guideline #3
Prefer Functional

  • vals v.s. vars
  • recursions or combinators v.s. loops
  • immutable v.s. mutable collections
  • transformations v.s. CRUD*

Guideline #4
But, don't diabolize local state

  • sometimes, mutable gives better performance
  • sometimes, mutable adds convenience

vars v.s. vals


var interfaces = parseClassHeader()...
if (isAnnotation) interfaces += ClassFileAnnotation
						

val parsedIfaces = parseClassHeader()...
val interfaces =
  if (isAnnotation) parsedIfaces + ClassFileAnnotation
  else parsedIfaces

loops v.s. combinators


val totalPrice = items.map(_.price).sum
val totalDiscount = items.map(_.discount).sum
						

val (totalPrice, totalDiscount) = 
  items.foldLeft((0.0, 0.0)) {
  	case ((tprice, tdiscount), item) => (tprice + item.price, tdiscount + item.discount)
  }
						

var totalPrice, totalDiscount = 0.0
for (item <- items) {
  totalPrice += item.price
  totalDiscount += item.discount
}

Guideline #5
Careful with mutable objects


val m = ArrayBuffer[Int]()

Guideline #6
Don't stop improving too early

  • shrink code by factor of 10 + make it more readable at the same time
  • clean and elegant solutions don't come to mind at the first time
  • it is fun to find better solutions

Choice #1
Infix v.s. "."

Choice #2
Alphabetic v.s. Symbolic


val xs = List("apples", "oranges", "pears")

xs.foldLeft("")((result, i) => result + i)

("" /: xs)((result, i) => result + i)

Choice #3
Loop, recursion or combinators

  • try conbinators first
  • if it becomes too tedious, or efficiency is a big concern, try tail-recursion
  • use loop for simple case or for readability

Choice #4
Procedures or "="

DON'T use procedure syntax


def method: Unit = {
  // operations
}

Choice #5
Private v.s. nested

  • use nested function to avoid passing parameters
  • use nested function for small functions
  • don't nest too many levels

Choice #6
pattern matching v.s. dynamic dispatch

the expression problem, check out scala class @ coursera, lecture 4.5 and 4.6

Choice #7
type parameters v.s. abstract type members

a good article by Bill Venners

  • try type parameters first
  • avoid Animals[_]

Keynote: Scala in 2018

by Rod Johnson, creator of Spring

in 2018

  • Java is still alive
  • Enterprise apps are using Scala
  • Startups are still NOT using Scala

myths / points

  • Readability over cleverness, LOC, FP, ...
  • Scala needs coding standard
  • Scala needs to move slower
  • Embracing instead of hating Java

Any fool can write code that a computer can understand. Good programmers write code that human can understand.
- Martin Fowler

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
- Brian Kernighan

Asynchronous Programming

asynchronous v.s. parallel

  • what else?
  • who's doing it?

asynchronous v.s. batching

pitfall: thread pool?

for tomcat, one thread handles one request

pitfall: back pressure

pitfall: performance v.s. scaling issue

pitfall: theory v.s. reality

  • cost of thread context switch
  • # of threads v.s. # of CPUs
  • where is the bottleneck?

Some thoughts about our system

Upgrade to scala 2.10

Use akka

  • asynchronous programming
  • fault tolerance
  • modular design

Use case class for data model

  • treat data as map

Use finagle for service modules

  • play is not for REST API
  • why pay the cost of HTTP?
  • statistics
  • separate REST and Data layer
  • modularity

Questions?