On Ruby

Here's the third of three Scala book interviews. Venkat Subramaniam (@venkat_s), author of the Prag's Programming Scala, has a lot to say about Scala and why you should be learning and using it.

You can find more posts about Scala (and Haskell and Erlang) on my Functional Programming page.

---

Functional Programming languages seem to be an increasingly popular topic. Why? What do FP languages teach or do for us?

Venkat Functional Programming has been around for a long time. Programmers are taking the time over the past few decades to rediscover it.

A few decades ago low level languages like Assembly and C were popular. As OOP and C++ because prominent, it became increasingly clear that memory management is quite unmanageable. We raised the bar, let the platform deal with memory management and garbage collection. We figured that by relying on a higher level of abstraction we can focus our effort, for better, on application development rather than memory management. This, among other things, brought languages like Java and C# to prominence. When programming in these languages, we don't have to worry any more about memory management.

As we moved on to create highly responsive applications, we began to realize that dealing with threading and concurrency is another real pain. As soon as you learn how to create a thread, the next thing you learn is how to limit and control it. Multithreaded applications are plagued with issues related to contention, deadlocks, correctness, and complexity of the low level APIs. The gaining availability of multi core processors and multiprocessors is only exasperating these concern. We're eager to put an end to the concurrency issues like we took care of memory management. This is where functional programming comes in.

Functional Programming advocates assignment-less programming and higher order functions with no side effect. By higher order functions, we mean functions that accept functions as parameters. You pass functions, return functions, and nest functions. Furthermore, these functions solely rely on the input you send them. They're not influenced by any external shared state, and, in turn, do not affect any external shared state. They promote immutability. This eliminates the concern of contention and the need for synchronization. It makes it easier to understand and verify behavior of such functions. However, threads still need to communicate and exchange information. Functional Programming languages like Scala provide an actor based message passing model to realize this.

What makes Scala the right FP language for people to pick up?

Venkat Scala is a relatively new language. Other prominent FP languages have come before it. However, quite a few things make Scala special and attractive. It is by far the most powerful statically typed, highly expressive, yet concise language that runs on the Java Virtual Machine (JVM). Scala is fully object oriented, intermixes with Java seamlessly, and provides very strong static typing but without the ceremony that Java adds. Though Scala is entirely a new language, for a moment entertain the thought that Scala is a refactored version of Java, stripped out of its ceremony and threading API, then enhanced with sensible type inference and actor based concurrency model. If Java were to be redesigned in 21st century, it may look a lot like Scala. So, if you are programming on the JVM, and are interested in taking advantage of functional programming capabilities, Scala is a great choice.

Why is the JVM a good platform for Scala and FP?

Venkat Or should we pose the question the other way around, asking why is Scala and FP a good choice on the JVM? I think these two questions go hand in hand.

The real strength of Java is not the language but the platform, the JVM. There are three things going for it. First, the capability of the virtual machine itself is superb in terms of performance and scalability. It did not start out that way, however, we've seen tremendous improvements over the past few years. Second, a rich set of libraries and frameworks are available for various tasks that enterprise applications demand. Name it, and there is something available already for you (the concern often in this space is availability of too many options, not too little!). Third, influenced by the two above factors, a significant number of enterprise applications already run on the JVM platform.

Some developers have the luxury of starting out on green field projects and do not have to integrate with other existing applications and components. They have the ability to choose any language and style they desire.

However, a large number of developers don't have that choice. They develop applications that run and integrate with things on the JVM. Emigrating to another language or another platform to enjoy the benefits of functional programming is really not an option for them. Scala provides a tremendous opportunity here. They can stay right on the powerful platform they're on, continue to developer and maintain their existing Java applications, and at the same time take advantage of functional programming and other related benefits that Scala bring to the platform.

Since Scala code compiles down to bytecode and integrates seamlessly with Java, you can take advantage of Scala to the extent you desire and makes sense of the project. You can have a small part of your application written in Scala and the rest of the application in Java. As you get comfortable and make the paradigm shift, more and more code and even entire applications can be in Scala. At this point, you can continue to integrate and utilize other components and services running on the JVM. So, the JVM is not simply a good platform. It is a compelling platform to utilize and benefit from functional style of programming.

What kinds of problems are a good fit for Scala?

Scala's strengths are strong sensible typing, conciseness, pattern matching, and functional style. The first three strengths can help with your traditional programming needs. It will take you less code to achieve your day to day tasks like working with XML, parsing data, manipulating collections of data, ... Scala can help you do the heavy weight lifting with lesser effort. The last strength I mentioned along with the actor based model will help you develop highly concurrent applications without the pain and perils of thread synchronization. On one hand, your concurrent application will be smaller in size. On the other hand, it is devoid of the uncertainty of program correctness due to state contention and deadlocking.

Design patterns and algorithms look differently when implemented in different languages. Can you give us some examples of elegant patterns or algorithms in Scala?

The language idioms have a great influence on the design. There are a number of patterns that are easier to implement in Java compared to C++. Similarly, languages that support closures and provide conciseness make lots of things easier and elegant.

Let's explore one example.

You are asked to total values in a range from 1 to a given number. You can write a simple loop to do this. Now, you are asked to total only select values, say only even numbers. You could duplicate the code that totals and put a condition statement in it. Now, you are asked to support different criteria, select even number, or select odd numbers, or prime numbers, etc. Spend a few minutes thinking about how you can achieve this in Java.

I can think of two ways to implement this in Java.

Approach 1:

Create an abstract class with an abstract method that will evaluate the selection of a value. Use this abstract method in determining the total. This follows the factory method pattern. Here is the code

// Java code
public abstract class TotalHelper {
 abstract public boolean isOKToUse(int number);
 public int totalSelectValuesInRange(int upperLimit) {
 int sum = 0;
 for(int i = 1; i <= upperLimit; i++) { if (isOKToUse(i)) sum += i; } return sum; } } 

Now to use this method, you will have to extend the class and override the isOKToUse() method. Each time you need a different criteria, you have to write yet another class. Quite a bit of work.

Approach 2:

Create an interface with the isOKToUse() method and call that method from within the totalSelectValuesInRange() method as shown below:

//Java code
public interface OKToUse {
 public boolean isOKToUse(int number);
}
//Java code
public class TotalHelper {
 public int totalSelectValuesInRange(int upperLimit, OKToUse okToUse) {
 int sum = 0;
 for(int i = 1; i <= upperLimit; i++) { if (okToUse.isOKToUse(i)) sum += i; } return sum; } } 

In this case you don't have to create a separate class to derive from TotalHelper, however, you do have to create (inner) classes that implement the OKToUse interface. Here you are using the strategy pattern to solve the problem.

While both of the above approaches will work, it is a lot of work to implement either approach. You can use IDEs to help generate quite a bit of that code, but that is still a lot of code that you have to look at and maintain.

Let's see how you can solve the above problem in Scala. We will follow along the lines of the second approach above, but without the interface. Since you can pass functions to functions, the code will be a lot simpler to write. At the same time, since Scala is statically typed, you have compile time type checking to ensure you are dealing with the right types in your code. Let's take a look:

def totalSelectValuesInRange(upperLimit: Int, isOKToUse: Int => Boolean) = {
 val range = 1 to upperLimit
 (0 /: range) { (sum, number) =>
 sum + (if (isOKToUse(number)) number else 0) }
}

The totalSelectValuesInRange() function takes two parameters. The first one is the upper limit for the range you want to work with. The second parameter is a function which accepts an Int and returns a Boolean. Within the totalSelectValuesInRange() function, you create a range and for each element in the range, you include the element in the sum if it passes the criteria evaluated by the function given in the parameter.

Here are two examples of using the above code:

Console println "Total of even numbers from 1 to 10 is " +
 totalSelectValuesInRange(10, _ % 2 == 0)
Console println "Total of odd numbers from 1 to 10 is " +
 totalSelectValuesInRange(10, _ % 2 == 1)

The output from the above code is shown below:

>scala totalExample.scala
Total of even numbers from 1 to 10 is 30
Total of odd numbers from 1 to 10 is 25

When looking at the above example, don't focus on the syntax. Instead focus on the semantics. You can't program any language without understanding the syntax. At the same time, once you get a grasp of the syntax, you navigate at the speed possible. This is when the language conciseness will help. There are quite a few interesting things to observe from the above example.

1. The code is very concise.
2. You did not spend time creating interfaces. Instead you passed functions around.
3. You did not specify the type repeatedly. When you called the totalSelectValuesInRange, Scala verified that the operation you perform on the parameter to the function (represented by the underscore) is valid operation on an int. For example, if you wrote
   

   
   totalSelectValuesInRange(10, _.length()> 0)
   

   
   Scala will give you a compile time error as shown below:

   >scala totalExample.scala
   (fragment of totalExample.scala):15: error: value length is not a member of Int
    totalSelectValuesInRange(10, _.length() > 0)
    ^
   one error found
   !!!
   discarding <script preamble>
   

   
   Notice how it recognized that the parameter represented by _ is an Int.
4. You did not perform a single assignment (val represents immutable data, you can't change or assign to it once you create it). In the Java example you initialized sum to 0 and then continued to update it. In the Scala example, however, you did not assign a value to any variable at all. This last feature comes in very handy when dealing with concurrency.

Imagine for a minute that the numbers you like to total are your asset values in stock investment. You can write a little code that concurrently fetches the stock prices from the web and determine the total value you have invested in it. You can then total these values without any issues of concurrency. And you'd be surprised, you can do that in about two dozen lines of code in Scala, as shown below.

import scala.actors._
import Actor._
val symbols = Map("AAPL" -> 200, "GOOG" -> 500, "IBM" -> 300)
val receiver = self
symbols.foreach { stock =>
 val (symbol, units) = stock
 actor { receiver ! getTotalValue(symbol, units) }
}
Console println "Total worth of your investment as of today is " + totalWorth()
def getTotalValue(symbol : String, units : Int) = {
 val url = "http://ichart.finance.yahoo.com/table.csv?s=" + symbol +
 "&a=00&b=01&c=" + (new java.util.Date()).getYear()
 val data = io.Source.fromURL(url).mkString
 units * data.split("\n")(1).split(",")(4).toDouble
}
def totalWorth() = {
 val range = 1 to symbols.size
 (0.0 /: range) { (sum, index) => sum + receiveWithin(10000) { case price : Double => price } }
}

The actor helped you to dispatch separate concurrent calls to the yahoo web service to fetch the price for the symbols you hold. You multiplied the response you got with the number of units to determine the total value. Finally you messaged that back to the calling actor. In the totalWorth() method you received the response from those calls using the receiveWithin() method and added them up.

Click here to Tweet this article

There are several good looking Scala books on their way to market. I'd like to help you get an early look at the books and their authors, so I'm working on a series of Scala author interviews for the FP side of On Ruby. Here's the second of several interviews.

Programming Scala authors Dean Wampler (@deanwampler) and Alex Payne (@al3x) have been good enough to answer several questions for me in this interview.

---

Functional Programming languages seem to be an increasingly popular topic. Why? What do FP languages teach or do for us?

Alex FP forces you to think differently about solving problems in code, and in a highly structured way. If object-oriented and procedural languages offer a more linguistic approach to programming, functional programming suggests a more mathematical approach. Once you wrap your head around the functional approach to handling collections of data, you'll never think about programming quite the same way. That's the reason that MapReduce, a combination of two fairly simple functional programming concepts, is so essential to what Google does. FP is rich in these powerful abstractions.

Dean It seems that every "paradigm" that goes mainstream lurks in the background until some "killer app" comes along for which the paradigm seems tailor made. GUI's did that for OOP. Now, it seems that growing concerns about pervasive concurrency, sometimes called the "multi-core problem", are driving interest in functional programming.

FP is a promising approach for concurrent programming because in pure FP, variables are immutable and functions have no side effects. If you have immutable variables, no synchronization is required for shared access. All the hard, error-prone programming problems in multithreaded code involve synchronizing access to shared, mutable state. If you get rid of mutable state, those problems just go away.

Another hallmark of FP is that functions are side-effect free — they don't change any global or object state. Such functions are inherently simpler to reason about, test, invoke concurrently, you name it.

Even if you don't care about concurrency (rare, these days), immutable state and side-effect free functions improve code quality, in general. For example, if I have an immutable object "graph", I don't have to worry about passing it to a client that wants to read it. If it's mutable, I have to worry that the client will screw it up in some way. I'd rather screw it up myself, thank you very much!

What makes Scala the right FP language for people to pick up?

Dean When I decided to learn an FP language, I picked Scala for very practical reasons; it seemed to be a very good candidate for widespread adoption. Because it runs on the JVM and because Scala code interoperates with Java code so seamlessly, I felt that a lot of Java developers would eventually migrate to Scala, first as a "better Java" and then later as a hybrid object-functional language, all without losing their existing investment in Java technology.

Alex It's worth clarifying that Scala is a hybrid Object-Oriented/Functional language. It's the best of both worlds: the power of FP with the familiarity of OOP. That familiarity makes Scala is a great first step into FP for programmers who haven't yet tried a functional language. For those who have, the practicality of doing domain modeling with OOP and interfacing with other JVM languages makes Scala a compelling alternative to strictly functional languages like Haskell and Lisp. All languages seem to gravitate towards an object model over time; see the Common Lisp Object System and the myriad efforts to turn JavaScript's prototyping into more traditional OOP. Why not pick a functional language that already has a mature object model baked in?

Why is the JVM a good platform for Scala and FP?

Alex The JVM is a great platform for any language for two reasons: maturity and community. It's widely acknowledged that the JVM isn't just the most mature VMs out there, it's simply one of the most mature of pieces of software out there, on par with the Linux kernel in terms of its history and extensive deployment. The JVM can be tuned, instrumented, profiled, and debugged using a variety of seasoned tools on a multitude of platforms. What's more, there's over a decade's worth of libraries for most any programming task available for the JVM, readily accessible from Scala with essentially no performance penalty. The Java community has already been through the process of producing code to tackle big-time, big-money problems, and that's value you can put to work immediately with Scala.

Scala's author had a hand in more than one functional programming language for the JVM before embarking on Scala. Coincidentally, he's also responsible for many of the performance gains the JVM has made over the years. Other big FP brains like Clojure's author have found the JVM to be a great host for functional languages. It still has a way to go before it's friendlier to dynamic languages, but the JVM's support for strong typing is a good fit for the FP paradigm.

Dean The JVM is arguably the most powerful VM in the world. The global, runtime optimizations it performs are quite extraordinary, doing things a compiler can never do, since it has to rely on static analysis of the code. Of course, the Java ecosystem is also rich with libraries and tools for almost every possible need. Hence, the JVM is great platform to build upon.

That's not to say that the JVM is perfect. It has a number of limitations that make FP harder, like functions are not "first-class" citizens (usable as values, arguments to other functions, and able to stand alone, without being a member of a type). Also, the JVM doesn't do tail-call optimization, which is very useful for recursive functions, which are more common in FP. However, language designers have found ways around these limitations and the JVM is definitely going to address these issues in the future.

By the way, Scala also compiles to .NET byte code, so the .NET community can enjoy Scala goodness, too.

What is the status of Scala on the CLR? Do you know anything about it's performance?

Alex Personally, I haven't worked with Scala on the CLR. My understanding is that CLR support is a lower priority for the developers working on Scala's implementation, and that support may not be complete at this time.

Dean I haven't worked with the CLR version, either. I have heard that Microsoft has given a grant to Martin Odersky's team to keep the .NET support current with the Java support.

With the upcoming changes to the JVM (tail call optimization and first class functions among others), will there be changes to Scala?

Alex I can't speak for the language's authors, but my understanding is that they track changes to the JVM closely to wring as much performance as they can out of Scala's implementation. As the JVM evolves to embrace its newfound role as host to myriad languages, I'm sure Scala will take advantage of those changes. No other language on the JVM has a team that's as capable of doing so.

Dean I've read some detailed blog posts by Charlie Nutter, the JRuby project lead, on the issues they have encountered supporting Ruby features on the JVM. One area of inefficiency is the need to wrap "blocks" (loosely speaking, "bare" functions) in little classes, consuming lots of resources. Some of the features planned for the JVM will certain benefit Scala by eliminating such workarounds.

What kinds of problems are a good fit for Scala?

Dean Scala's flexible syntax is surprising good for defining "internal" DSL's, for which Ruby is justly famous. If you need an "external" DSL, then the combinator parser library will probably be all you need to build a custom parser. This flexibility also allows Scala to provide some very elegant built-in API's for manipulating XML, building thick-client interfaces with Swing, etc.

I can't think of another language that has quite the flexibility for small to large scale problems.

Alex Scala's name is a shortening of "scaleable language". The goal of its creators was to design a language that scaled from small scripting tasks to desktop GUI applications and all the way up to huge enterprise systems. While Scala is certainly capable of all that, its sweet spot seems to be in producing maintainable back-end systems, particularly those that require non-trivial concurrency. Essentially, it's good for the things that languages like Java and C++ are good for, but without suffering the pains and hassles that often come with those languages.

That said, I really do believe that Scala scales from scripts on up. I've written tiny scripts that rip through giant XML files that are just as terse as anything I've written in Ruby and many, many times faster (even accounting for the JVM startup time). I've written a small blogging system of the sort that people usually write in Perl, Python, or PHP and found the code far more maintainable. At Twitter, we're using Scala for critical parts of our service's infrastructure, such as our message queue. I certainly believe in the right language for the right problem, but there's not much I wouldn't at least attempt to solve in Scala.

If you were putting together a development team for a scala project, what are some things you'd look for in the candidates?

Alex We're actively hiring engineers at Twitter, and this is definitely something we've had to think about when it comes to Scala experience, or lack thereof. We know the Scala community is small, and that hiring someone with prior Scala is unlikely today. I think that in a couple years, that's going to be a very different story.

Generally, in-depth experience with OOP, dynamic languages, and a smidge of functional language experience means that a programmer can get up to speed with Scala quickly. If a candidate can tell me what a closure is, or what a combinator is, or describe some basics of type theory, they're going to do fine with Scala. If they can't, though, chances are that they've used those features in other languages and just aren't familiar with the terminology.

The more experience with the Java SDK a programmer has, the easier it'll be to navigate the landscape of classes that Scala is built on. That's hardly a prerequisite, though, and I can say that from personal experience. I've mostly avoided Java over the past five year of my programming career, and it hasn't taken long to come up to speed with "Javaland" by way of Scala. When I need it, it's there. When I don't (which is most of the time), it's not.

I think the ideal Scala programmer is passionate about the language she works with every day. You can write perfectly passable code in Scala if you treat as just another tool, but if you really explore its rich set of features, there's so much to take advantage of. It's been great to see our engineers go from zero familiarity with Scala to writing code that uses the language's most advanced features, like parser combinators and actors.

Dean Over the years, I've found that really good developers tend to be very curious about other languages. So, even if they have no prior exposure to Scala, they have probably seen variations of its features in other languages. In my "day job", I train and mentor teams trying to adopt agile methods, like the XP practices (TDD, pair programming, etc.). I see so much damage in teams that lack these practices that I would also want my Scala new hires to be good at XP!

It seems a bit strange to talk about so much about a language without showing it off a bit. Could one of you provide a small program that shows Scala off a bit?

Alex Here's an example I used in a presentation:

"showing a nonexistant user returns 404" in {
 withFormats(List("xml", "json")) { format =>
 val response = User.show("jack", "asonetibaosneitb", format)
 response mustNot beNull
 response.code mustEqual 404
 response
 } mustNot beEmpty
}

In it, you can see Scala's support for Domain Specific Languages (via use of the Specs BDD library), anonymous functions, and the clarity and fluidity of Scala's syntax. Given how much time a programmer spends (or should be spending!) writing tests, I think this beautiful test code really shows off what Scala can do in just a few lines.

Dean Scala's support for building nice DSL's doesn't get enough attention, IMHO. It's a killer feature, for the same reason it's so seductive in Ruby. Here's another DSL example, a snippet of code for a build tool I've been working on.

target('compile -> List('clean, 'build_dir)) {
 scalac(
 'files -> files(srcDir+"**/*.scala", specDir+"**/*.scala"),
 'classpath -> environment.classpath,
 'd -> buildDir,
 'opts -> "-unchecked -deprecation"
 )
}
target('clean) {
 deleteRecursively(buildDir)
}
target('build_dir) {
 mkdir(buildDir)
}

It's inspired by Ruby's "rake". You specify targets, named with Scala symbols (e.g., 'compile) and there are built in functions for invoking the compiler, manipulating files and directories, etc.

By the way, it seems to be an unofficial Scala community requirement that when you do a project to learn Scala, it must either be a build tool or a Twitter client...

Design patterns and algorithms look differently when implemented in different languages. Can you give us some examples of elegant patterns or algorithms in Scala?

Alex Scala's implementation of inheritable, extensible cross-cutting concerns in the form of Traits is one of the language's best features. Imagine Ruby modules on steroids and you're getting there. That's a difficult problem for most languages to handle well, and Scala does a great job at it.

Scala's Actor library is another superbly-implemented part of the language. While Actors in Scala feel "baked in" to the language, in actuality it's a completely self-contained library. The Actor model can be found in Erlang, Io, and a number of other experimental languages, but it feels solid and right at home in Scala.

Dean Indeed, the Actor library is another example of the flexible support for building internal DSL's.

Just for emphasis, let me echo what Alex said about Traits. It's one of the scalability features (in terms of application size and complexity) that I'm most excited about. Here's another way to describe traits; it is Scala's mechanism for supporting "mixin"-style composition, originally made famous in Lisp and more recently in the form of Ruby modules. You have your main class hierarchy (single inheritance, like Java), but you can mix in abstractions and implementations in a modular way, defined as traits. With Java, you can only "mixin" the abstraction part as interfaces. You have to resort to ad-hoc hacks to add implementations. This composition mechanism solves some of the issues that Java users turn to Aspect-Oriented Programming to solve and it promises to encourage more modular designs that will grow gracefully over time.

The question of Design Patterns is an interesting one right now. Patterns are getting a lot of bad mouthing from some reputable (and not so reputable) people. Without rehashing the arguments, let's just say that the central argument seems to be that patterns are just workarounds for language deficiencies. I think that misses the point that a good pattern stands on its own merits. If a language supports it "natively", then so much the better!

Because of Scala's support for FP, especially closures, some design patterns just aren't as important as they are in Java. (I'm looking at you, Visitor!) Rather, API designers can build in elegant hooks for clients to pass in closures to customize behavior, etc.

Also, traits make patterns like Observer very elegant. I've heard there are some good examples of Observer in a Scala book O'Reilly is publishing, available now as a Rough Cut!!

Click here to Tweet this article

There are several good looking Scala books on their way to market. I'd like to help you get an early look at the books and their authors, so I'm working on a series of Scala author interviews for the FP side of On Ruby. Here's the first of several interviews.

I've spent some time talking with David Pollak (@dpp) about his upcoming book from Apress, Beginning Scala (also available, electronicly, as an Alpha book from Apress). Read on to see what he has to say.

---

Functional Programming languages seem to be an increasingly popular topic. Why? What do FP languages teach or do for us?

David I came to Scala via Ruby. I was doing some Ruby and some Java coding (I've been doing Java since 1996). My Java code started taking on a "Ruby Flavor" in that I was passing around a lot of code blocks. In Ruby, passing code block, lambdas, etc. is super-simple. In Java, I was creating lots of anonymous inner classes and passing them around... it was a syntactic disaster.

In Scala, passing a function, a block of code, as a parameter is as easy and syntactically pleasing as it is in Ruby (or nearly so... Charlie Nutter has been barfing all over Scala's syntax lately.) This is the first part of what I understand FP to be. So, in a way, Ruby is a functional language.

In addition to the simple ability to pass code blocks as parameters, other touch-stones of FP style coding are:

• Immutable data structures
• Pattern Matching
• Optionally, a math-driven type system
• Optionally, lazy evaluation

Scala's default collections classes are immutable. Once an instance has been created, the value of that instance, whether is be a List, a Map (dictionary), etc. never changes. This is familiar to Java programmers. Java's String class is immutable. Once you create a String, you can never change it. Python requires immutable data structures for keys to dictionaries. Immutability introduces a new way of approaching a program. One thinks about methods as things that take input and return output and will always return the same output given the same input. In Ruby, String is mutable and there have been many a bug in my programs because some other method changed the value of a String out from under me.

Pattern matching provides a powerful way to use declarative syntax to express business logic. I'm include an example in the idomatic section of intercepting an incoming HTTP request using pattern matching.

Scala has a very powerful type system including a type inferencer. What that means is that you can define very powerful rules (e.g, when building a query, you can only pass a String into a column that is a VARCHAR) in the library, but the end-user gets the syntactic simplicity of Ruby.

Scala supports lazy evaluation at the language level and in the libraries. This means that only elements that are actually accessed are computed.

Functional languages teach us how to think in terms of transformation rather than getting/setting. Functional programming focuses the developer's eyes and mind on the business logic rather than the boilerplate of flow of control. Functional programming gives us different kinds of abstractions to compose than objects. Composing functions and performing operations on collections just as easily as performing operations on single items changes the focus of development to logic rather than mechanisms.

What makes Scala the right FP language for people to pick up?

David Scala along with OCaml and F# are the "practical" functional languages. You can get things done out of the gate with any of these languages. You don't have to learn a lot of theory to get things done with Scala, OCaml or F#. With these languages, you can dip your toe in the functional waters without having to take an immediate plunge. Neither of these things is true of Haskell or Erlang.

Scala and F# have the Java and CLR libraries immediately available which is a killer reason to choose either of these languages.

Scala has better OO abstractions than does F# or any other language. Scala seems to have integrated OO and a Type System in a way that no other language has.

Why is your book the right one for people to pick up and learn about Scala?

David I take a very simple approach to Scala. There's very little theory and a whole lot of simple examples and idioms. I've tried to make sure that the code is oriented toward practical users of Java as well as practical users of Ruby. The chapters are short and to the point. More of the code examples can be typed into the REPL (like irb) so the reader can get immediate feedback on the example and the language as a whole.

Why is the JVM a good platform for Scala and FP?

David:

1. It just works
2. It's very, very fast
3. Excellent integration with existing Java libraries
4. The ability to intermix Java and Scala (and Groovy and JRuby) in a single project
5. The JVM is everywhere and it's well tuned everywhere

What kinds of problems are a good fit for Scala?

David Heh... everything from simple scripting on up to extremely complex systems. With the exception of Erlang's distributed capabilities and C's native device capabilities, I think that every other problem is well solved with Scala. But, I'm biased. :-)

Design patterns and algorithms look differently when implemented in different languages. Can you give us some examples of elegant patterns or algorithms in Scala?

David A BDD Test:

 object BoxSpec extends Specification {
 "A Box" can {
 "be created from a Option. It is Empty if the option is None" in {
 Box(None) mustBe Empty
 }
 "be created from a Option. It is Full(x) if the option is Some(x)" in {
 Box(Some(1)) must_== Full(1)
 }

A Multi-user web-based chat application:

 case class Messages(m: List[String])
 object ChatServer extends Actor with ListenerManager {
 private var msgs: List[String] = Nil
 protected def createUpdate = Messages(msgs)
 override val highPriority: PartialFunction[Any, Unit] = {
 case s: String =>
 msgs ::= s
 updateListeners()
 }
 this.start
 }
 class Chat extends CometActor with CometListenee {
 private var msgs: List[String] = Nil
 
 def registerWith = ChatServer
 
 override def highPriority = {
 case Messages(m) =>
 msgs = m
 reRender(false)
 }
 
 def render =
 <div>
 <ul>
 {
 msgs.reverse.map(m => <li>{m}</l>>)
 }
 </ul>
 {
 ajaxText("", s => {ChatServer ! s; Noop})
 }
 </div>
 }

A REST API handler:

 case Req(ApiPath :: "statuses" :: 
 "public_timeline" :: Nil,
 this.method, GetRequest) => publicTimeline
 def publicTimeline(): Box[TwitterResponse] = {
 val statusList =
 Message.findAll(OrderBy(Message.id, 
 Descending),
 MaxRows(20)).
 map(msgData _)
 Full(Right(Map("statuses" -> 
 ("status", statusList) )))
 }

One more very nice piece of code... find all the classes used by <p> tags in an HTML document:

for {p <- x \\ "p"; ca <- p \ "@class" c <- ca.text.split(" ")} yield c 

What tricks or tools do you suggest someone beginning to read Scala use?

David Don't just read, but use. Open the Scala REPL and start typing. Start playing. Start exploring. Try to understand the actual thing that happens when certain constructs are used. In this way, it's 100% the same as a newbie exploring Ruby. Type a line... see what happens... type another... see what happens. Touch, feel, play.

What are some good Scala code bases to read?

David The Lift utils packages is a nice place to start.

What blogs are good for learning more about Scala?

David

• scala-blogs.org
• technically.us/code
• www.drmaciver.com/planetscala/
• james-iry.blogspot.com/
• www.gracelessfailures.com
• jonasboner.com/
• matt.immute.net/taxonomy/term/11/0
• www.codecommit.com/blog/

Click here to Tweet this article

Ola Bini is one of my favorite blog reads, and recently he’s been writing about scala a functional language that lives on the JVM.

Scala has been pretty hot in the blogging world recently and the recent availability of Programming in Scala pre-prints should only increase that interest.

Since I’m working for a Java shop, maybe it’s time for me to spend a little more time getting acquainted with Java, JRuby, Scala, and the other languages that run on the JVM. Doing so would certainly tie in with the ideas of learning a new language each year and becoming a polyglot programmer.