Scala for the Impatient

My next writing project is "Scala for the Impatient". Why yet another book? I became impatient with the books and blogs that seemed to be directed towards language enthusiasts, not programmers who need to get a job done. Watch out for the first drafts on Safari in a few weeks!

In 1995, I got a call from Gary Cornell who told me that we were going to write a Java book. That surprised me—I didn't know any Java, and I was pretty sure that Gary didn't know it either. But Gary knew that Java would be big. So we set out to write, as fast as we could, the first Java book that showed how to write real code. (There already were a couple of books out, such as the regrettable “Teach yourself Java in 21 days”, but they focused on giving the illusion of knowledge.) Core Java appeared a few weeks after the Java 1.0 release, and it was an instant best-seller. A 9th edition will be out later this year, covering Java 7.

When I first heard about Scala, nobody told me that it was going to be big, so I didn't write a book. Of course, other people did. I got a few, but I found that I never read any of them. I just wrote code and read blogs whenever I got stuck. And I spent way too much time on

What was wrong with the books? For me, two things. First, I didn't care to be told that I had sinned and must repent, and embrace the functional style in all its goodness, and only then could I hope to lead a useful life. More importantly, I was just too impatient. I know what a loop and a class and a function is. I don't want to read that stuff again.

So, why not just stick with the blogs? There are several good blogs that try to get a Java programmer up to speed with Scala, and I learned a lot from them. But there is something to be said about a well-researched book. In a blog, the author gets away with omissions, half-truths and outright errors. In a book, one expects correct and complete information, and a thoughtfully prepared learning path.

What I need is the analog of TEX for the Impatient, an admirable book by Paul Abrahams that courageously positioned itself to those “for whom TEX is a useful tool rather than a primary interest” . That describes how I feel about Scala.

The trouble is, nobody wrote such a book, and it looks like I'll just have to write it myself. I drafted a proposal in which I placed the various topics into five layers:

  1. Basic Scala
  2. Intermediate Functional Programming
  3. Intermediate OO Programming
  4. Advanced Scala
  5. Esoteric Scala

You can do a lot of useful work just with the first level, which you can pick up quite quickly. After the second level, you should be able to use a typical Scala library effectively (such as the Scala ccollections).

I was delighted to see a discussion on four Scala language levels that was pretty similar to my thinking. Moreover, after Martin Odersky enumerated his four levels of Scala wisdom, an irate Tony Morris complained that there is a fifth level that is way higher (which presumably he has attained). So maybe I am on to something with the advanced/esoteric distinction :-)

I sent out a couple of sample chapters for review, and the reviewer complained that a fair amount of the material was strange and out of place. I looked at the offending sections. They were about file processing, Java interop issues, regex pitfalls, and similar stuff. All practical, hands-on topics for getting a job done. I guess for the reviewer, Scala was a primary interest rather than a useful tool. Hmmm--now I really think I am on to something.

As I started writing, I was surprised how difficult it is to organize material for the impatient. Consider the task of writing a class. Ignoring constructors for now, let's say I start with

class Person {
  ??? name: String

Of course, all the books tell me the difference between val and var. Here I want to be able to change the name, so I choose var. How do I decide whether to use a plain var, private var, private[Person] var or private[this] var? I tried looking at several of books, but I wasn't patient enough to find the answer, or even a clear explanation of the differences. This book, for example, states that private var means that no getters/setters are generated, which can be quickly refuted by running javap -private. This seems such a basic question, and I can tell from the blogs and mailing lists that people are confused about it. I want to give clear, truthful, and easy-to-find guidance.

Scala Field Generated Methods When to Use
val name public name To implement a property that is publicly accessible and backed by a field.
var name public name, name_=
@BeanProperty val name public name, getName() To interoperate with Java beans.
@BeanProperty var name public name, getName(), name_=, setName(...)
private val/var name private name, name_= To confine the field to the methods of a class, just like in Java. Use this (without the [Classname] qualifier) if you don't want a public property.
private[Person] val/var name Implementation-specific
private[this] val/var name None To confine the field to methods invoked on the same object. Not generally useful.

In a few weeks, first chapter drafts will be available on Safari, and I'll also post some blogs . If there anything that you are impatient to see discussed in a Scala book, please comment!