Technology Lesson

After some functional programming on day two, its time for the third and final day of Scala in Seven Languages in Seven Weeks.

Scala, Day 3: Thoughts

After two lengthy chapters on the object oriented and functional programming syntax/options in Scala, the third day rushes through some of the most intriguing features, including pattern matching and concurrency via actors. I would have preferred to spend a bit more time on these complicated topics.

In fact, I had the same complaint on Day 3 of IO, where we also blasted through a discussion of concurrency in just a few pages. I respect the difficulties of plowing through seven different languages in a single book and dont expect deep discussions of any one of them, but I think the book wouldve been stronger if it had a greater bias towards the more advanced "day 3" topics of each language instead of basic syntax discussions in day 1 or 2.

Scala, Day 3: Problems

Extend the "sizer" application to count and size links

Take the sizer application (code, output) and add a message to count the number of links on a page. Follow these links and calculate their size as well, so you get the total size for each page.

The code:

The output:

This problem was a great way to experiment with actors in Scala. The sequential solution is self explanatory, so heres an outline of the concurrent one:

1. The caller creates B Base Actors, one for each of the B base URLs.
2. The caller then calls receive to await a message from each Base Actor.
3. Each Base Actor concurrently loads its base URL, finds the links on the page, and creates L Link Actors, one for each of the L links on the page.
4. The Base Actor then calls receive to await a message from each of its Link Actors.
5. Each Link Actor concurrently loads the page for its given link and sends a message to its parent Base Actor with the size of that page.
6. When the Base Actor has received a message form each of his Link Actors, it sends a message to the caller with the total size.
7. When the caller has received B messages from the Base Actors, we are done.

The sequential code takes nearly 20 seconds to run while the concurrent code takes less than 3 seconds, a 7x improvement. The concurrent code is definitely more complicated, but not unreasonably so. Even though it was my first time using Scala actors, the code took less than 30 minutes to get working, much of it spent learning about the self keyword. In fact, I find it very easy to reason about Scalas actors, which is not something I can say for Javas synchronized keyword, Executors, Runnable, and various other concurrency constructs. 

User experience counts. Not only for products, but for programming languages too.

How many features can you pile into one language before it becomes too cumbersome? How much syntax sugar do you need to understand to be able to read or write code? How many paradigms and mental models do I need to juggle to follow along? Do so many options make a language more flexible or less? Will there be such a thing as "idiomatic Scala" or will it be a free-for-all? Is it better to have a dozen ways to do something or one "proper" and well known way?

I dont know the answers to these questions, but I suspect theyll have a large impact on Scalas adoption. In the meantime, Ill keep hacking away at it to see what I can learn.

On to Erlang

Read on to learn about the next language in the book, Erlang.