[{"_1":2,"_85":-5,"_86":-5},"loaderData",{"_3":4,"_37":-5,"_38":39,"_71":72,"_83":-5,"_84":-5},"root",{"_5":-5,"_6":-5,"_7":8,"_22":-5,"_23":24,"_25":26,"_29":30,"_35":36},"user","shoppingCartId","shoppingCart",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":14},"id","no-cart","count",0,"free",true,"updatedAt","2026-01-27T08:25:44.708Z","paymentGateway","STRIPE","cartItems",[],"loading","toast","locale","en","constants",{"_27":28},"paypalClientId","AX53Cwz8jR6rVVzzZiZNWWXl0dGagi-GZrjG-S3Ua14E5nrKMn7DxDQ730O4R8LusLPp49ALn6aRVaEy","publishers",{"_31":32,"_33":34},"companies",[],"universities",[],"needsLocaleCookieSync",false,"routes/_store+/_readers+/read_/route","routes/_store+/_readers+/read_.$slug/route",{"_40":41,"_65":66,"_67":68,"_69":36,"_70":-7},"book",{"_42":43,"_44":45,"_46":-5,"_47":48,"_51":52,"_54":55,"_63":64},"title","Scala Idioms","slug","scalaidioms","metaText","coverFeatured",{"_49":50},"url","https://d2sofvawe08yqg.cloudfront.net/scalaidioms/s_featured?1620378093&1620378093","coverFeatured2x",{"_49":53},"https://d2sofvawe08yqg.cloudfront.net/scalaidioms/s_featured2x?1620378093&1620378093","authors",[56],{"_9":57,"_58":59,"_5":60},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci81MzEy","name","Dominic Fox",{"_61":62},"username","poetix","showReadLinkString","full","parts",[],"toc",[],"isUnavailableOnline","unavailableMessage","routes/_store+/_readers+/read_.$slug.$chapterId/route",{"_42":43,"_73":-5,"_40":74,"_80":-5,"_81":82},"content",{"_75":76,"_42":43,"_46":-5,"_44":45,"_63":64,"_77":78,"_79":-5},"previewContent","

\n\n\n

Scala Is Not A Language

\n\n

If you’re new to Scala, the chances are you’ll have some complaints. The language seems bewilderingly large and complex; things can and do go wrong in unexpected ways. One moment it’s implicit function arguments that are the source of the frustration, the next it’s something called the “cake pattern”. Those who’ve been working with the language a little longer are likely to smile benevolently and humour your objections with an infuriating air of enlightened tolerance. “Just stick with it”, they may say. “I felt exactly the same six months ago, and then…”

\n\n

And then what? Not everybody will make their peace with Scala: some people will always dislike the language, and some of them will have good reasons for doing so. But the transition from wary discomfort to actual enjoyment of Scala programming is a common one, and seems to take place for many people after somewhere around six months of exposure to it. What changes for them? Is it just a matter of increased familiarity, or is there some particular realisation that makes all the difference?

\n\n

A colleague of mine, Ian, described his own discovery of the true nature of Scala in the following terms. On first acquaintance, he had thought of it as a language like Java or Python, only bigger and hairier. His own preference for compact, single-idiom languages that are easy to fit into your brain made him rebel against Scala’s seemingly profligate abundance of features and supported programming styles.

\n\n

According to Larry Wall, famously, in Perl “there’s more than one way to do it” - which makes Perl a great tool for hackers who enjoy creatively flexing the language, but a many-tentacled nightmare for those who prefer Python’s more prescriptive rubric: “there should be one - and preferably only one - obvious way to do it”. Scala seemed to Ian to favour the solo hacker (or freewheeling show-off) over the team-player who wrote software for others to read and understand.

\n\n

Indeed, there was a general feeling in our team at the time that the only safe way to use Scala was to restrain the show-offs, and stick to a subset of the language that everyone felt comfortable with. The trouble with that approach was that whatever features we decided to rope off as unsafe, we’d find ourselves forced to use by 3rd-party libraries for which they appeared to be essential. The complexity seemed unavoidable.

\n\n

However, my colleague came to realise that Scala was not a language in the sense the Java or Python were languages, but rather a toolkit out of which a family of related mini-languages could be put together. Each of these mini-languages was compact and consistent: the art of Scala programming was knowing their different idioms, and deciding which to use for a given task. Once you understood this, the different pieces of the picture started to separate out. Instead of a confusing whirl of novelty, Scala started to seem like a collection of well-designed parts - parts that actually hung together surprisingly well.

\n\n

Of course, it’s an exaggeration to say that Scala “isn’t a language”. What Scala isn’t, is a single-idiom language. Scala is both “multi-paradigm”, notably in the sense that it supports both object-oriented and functional programming styles, and multi-idiom, in the sense that it supports the creation of mini-languages tailored for specific purposes. If you’re having trouble finding out what “idiomatic Scala” is supposed to look like, it may be because there are multiple idioms to choose from.

\n\n

The purpose of this book is to explore some of these idioms, and to show how a DSL (Domain Specific Language) like ScalaQuery, an advanced typeclass library like Scalaz and a distributed programming framework like Akka can coexist within the same language, each defining its own particular patterns of usage. We’ll be looking at code examples, getting to know the techniques and language features which support each idiom, and critically comparing them. My ambition is not to answer the question “when should I use X?” for you, but to enable you to answer that question for yourself, on the basis of a widely-informed understanding of the options and possibilities that Scala provides.

\n\n

Rudiments: `map`, `flatMap`, `filter` and `fold`\n

\n\n

In this chapter, we’ll look at one of the simplest and most fundamental sub-languages of Scala, the data query and transformation language provided by the collections library. We’ll see how the logic of relational queries over database tables, expressed in SQL, translates into the logic of functional queries over in-memory collections, expressed in native Scala.

\n\n

By “functional queries” I mean simply queries expressed using the higher-order functions map, flatMap, filter and fold (or its variants: foldLeft, foldRight and reduce). In Scala these are implemented as methods on collection types (e.g. List) which take a function and return the method’s target transformed using that function. Let’s start with an example of one such query. Consider the following snippet of code, which takes a list of three numbers, multiplies each of them by 2, throws away any that are not greater than 2, and adds the remaining numbers together:

\n\n

1 List(1, 2, 3).map(_ * 2)\n2              .filter(_ > 2)\n3              .foldLeft(0)(_ + _)\n4 //> res1: Int = 10\n

\n\n

Syntactically, this has the look of a “fluent API” in which method calls are chained and laid out across several lines. Each method call returns a new value - the initial List(1, 2, 3) is unmodified - so that a sequence of intermediate values is threaded from call to call. If we pull out and name the intermediate values, it looks like this:

\n\n

1 val initialList  = List(1, 2, 3)                   //> initialList: List[In\\\n2 t] = [1, 2, 3]\n3 val doubles      = initialList.map(_ * 2)          //> doubles: List[Int] =\\\n4  [2, 4, 6]\n5 val greaterThan2 = doubles.filter(_ > 2)           //> greaterThan2: List[I\\\n6 nt] = [4, 6]\n7 val summed       = greaterThan2.foldLeft(0)(_ + _) //> summed: Int = 10\n

\n\n

The map method applies the function _ * 2 to each member of initialList, returning a list of doubles, while the filter method creates a copy of doubles which contains only the values for which the function _ > 2 returns true. Finally, the foldLeft function takes an initial value of 0 and adds each of the values in greaterThan2 to it in turn, obtaining the sum of the values in the list. (In fact, for lists of numeric values there’s a sum method that does exactly the same.)

\n\n

A great many operations which involve selecting some subset of a dataset, transforming it and presenting some summary of the result can be expressed using this language, and it is common in Scala to use this idiom to express algorithms which can be broken down into steps of these kinds. (We’ll consider some of the shortcomings of this idiom, and discuss an alternative approach, later on).

\n\n

Relational queries

\n\n

A relational query is a query which is expressed in terms of some variation of relational algebra. The database query language SQL may be considered a somewhat low-fidelity implementation of this idea. Among the operations it supports are projection, which identifies a range of columns to return, and selection which restricts the returned column-sets to those matching a particular condition.

\n\n

Confusingly, the keyword SQL uses for projection is SELECT:

\n\n

1 SELECT name, age\n2 FROM   Person\n

\n\n

Here we have a table, Person, and a query which projects the name and age columns from this table, returning a result set containing the name and age of every person in the table. For selection, we use the WHERE clause:

\n\n

1 SELECT name, age\n2 FROM   Person\n3 WHERE  age > 40\n

\n\n

In this case, we are only interested in persons over 40 - the condition (or “predicate”) age > 40 is applied as a test to each person in the table, and the projection is only applied to those which meet the condition.

\n\n

Projection and selection in Scala

\n\n

Let’s see if we can define a similar query in Scala. Firstly, we define a Person using a case class:

\n\n

1 case class Person(name: String, age: Int, favouriteColour: String)\n

\n\n

Secondly, we create a data structure - in this case, a plain List - containing several Persons:

\n\n

1 val maggie = Person(\"Maggie\", 32, \"Red\")\n2 val millie = Person(\"Millie\", 24, \"Blue\")\n3 val molly  = Person(\"Molly\",  45, \"Green\")\n4 val may    = Person(\"May\",    41, \"Yellow\")\n5 val persons = List(maggie, millie, molly, may)\n

\n\n

Finally, we can express our query over this structure using map and filter:

\n\n

1 persons.map(person => (person.name, person.age))\n2        .filter(_._2 > 40)\n3 //> res1: List[(String, Int)] = [(\"Molly\", 45), (\"May\", 41)]\n

\n\n

The map performs the “projection” part of the SQL query (the SELECT clause), projecting a tuple of name and age out of each Person. The filter then applies the “selection” (the WHERE clause).

\n\n

Joining tables

\n\n

Now for a more complicated example. Here’s a straightforward join in SQL, expressed by taking the Cartesian product of two tables and selecting only those rows in the product where the row in the second table is related to the row in the first:

\n\n

1 SELECT p.name, p.age, a.postcode\n2 FROM   Person p, Address a\n3 WHERE  a.occupant_id = p.id\n

\n\n

This will give us the name, age and postcode of every person who has an address, for every address that they have (some people might have more than one).

\n\n

Now here’s some Scala that will (rather inefficiently) do the same:

\n\n

 1 case class Address(postcode: String, occupant: Person)\n 2 \n 3 val addresses = List(\n 4   Address(\"AB1 2CD\", maggie),\n 5   Address(\"VB6 5UX\", maggie),\n 6   Address(\"HR9 5BH\", may)\n 7 )\n 8 \n 9 addresses.map(address =>\n10   persons.filter(address.occupant == _)\n11          .map(person => (person.name, person.age, address.postcode)))\n12 //> res1: List[List[(String, Int, String)]] = List(List((Maggie,32,AB1 2CD)\\\n13 ), List((Maggie,32,VB6 5UX)), List((May,41,HR9 5BH)))\n

\n\n

Because we have two nested maps here, we end up with a List of Lists. We can “flatten” this into a single List by using flatMap in place of the first map:

\n\n

1 addresses.flatMap(address =>\n2   persons.filter(address.occupant == _)\n3          .map(person => (person.name, person.age, address.postcode)))\n4 //> res1: List[(String, Int, String)] = List((Maggie,32,AB1 2CD), (Maggie,3\\\n5 2,VB6 5UX), (May,41,HR9 5BH))\n

\n\n

The combined use of flatMap and map here gives us a clue that this code could be written more concisely and pleasingly in for-comprehension syntax (if you don’t know why this is, don’t worry - we’ll come back to it):

\n\n

1 for {\n2   person  <- persons\n3   address <- addresses if address.occupant == person\n4 } yield (person.name, person.age, address.postcode)\n

\n\n

However, as we said, this code is rather inefficient - it has to do the equivalent of a “table scan” across the addresses collection for each person in the persons collection. If we had many more persons and addresses, then it might be better to construct an index:

\n\n

1 val addressesByOccupant = addresses.groupBy(_.occupant)\n2 for {\n3   person  <- persons\n4   address <- addressesByOccupant.getOrElse(person, List.empty)\n5 } yield (person.name, person.age, address.postcode))\n

\n\n

What does groupBy do? It maps over the collection, using the supplied function to extract a key for each value, and building up a list of items which have the same key. The resulting set of key/list-of-items pairs is returned as a Map[Key, List[Item]]. We can then use this to look up all the addresses having a given occupant (returning an empty List if the person has no addresses).

\n\n

A good SQL query optimiser will determine when it is more efficient to construct an index to compute a join, and try to ensure that the “query plan” into which the SQL statement is compiled implements a suitable strategy for retrieving and combining the required data. In this Scala code we are working at the level of the query execution engine which actually carries out the query plan, rather than defining a query in a declarative style which can then be optimised. Later on we’ll see how ScalaQuery makes it possible to define declarative queries, which are converted to SQL and passed to the database engine to optimise, using native Scala syntax.

\n\n

All you need is `fold`\n

\n\n

We could write a groupBy function explicitly in terms of map and foldRight as follows:

\n\n

1   def groupBy[A, B](iterable: Iterable[A], key: A => B): Map[B, List[A]] =\n2   iterable.map(item => (key(item), item))\n3           .foldRight(Map.empty[B, List[A]]) { (map, pair) =>\n4     map + (pair._1 -> (pair._2 :: map.getOrElse(pair._1, List.empty[A])))\n5   }\n

\n\n

\n\n\n

\n\n","tocStructure",[],"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Table of Contents

Scala Is Not A Language

Rudiments: map, flatMap, filter and fold\n

Relational queries

Projection and selection in Scala

Joining tables

All you need is fold\n

Rudiments: `map`, `flatMap`, `filter` and `fold`\n

All you need is `fold`\n