After trying to learn Scala by osmosis as I go through the exercises for the Coursera Principles of Reactive Programming course, I decided to have a quick look for good online tutorials. Fortunately I came across this book. Martin Odersky (the creator of the language) is one of the authors of the book and it is really good read. It really pushes the case for Scala being a truly scalable programming language. Reading this book cleared up a lot of the concepts that I’d been introduced to by example – companion classes for example and the use of implicits. The book also covers the idea of traits really well, and contains a number of fairly large examples which show some great features of the language. The book is a little old so doesn’t cover some of the more recent language features, but it is certainly a really good foundation.
While I was looking for example code in Scala, I came across MetaScala, a cutdown JVM implemented in Scala. Once the reactive programming course finishes, I’m going to have a close look at it. The Scala book discusses the flow based type inference that the language uses… this week I also came across this discussion of type flow (for optimisation purposes) in the SBCL Common Lisp implementation.
I’m also going to be attending CodeMesh in London this week, so I’ve started to select talks on the various tracks. One that looks good is the History of Lazy Functional Programming Languages by David Turner. Lots of the material will probably come from this recent paper. SASL holds a special place in my memory. It was the first lazy functional programming language that I came across, and the clever compilation scheme into SKI combinators was amazingly clever. I never got to use it and didn’t get to program in a lazy functional language until I came across Haskell – previously I had used the lazy LispKit Lisp but that didn’t have the algebraic data types of languages like Hope.
While we’re on the subject of lazy functional languages, this paper discusses some of the “space leak” issues that are often associated with laziness, though it points out that non-lazy languages can also have issues when closures are used. One interesting point made by the paper is that the garbage collector can be used to force the evaluation of cheap call-by-need thunks to avoid the leaks.
CodeMesh has a load of other interesting talks which I’ll write up when I get back.