Scala vs.Clojure, part 3 – the similarities

There is some more discussion of Scala vs. Clojure. With the Oracle deal, and some discussions about the slow Java 7 release, it looks like Java is detoriating faster not slower. So discussions about Java succession increase. I've discussed Scala vs. Clojure here, here and here. Greg Osuri now adds his take in "Scala Vs Clojure", What the market thinks and compares job numbers for Clojure and Scala.

What I found interesting was a comment to that post:

I'm not really sure why Scala and Clojure are always discussed side-by-side. Sure, they're both relatively new languages and they are both on the JVM, but Scala and Clojure have vastly different philosophies.

Scala and Clojure are indeed very different, so why compare them? I've wondered the same in the past, because, hey, they just don't look alike. And nothing less than "different philosophies". As Jesper on Stack Overflow writes:

Note that Clojure and Scala are two totally different types of programming languages - Clojure is a functional Lisp-like language, it is not object oriented. Scala is an object oriented language which has functional programming features.

But then why are they compared and mentioned together? To some, Java looks to need a successor - see my Is Java dead? analysis - both languages have enough momentum to be discussed as one (contrary to Fan for example). Both are functional languages, both support objects, both favor concurrency. So they are remarkly alike. Only on the first look are they quite different, as Scala favors C style syntax for OO and FP while Clojure favors Lisp style syntax. But that's only lipstick.


In detail, Scala and Clojure look quite similar:

  1. Scala and Clojure are more alike than different
  2. Both have a strong focus on functional programming
  3. Both favor tight Java integration and basing apps on Java libraries (with wrappers) - with Clojure having a little bit more autarky tendencies
  4. Clojure more Lisp style, but with objects (see protocols)
  5. Scala more C style, but with functions
  6. Both favor persistent collections (immutable)
  7. Both favor new ways of concurrency, STM (Clojure) vs. actors (Scala), but both support the other mechanism with agents in Clojure and STM in Scala or Scala CCSTM


So you might wonder, with all those similarities, is it only a syntax thing? I might concur yes. You can think the same way in both languages, what you perhaps choose are differently thinking communities. The major difference is that Scala has very powerful type system - if you're into that type of thing - Clojure is loosly typed, but can have type hints - also see here. There is a strong type focus in the Scala community, influenced by early adopters.

Hope this helped to clear some things up.

If you liked this post, might also be interested in some other post I wrote about the topic:

8 steps to reduce blog load times from 4sec to below 1sec

I'm obsessed with metrics. I'm obsessed with the number of RSS subscribers. With Google PageRank. Google seems to push faster internet to everyone, with fiber to the home, their own DNS, the page speed plugin and hosting Ajax libraries. As I wanted to get some more Google love, going from PR4 to PR5 and not falling back to PR3, I needed to speed up my blog. But where to start? Isn't this impossible if you're not a professional? All of you might have thought about speeding up your website or blog I guess along the same thoughts:

  • Page speed influences pagerank (PR) in the future
  • Firefox experienced a 15% increase in conversion for downloads, by speeding up their landing page recently. For a blog this means better conversion of RSS subscribers and newsletter signups.
  • I was shocked when I saw Google Webmaster Tools show page speeds of 5-15 seconds, still not sure why but urgently needed to get better.
  • Faster pages just feel more professional.
  • Took the opportunity to declutter the blog. Removed external widgets like PostRank I no longer use.

The result of my work is that page loading times are down from 4sec to below 1sec mostly (measured by Pingdom Tools) - Still too slow as I want to get below 0.5sec, but much better than before.

Here are the 8 steps I took to get this amazing improvement:

  1. Inspect your page, e.g. with YSlow, Google Page Speed or Pingdom Tools. Measure, measure, measure. Think about every little Javascript, every image and every CSS. Are they really needed?
  2. Delete all plugins in WordPress you do not really really need - they often inject Javascript or CSS into the page, even if you do not use the plugin in a widget or on the page.
  3. I've added a cookieless domain, to post stuff I do not want to put into the CDN. YSlow suggested this and I've seen Stack Overflow use
  4. Move to a CDN - most of my readers are in the US, my server is in Germany. This leads to slower image downloads and especially latency, or startup times before the first byte arrives. I've chosen Cloudfront for now because it was easy to setup and I had an Amazon account. I'm using CloudBerry for uploads, it's free in the basic version and just works. I might move to a cheaper CDN that better supports (SimpleCDN is full!) GZIP and expire headers. I've added a domain for my CDN usage at which adds some flexibility.
  5. I've removed merciless Javascript from WordPress (JQuery was twice on the page), I've minified JS and packaged all CSS into one CSS file. This results in less DNS lookups, less http connections and smaller files and overall reduces page loading times significantly.
  6. Added expire header in the far future with a version URL scheme ( /version/images/ ... e.g. /1/images), so everything is cached in the browser. I can increase the version number with new assets. Expire headers are easy to do with Apache on by adding .htaccess, more difficult with Cloudfront (see above, a reason to possibly move to another CDN). I also removed ETags when possible so the .htaccess looks like this:
    ExpiresActive On
    ExpiresDefault "access plus 1 year"
    FileETag None
  7. Added GZIP where possible, was easier with Apache than Cloudfront:
    <Files *.js>
    SetOutputFilter DEFLATE
  8. I've reduced the number of posts on the page. Now there are only 3 posts on the start page. I might move to summaries, as they are shorter, have less images, faster download.

Overall I'm pleased with the results. Especially as the page really feels much faster to me, not only the metrics are better. So what's left to do: External images and JS, like tweetmeme, quantcast and Google Analytics still are slow - something I need to solve.

I had some fun during all of this and learned a great deal about CDNs, so I suggest you do the same.

How to use an Ultra Thin Web UI with Play Framework

Many times I've seen fat UI layers and waded through molasses of unreadable business logic. Why are UI layers growing fat so fast? Because for most developers it seems to be the easiest thing to stuff code and logic into the web layer - I've done that too! No need to create new classes, no need to think, no need for architecture. This leads to bugs, cut & paste code all over the place and makes it really hard to understand what's going on. The worst I've seen is lots of programming language code in templates, but nearly as bad are fat controller classes.

Josh Symands writes in "Rails Worst Practices: 13 Coding Nightmares You Should Avoid" about chubby controllers:

There should be no business logic in a controller.

Read that again.

There should be no business logic in a controller.

Controllers do two things: they take data from the params or session and send it to the model. The MODEL performs all the necessary logic. Then, the controller does the other thing that's completely necessary: it decides what should be shown to the user. That's it. The sum total of a controller action is two steps long.

Send information to the model.
Decide what to display.
If you are doing ANYTHING ELSE in your action, you are doing it in the wrong place. The end.

Wherever I've seen a fat UI layer, I go on a crusade to thin the web layer. This is often hard and thorny, because it needs a lot of time to clean your UI layer. Why? Because a thin layer has

  1. better and easier unit testing
  2. more and better reuse
  3. and you will need to change your web framework in the future, which is usually not possible with a fat UI layer. Then you're screwed.

I've dabbled with ultra thin UI layers before, with the Editor/View pattern to easily support Swing/SWT frontends for the same code. And I came back to the topic recently when diving deeper into Domain Driven Design. As Eric Evans writes in his Domain Driven Design book, don't put logic in your UI layer if your following DDD (he says it might be ok to go with a "Smart-UI" and not do DDD, but then you need to adjust your development effort accordingly).

A way to keep your web layer thin is to introduce use case classes. Those do one thing and are application specific. They are not part of your domain layer, but use esxtensivly services and repositories from your domain layer.

A controller method in Play could look like this:

def newUser(templateId: String): Unit = {
    val user = use(new NewUserUseCase())

    val newList = use(new NewListUseCase(templateId,

    val listId =

It's not doing much beside calling two use case classes.

The neat implemantation of use() injects all domain layer dependencies into the use case classes, then executes the use case and returns it's result.

  def use[R](useCase: {def execute(): R}): R = {

An example use case from the example above that creates a new user does look like this:

class NewUserUseCase {
  @Inject var userRepository:UserRepository = _
  @Inject var idService:IdService = _

  def execute(): User = {
    var userId = idService.newId

With this setup, the web layer is ultra-thin, just calling use cases of the application layer. We now can

  1. easily unit test the use case classes
  2. reuse the use case classes in different controllers
  3. if we need, change the web framework by reusing all use case classes

Mission accomplished. How do you keep your web layer ultra thin?

Update:Found this here.

This one, simple, single line interface leads to many tangible benefits. The use of the ViewService interface completely decouples your code from your selection of which MVC framework you use. Your MVC selection no longer needs to be a strategic or organization-wide decision because switching, or even using a separate MVC framework per application, is now trivial. Each application you create now has the freedom and flexibility to use the best framework for the given requirements and technical circumstances.

The mixing MVC frameworks due to a thin web UI I completly forgot in the post.

Stateless Applications are an Illusion

Stateless applications have haunted me over the years. There is a mantra for web development: Keep your application stateless. I have seen companies pilling money on the effort to go stateless with their web applications. I've encountered a company with a multi million lines of code application with a stateful web framework going coniserable lengths to reengineer the app to being stateless. I have seen companies who don't scale because they wanted to be stateless. All of this haunted me. Because it should not haunt you as a developer, I will take a deeper look and show that it's impossible to keep most applications stateless.

To begin with, I divide state into two kinds:

  1. Application state (like Orders)
  2. Conversational state (temporary state during a session)

Some applications do not need state, or only have application state. The viewing part of CMS for example. One view sees applications as state machines and the essence of web requests to change this state. Beside the two kinds of state, there are at least two dimensions of state:

  1. accidental, framework state
  2. use case driven state, often the conversational state from above

The first dimension of state, framework state, can be designed away. There are frameworks which keep state during their operation - Tapestry for example. By chosing the right framework and architecture, you can minimize or prevent framework state. The second dimension cannot be designed away. If your use case calls for state, you need to store that state. A checkout process comes to mind: customers choose over serveral pages delivery address and payment information. Baskets come to mind: they store their conntent often only during a session. That conversation state needs to be hold somewhere.

When people talk about stateless applications, they in fact mean no state in the web tier. But state can be stored in several layers:

  1. Best state store: Client ( hack, Javascript variables for AJAX applications, Cookies)
  2. Pages (e.g. with JS variables or Hidden fields)
  3. Easiest state store: Web Tier (HTTPSession in Java applications)
  4. Infrastructure (Cache like Memcached, Databases like MySQL, NoSQL like Redis)

You need to decide where to put your conversation state, but you cannot prevent your app from having state if the use case calls for it. What about using the easiest and fastest state store, your web tier? ThePlay framework says:

But this is much better because a session is not the place to cache your application data!

Contrary to this, your web tier session is a very good place to cache your application data. Problems do not arise when your web session is a cache (might arise if you do not handle stale data, but every cache has that problem), and can be constructed easily with the help from a persistent state store. e.g. store the UserId in a persistent store like Redis, cache the User object in your session. In case of a session failover, the new server will reconstruct the session from your persistent state store. Many developers do not like web tier state because your web tier does not allow easy failover and scaling. But when thinking the session as a cache, not a state store, no problems arise in case of taking down one web tier server.

As always there are trade offs, there is no best solution, be it web tier caching or "stateless" applications. As a developer you need to decide between the different trade offs of state storage.