Beginning Scala is a fairly recently published introductory Scala book (2009). It has made learning about coding and design with Scala thus far a pleasure. While I’ve been aware of Scala for a few months now (when I started web programming), I’ve been very busy with high priority task juggling and hadn’t made time to experience the language (or read the book). My first memory of Scala is hearing about how twitter switched over much of their Ruby on Rails to a Scala framework to improve performance. Since then I’ve sampled 14 million other web technologies .

why I’m loving the book

After the intro and background (who developed scala: Martin Odersky and why: Java needed a successor – ty sisyphus) Dave shows us sample code which is exactly how I prefer to learn something. When I want to learn about a topic, I prefer to dive in head first. I want to experience it for myself, to really understand it, and make it my own. I like to cut to the chase, and then back track to fill in the knowledge gaps fueled by the curiosity that naturally arises by going through something interesting the first time. If it’s not interesting, I can drop it with minimal time lost. This is precisely how I feel about Scala, and Dave Pollack gets it. Even in his first real sample program we get a line by line description of some syntax covering a nice range of functionality and syntax. Here’s an excerpt from the book (from chapter 2).

Listing 2-1. Sum.scala

Let’s go through this file in detail.

Importing Stuff

The import scala.io._ code imports all the classes from the scala.io package. This is the same as Java’s import scala.io.*;. Scala uses the _ rather than the * as a wildcard. Coming from Javaland, it takes a little getting used to, but it’ll soon make sense.

Parsing a String to an Int

Next, we define the toInt method, which takes a single parameter called in. That parameter has the type String:

def toInt(in: String): Option[Int] =

In Scala, method definitions begin with the def keyword. The method name follows, along with the method’s parameter list. In this case, the toInt method takes one parameter: in, whose type declaration follows it rather than precedes it. In some cases, the Scala compiler can figure out or infer the type of a variable or the return type of a method. You need to declare the parameter types for a Scala method, but we may omit the return type if the return type can be inferred and the method is not recursive.2 We declare the return type as Option[Int]. In general, if the return type is not immediately obvious, it’s an act of kindness and good citizenship to your fellow programmers and your future self to declare the return type.

What’s Option and what are those funky square brackets around Int? Option is a container that holds one or zero things. If it holds zero elements, it’s None, which is a singleton, which means that only one instance of None. If the Option holds one element, it’s Some(theElement). The funky square brackets denote the type of thing that’s held by the Option. In this case, the Option holds an Int. In Scala, everything is an instance of a class, even Int, Char, Boolean, and the other JVM primitive types. The Scala compiler puts primitive types in instance boxes (boxing) only when necessary. The result is that you can treat all classes uniformly in Scala, but if your primitive data does not require boxing, you’ll see the same program performance you see using primitives in Java. If your primitive does require boxing, the Scala compiler does all the boxing and unboxing for you, and it even does null testing when it unboxes—nice and polite.

So, Option[Int] is a container that holds zero or one Int value. Using Option is one of the ways that Scala lets you avoid null pointer exceptions and explicit null testing. How? You can apply your business logic over all the elements in the Option. If the Option is None, then you apply your logic over zero elements. If the Option is Some, then you apply your business logic over one element. Option can be used and nested in the for comprehension. We’ll explore Option in more depth in Chapter 3.

When I’m writing code, I return Option from any method that, based on business logic, might return some value or might return none. In this case, converting a String to an Int might succeed if the String can be parsed or might fail if the String cannot be parsed into an Int. If the String cannot be parsed, it is not something that’s worthy of an exception because it’s not an exceptional situation. It is merely a calculation that has no legal value, thus it makes sense to return None if the String cannot be parsed. This mechanism also avoids the Java patchwork of sometimes returning null when there’s no legal value to return and sometimes throwing an exception.

Speaking of exceptions, that’s exactly what Integer.parseInt does when it cannot parse the String into an Int. So, in our code, we wrap a try/catch around

Some(Integer.parseInt(in.trim)).

If the Integer.parseInt method succeeds, a new instance of Some will be created and returned from the toInt method. There’s no explicit return statement as the last expression evaluated in the method is its return value.

2. A recursive method is a method that calls itself.

3. Option[Int] is a “variant type” or “sum type” with None as one variant and Some[Int] as the other.

Neither None nor Some[Int] is the same as Int, but if you’re working with an Option[Int] that happens to be of the variant Some[Int] then you can extract the actual Int from it by calling the get method. If Integer.parseInt throws an exception, it will be caught by the catch block. The catch block looks different from Java’s catch. In Scala, there’s a single catch and a series of patterns to match the exception. Pattern matching is a language-level Scala construct, and it’s uniformly applied across the language. In this code, we have

case e: NumberFormatException => None

This pattern matches the exception to NumberFormatException and returns the expression None, which is the last expression in the method. Thus toInt will return None if parseInt throws a NumberFormatException. To summarize: toInt takes a String and attempts to convert it to an Int. If it succeeds, toInt returns Some(convertedValue), otherwise it returns None.

Summing Things Up

Next, let’s tackle the sum method. We define our method:

def sum(in: Seq[String]) = {

We don’t declare the return type for sum because the compiler can figure it out and the method is short enough that a quick glance at the code shows us that the return type is an Int. The in parameter is a Seq[String]. A Seq is a trait (which is like a Java interface) that is inherited by many different collections classes. A Seq is a supertrait to Array, List, and other sequential collections. As Option[Int] is an Option of Int, Seq[String] is a sequence of String elements.

A trait has all the features of the Java interface construct. But traits can have implemented methods on them. If you are familiar with Ruby, traits are similar to Ruby’s mixins. You can mix many traits into a single class. Traits cannot take constructor parameters, but other than that they behave like classes. This gives you the ability to have something that approaches multiple inheritance without the diamond problem (http://en.wikipedia.org/wiki/ Diamond_problem). The first line of the sum method transforms the Seq[String] to Seq[Int] and assigns the result to a val named ints:

val ints = in.flatMap(s => toInt(s))

This maps and flattens each element by calling the toInt method for each String in the sequence. toInt returns a collection of zero or one Int. flatMap flattens the result such that each element of the collection, the Option, is appended to the resulting sequence. The result is that each String from the Seq[String] that can be converted to an Int is put in the ints collection.

In Scala, you can declare variables as assign-once or assign-many. Assign-once Scala variables are the same as Java’s final variables. They are identified with the val keyword. Assign-multiple variables in Scala are the same as Java variables and are identified with the var keyword. Because I’m not changing the value of ints after I set it, I chose the val keyword. I use val in my programs unless there’s a compelling reason to use var, because the fewer things that can change, the fewer defects that can creep into my code.

Another fancy thing that we’ve done is create a function that calls the toInt method and passes it to the flatMap method. flatMap calls the function for each member of the sequence, in. In our example, we defined a function that takes a single parameter, s, and calls toInt with that parameter. We pass this function as the parameter to flatMap, and the compiler infers that s is a String. Thus, an anonymous function is created, and an instance of that function is passed to the flatMap method. Additionally, Scala sees that the return type of toInt is an Option[Int], so it infers that the ints variable has the type Seq[Int]. So, you’ve done your first bit of functional programming. Woo-hoo! The next line sums up the Seq[Int]:

ints.foldLeft(0)((a, b) => a + b)

foldLeft takes a seed value, 0 in this case, and applies the function to the seed and the first element of the sequence, ints. It takes the result and applies the function to the result and the next value in the sequence repeatedly until there are no more elements in the sequence. foldLeft then returns the resulting accumulated value. foldLeft is useful for calculating any accumulated value. In math, sum, prod, min, max, and so on can be implemented easily with foldLeft. In this case, we defined a simple function that takes two parameters, a and b, and returns the sum of those parameters. We did not have to declare the types of a or b, because the Scala compiler infers that they are both Ints. The foldLeft line is the last expression in the method, and the sum method returns its results.

Program Body

The following defines the input variable:

val input = Source.fromInputStream(System.in)

Its type is Source, a source of input, which wraps the JVM’s System.in InputStream. In this case, we didn’t have to do anything fancy to access a Java class. We used it just as we might have from a Java program. This illustrates the awesome interoperability between Scala and Java.

The next line gets the lines from our source and collects them into a Seq[String]:

val lines = input.getLines.collect

Finally, we print a message on the console with the sum of the lines with parsible integers on them:

println(“Sum “+sum(lines))

To run the program, type

> scala Sum.scala

When you’re prompted, enter some lines with numbers. When you’re done, press Ctrl-D (Unix/Linux/Mac OS X) or Ctrl-C (Windows), and the program will display the sum of the numbers.

Great, you’ve written a Scala program that makes use of many of Scala’s features including function passing, immutable data structures, and type inference. Now, let’s look more deeply into Scala’s syntax.

what’s special about scala

It’s a software language designed to match object oriented and functional paradigms. We are guided to think (and code) differently when writing libraries versus generating specific applications. Martin Odersky describes the design goals of the language best in this interview on scalazine, the Goals of Scala:

Martin Odersky: The first thing we cared about was to have as clean an integration of functional and object-oriented programming as possible. We wanted to have first-class functions in there, function literals, closures. We also wanted to have the other attributes of functional programming, such as types, generics, pattern matching. And we wanted to integrate the functional and object-oriented parts in a cleaner way than what we were able to achieve before with the Pizza language. That was something we deeply cared about from the start.

Later on, we discovered that this was actually very easy, because functional languages have a fixed set of features. They had been well researched and well proven, so the question was only how to best integrate that in object-oriented programming. In Pizza we did a clunkier attempt, and in Scala I think we achieved a much smoother integration between the two. But then we found out that on the object-oriented side there remained lots of things to be developed. Object-oriented programming, at least when you throw in a static type system, was very much terra incognita. There was some work we could look at and use, but almost all languages that we found had made a lot of compromises.

So as we developed Scala, we started to discover how we could mix objects together with traits and mixin composition, how we could abstract the self types, how we could use abstract type members, and how we could let this all play together. Up to then there had been a couple of research languages that addressed a few of these aspects in specialized ways, but there wasn’t much in terms of mainstream languages that covered the whole spectrum of making it all work. In the end it turned out that the main innovations in Scala were on the object-oriented side, and that’s also something we really cared about.

what’s special about Dave Pollack

He’s an active developer that’s designed and built lift with the help of a great open source group. This is a full featured web framework built with scala but focused on developing web applications fast and effectively. Here’s Dave’s personal blog. From the liftweb site:

Lift is an expressive and elegant framework for writing web applications. Lift stresses the importance of security, maintainability, scalability and performance, while allowing for high levels of developer productivity. Lift open source software licensed under an Apache 2.0 license.

I first discovered Dave passionately describing why he preferred Scala’s static typing to his development time with Ruby on Rails (and heavy type testing cost) on Lambda the Ultimate. You’ll get a good feel for Dave’s thinking, and some incredible cross evaluation and discussion from other group members.

Related articles by Zemanta

• Scala, a Statically Typed, Functional, O-O Language (tech.slashdot.org)

Hugh Macleod gathered his manifesto How to be Creative, and weaved together his creative insights on how best to develop our genuine creativity in Ignore Everybody.

The history unfolds with Mr. Macleod’s background as a young advertiser. One of his observations that slightly frustrated me was the “watercoolies” a nickname he and his former coworker John gave to the older folks that were getting squeezed by the industry. The water cooler folks were burnt out by the advertising system, and were identified by complaints about everything under the sun. I was a little miffed by Hugh’s thoughts of his friend John joining the ranks of the watercoolies. Why can’t we find value in what other folks share? After all, they have been through the wringer and between complaints there are moments of miraculous appreciation and truth. Yeah they may not be wildly successful or rich, but you can’t take it with you anyway. Your mindset and outlook is what defines your “life wealth” in my book. A penniless guy or gal who appreciates all their life has provided them, is far wealthier than one who is filthy rich, but is paranoid and angry at every penny lost.

Hugh let’s us know that Ignore Everybody isn’t an absolute statement:

When I say, “Ignore Everybody,” I don’t mean, Ignore all people, at all times, forever. No, other people’s feedback plays a very important role. Of course it does. It’s more like, the better the idea, the more “out there” it initially will seem to other people, even people you like and respect. So there’ll be a time in the beginning when you have to press on, alone, without one tenth the support you probably need.

For my own path, I greedily soak in every comment, reply and morsel of feedback. Witnessing the social dynamic changes of Internet publishing, old corporate structures failing, all firsthand is like a personal gift from time and space. To be alive at this time, in this place, allows us all to observe a transformation of value creation the world has never before seen. Perceived value is just now becoming recognized as an ultra personalized measure for each person. Groups and communities are nearly self organizing from diverse slices of society.

1. social media shares for real connections (information filtering, conversations, observations)
2. open source repositories for hackers/coders/developers
3. crowd funded social programs to kick start entrepreneurs in low income areas

the Dip

Seth Godin concentrates his marketing insight towards knowing when to quit and when to stick with something in the Dip. It’s a rebellious but very quick jaunt (80pages, thanks for focusing it down Seth) through some simple curves that match much of our life’s activities. The Dip is characterized by a process that initially starts out wonderful entertaining, then becomes a chore, terrifically challenging, but eventually pays off when we attain mastery of a field.  For Seth, super focusing meant quitting everything that wasn’t a Dip like function (he calls the flat line reward functions  Cul-de-sacs, and dead ends are Cliffs). Cul-de-sacs are local optimals, which we psychologically cling onto, but coast along within. Without challenging ourselves or those around us we degrade and cease to improve our skills and knowledge. There is no end game mastery where we can reap great rewards, and provide superb value to society at large. The final curve Seth maps to life are Cliffs. These type of self feeding habits make it nearly impossible to quit, until something drastic happens and the entire system collapses. Cigarettes, and other addictive substances fall into this category, but as fortune would have it most of life’s challenges are either Dips or Cul de sacs.

For someone who has diversified interests in many different areas, I felt some conflict with Seth’s proposal. I have a great fondness for sharing and know that blogging will be party of my daily activities for as long as I’m able. But there are so many fascinating things I can be apart of that are outside of blogging, which in fact fuel my desire and value of my writing. Novel Internet software design solutions and entrepreneurship are key areas of concern for me. The building of value in our society, and those who risk everything to make abstract concepts concrete are of profound importance to my curiosity. Serendipity find’s those who are open to it’s marvels by connecting disparate data (observations). The ultra focused masters of their domains may miss out on the splendor of a balance between our passions, and our other needs/hobbies.

Seth leaves us with a statement near the end of the Dip which encourages and challenges us:

You’re Astonishing

How dare you waste it.

You and your organization have the power to change everything. To create remarkable products and services. To over deliver. To be the best in the world.

How dare you squander that resource by spreading it too thin.

How dare you settle for mediocre just because you’re busy coping with too many things on your agenda, racing against the clock to get it all done.

The lesson is simple: If you’ve got as much as you’ve got, use it. Use it to become the best in the world, to change the game, to set the agenda for everyone else. You can only do that by marshaling all of your resources to get through the biggest possible Dip. In order to get through that Dip, you’ll need to quit everything else. If it’s not going to put a dent in the world, quit. Right now. Quit and use that void to find the energy to assault the Dip that matters.

Go ahead , make something happen. We’re waiting!

Ok Seth, I get the message. I can cut back on my World of Warcraft hours to spend a few more hours a week working towards creating something of real long term value.

Related articles by Zemanta

• A Purple Cow joins forces with a Gaping Void, only greatness results (victusspiritus.com)
• Hugh MacLeod, The Gaping Void (gothamgal.com)
• Heresy in the church of the latent entrepreneur (stephendann.com)

I’m two chapters in and loving it so far.  Thanks to Jonathan for taking the time and effort to organize his thoughts and develop a cogent and effective strategy to Reclaim our Dreams.

Here are selected high points during my reading experience:

Jonathan engages the readers with
a series of questions to get them thinking about their own paths from the very
beginning.  It quickly becomes evident this is not a guided tour but simply a tool kit to aid oneself in their own quest for rediscovering their true calling.

He muses “Why do you live?” … Jonathan reached
an answer for himself: “The point of living is to enjoy life”, and finds it to be a commonality among those he has personally observed.  Each of our lives has central themes which we can learn from and find nourishment.

Then he proceeds to ask common concerns we share:

“We have questions such as these:

• What happens if doing what I love
  isn’t practical?

• What happens if I can’t make any
  money with my passion?

• What happens if I’m not good at
  following my heart?

• I don’t seem to have time for the
  things I love. How do I make time?”

By bringing light to these barriers to self development he forces us to to see that they are merely perceived obstacles and excuses not to follow our inner nature.

In chapter 1, “unbrainwashing or creating room
for your dreams to grow” I was reminiscent of the Jedi training words of
Yoda, “you must unlearn what you have learned”.  Jonathan warns that many of us become a prisoner of our own ingrained thought processes.  “Instead of owning your thoughts,
your thoughts own you. You start to identify with your thoughts, and
pretty soon the conflict in your mind is too much. It’s always
judging, always brooding about something.”  This causes us harm because we are comparing our current state of being with one that is unachievable or impossible.  “Constantly comparing yourself
against an image of perfection causes you to search for something
you’ll never have and strive to become someone you’ll never be. It
doesn’t exist”.  I believe what he is describing is a differentiation from our creativity and analytical minds, which is based on holding possible choices in opposition (juxtaposition), and our true selves.

For chapter 2 we are coached to “Stop Caring”.  I was particularly impressed with the warning signs of “toxic caring”:

“Some Symptoms of toxic caring
include:

• We value productivity and
  accomplishments more than what makes us come alive

• We give more merit to the bullet
  points on our resumes than the contents of our character

• We care more about the size of our
  bank accounts than the fulfillment of our passions

• Efficiency and getting things done
  becomes more important than how much we enjoy what we’re doing”

Once again I humbly thank Jonathan Mead for taking the time and energy to orchestrate his powerful message and giving each of us a chance to “Reclaim Your Dreams”.