Scala Presentation notes

These are notes for a talk I gave at work on scala (in about 2012!)

Scala - SCAlable LAnguage

scalable in terms of building libraries, expanding the language as well as runtime scalability

Scala is a static/strongly typed JVM language, that is a hybrid object oriented / functional language.
Could be a direct replacement for Java.

Java works and there are a LOT of Java programmers, so why change?
Just ask Paul Graham : beating the averages (although he is talking about LISP)

What's wrong with Java?

• a LOT of boiler plate code, many lines of code not adding any real information
• difficult to do multi-threaded apps. Pessemistic locking for the complex case, but it doesn't scale very well. JEE helps cover the simple case, but it's too heavyweight for many applications.
• a LOT of Java frameworks/libraries are hard to work with, due to backwards com lots of xml config instead of code or coding by convention
• no closures or first class functions
• not pure OO - primitives, operators, basics arrays, statics work completely separate from objects 
• It's not evolving fast enough - matter of opinion
• no multiple inheritence
• no built in aspect facility 
• no tuples or multiple return values, can't do pass by value either
• null checks - anything could be null
• cloning objects difficult 
• only external Domin Specific Languages practical (eg ant)

Dynamic Languages answer
Ruby/JRuby, Python/JPython, Groovy, JavaScript

• dynamic typing reduces boiler plate
• often pure OO
• tuples or multiple returns
• often have first class functions
• better meta programming to increase expressiveness
• often a limited form of multiple inheritence
• evolve reasonably quickly
• internal and external DomainSpecificLanguages

Problems of their own

• slow performance
• dynamic typing makes larger projects more difficult
• some unit testing required just to replace basic static type checking (in addition to actual unit tests)
• generally don't scale up well

Functional languages
Haskell, Lisp, Clojure,

• very concise syntax due to high level components
• immutable data makes threading easier
• easier to reason about program, as side effects are reduced
• extensive meta programming 
• function composition belies the need for multiple inheritence
• tuples
• bottom up programming the normal - ie internal DSL the norm

Even worse Problems

• very low mindshare - hard to find developers
• perceived difficult to learn
• minimal libraries (except Clojure which runs on the JVM)
• can be overly restrictive (eg no mutable data or no side effects)

Scala's answer to both

• same or similar performance to java
• strong and static typing
• concise syntax, looks like dynamic language
• Threads, Actors, Software Transactional Memory
• 3rd part libraries can be written to feel like language support (eg Actors)
• functional programming available
• internal/external DSLs normal
• Option instead of null
• still evolving

Choice is a recurring theme

• optional type annotations
• OO and functional
• threads/actors/stm
• mutable/immutable 
• referential transperancy / side effects

 Possible problems

• it's NOT called Java - even though much of it actually is Java
• static typing (debatable) - type inference helps
• Complex language - even though the source code can be simpler than java
• not true functional language, ie mutable data just as easy as immutable - only haskell people say this
• language still evolving - faster than Java but slower than C#
• Clojure - LISP syntax is a barrier for a lot of developers

Sucess Stories

Twitter - using ruby front and backend. ruby didn't scale to massive number of transactions. reimplement backend queueing system in scala. http://www.artima.com/scalazine/articles/twitter_on_scala.html 

...

Intro for Java Developers

• hybrid pure OO and functional language
• strong statically typed - (stronger than java)
• It IS Java underneath - Runs on the JVM
• It's basically Java on the surface too - start with Java and make a few tweaks, make things more general
• Imagine what Java would be like now, if it added new features and allowed breaking backwards compatibility like C#.NET does.
• Eclipse Netbeans and another popular IDE plugins available - not as good as java, but better than most non-java languages

Features/Positives

• can work with Java code directly with zero ceremony
• Java can talk to scala directly, but the class names will be weird although deterministic
• local type inference - minimal type annotations, Not as strong as haskell, though
• Java based syntax - easier to learn than other functional languages, feels like a dynamic java
• concise syntax - less lines of code, less code to write/read/maintain
• operator overloading - really just method overloading, but some methods look like operators
• fast runtime - comparable to java
• possible to extend the language with libraries that feel like native support
• Actors - erlang style concurrency, multiple implementations to choose from
• Lift - rails-like web framework
• singletons - via object keyword, no statics
• traits - interfaces, cross-cutting concerns/aspects, module composition, multiple inheritence
• duck typing - dynamic method calling that's type safe using structural typing
• consistant and simplified equals / == handling - including the null case
• XML literals and Xpath like queries
• regex literals
• case classes - automatically correct java beans
• immutable and mutable collections available
• .Net version - under development
• no checked exceptions - debatable
• extensive options for private access - either public (by default) or private (specify a scope)
• covariance/contravariance made more explicit

why scala 
Akka actors

running scala

• REPL - Read Eval Print Loop - lisp, python - even an online version
• script - perl, python, shell script
• compile/execute - java

http://www.scala-lang.org/node/166#Scriptit 

See hello world example

http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-1 

See Real world Comparison

Basics

• val immutable value - same as final
• var mutable variable - same as normal variable
• types taken directly from java - primitives are mapped to a real object type
• a lot of type annotations are optional, because of local type inference
• no operators, only methods on objects
• semi-colon optional, only used to separate statements on a single line 
• optional method invocation syntax, for single argument methods "obj.meth(args)" or "obj meth args"
• reverse order for type annotation - allows type to be optional
• methods/functions and values/fields are not as distinct. both are assigned, both can be assigned from a block or single statement

See Basics

Object oriented

• pure oo language - ie everything is an object or a method on an object - no primitives, no statics, no operators
• class - same as java class
• class instance - same as java object
• object - like a java class with only static members, but it's also a singleton object
• trait - like a java interface, but with implementation
• traits allow multiple inheritence - a solution to the diamond problem, using a right-first depth-first search
• traits allow aspect oriented functions - stackable traits
• case class - a special kind of class, that will autogenerate Java Bean methods, and can be used in pattern matching

See Bean
See Singleton
See Trait

functional

• first class functions
• function literals
• higher order functions
• currying
• immutable values
• immutable collection types
• lazy and strict evaluation
• pattern matching
• foreach
• for comprehensions
• map
• filter
• fold
• reduce
• almost everything is an expression. eg try catch block yields a value
• monads
• some Tail Call Optimisation

See functional
See Pattern Matching

http://anyall.org/scalacheat/ 

Control Structures

• if else - returns a value like ternary ? :
• for - more than for loop, returns value
• match - pattern matching, more than switch
• while, do while - only used for side effects, not encouraged
• try catch finally - uses pattern matching to catch, returns a value
• recursion - some TCO available
• no break or continue - while loops discouraged, better ways to achieve the same goals

proper scala way cannot have off-by-one errors, or any other boundary problems.
It's an implementation agnostic way to apply a function to each item in the list.
It doesn't use _any_ mutable state at all.

See JavaLoops
See Loops
See ForDemo

Xml

• Xml parsing using all java parsing libraries
• xml literals
• xpath like queries
• pattern matching on xml values

See XML

http://rosettacode.org/wiki/XML/XPath#Scala

Actors

• Taken from Erlang
• object as thread - or virtual thread
• method call as async message, 
• method result as async message response
• messages are immutable data 
• messages received via actor's mailbox 
• no shared mutable state - no locking - no race conditions - no dead locks
• problems need to be re-structured / re-stated to use actors 
• 1,000s Threads vs 1,000,000s of Actors   

three basic ways to send/receive messages. similar to BPEL

• asynchronous one way . two way can be emulated, but is actually just two separate async one ways
• synchronous - waits for message response
• futures - async two way. returns immediately from sending message (like async), but the response is a future object. When you attempt to use the future, it will then wait for the actual response.

There is a choice between actors that use a thread each, or actors that will share a thread pool.


See Actors

http://www.slideshare.net/jboner/pragmatic-real-world-scala-45-min-presentation 


Logger example
each type of message must be a case class.
Exit message type used to tell actor to finish
async messages are processed asynchronously, but message ordering is preserved.
object singleton ensures only a single message queue.
async processing means that logging a message doesn't cause main program execution to block