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
