Tech Talk - Things I Learned at Scala Days 2013

Scala Days 2013by Hung Lin @hunglin

Scala the **** out of NYC3 days event @ NYCScala Sunday @ meetup HQ: 8 talksShapeless workshop on Monday

Hot TopicsScala 2.10Style of Scala*Asynchronous Programming - akkaBig Data / Streaming Data - SparkMacroPlay

Keynote: Scala with Styleby Martin Odersky, creator of scala

What is OOP good for?Fixed APIs with unknown implementations. e.g.Simula67 for simulation, Smalltalk for GUIObjects are characterized by state, identity andbehavior - 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

expressionfind meaningful names for the intermediate results. It's

not easy but it's important

Guideline #3 Prefer Functional

vals v.s. varsrecursions or combinators v.s. loopsimmutable v.s. mutable collectionstransformations v.s. CRUD*

Guideline #4 But, don't diabolize local statesometimes, mutable gives better performancesometimes, mutable adds convenience

vars v.s. valsvar interfaces = parseClassHeader()...if (isAnnotation) interfaces += ClassFileAnnotation

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

loops v.s. combinatorsval totalPrice = items.map(_.price).sumval 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.0for (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 atthe same timeclean and elegant solutions don't come to mind at thefirst timeit 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 firstif it becomes too tedious, or efficiency is a big concern,try tail-recursionuse 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 parametersuse nested function for small functionsdon't nest too many levels

Choice #6 pattern matching v.s. dynamic

dispatchthe expression problem, check out

, lecture 4.5 and 4.6scala class @ coursera

Choice #7 type parameters v.s. abstract type

members

try type parameters firstavoid Animals[_]

a good article by Bill Venners

Keynote: Scala in 2018by Rod Johnson, creator of Spring

in 2018Java is still aliveEnterprise apps are using ScalaStartups are still NOT using Scala

myths / pointsReadability over cleverness, LOC, FP, ...Scala needs coding standardScala needs to move slowerEmbracing 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 firstplace. Therefore, if you write the code as cleverly aspossible, you are, by definition, not smart enough to

debug it. - Brian Kernighan

Asynchronous Programming

asynchronous v.s. parallelwhat 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. realitycost of thread context switch# of threads v.s. # of CPUswhere is the bottleneck?

Some thoughts about our system

Upgrade to scala 2.10

Use akkaasynchronous programmingfault tolerancemodular design

Use case class for data modeltreat data as map

Use finagle for service modulesplay is not for REST APIwhy pay the cost of HTTP?statisticsseparate REST and Data layermodularity

Questions?