Clojure, Programming, Scala

Horses for courses: choosing Scala or Clojure

So one of the questions after my recent talk trying to compare Scala and Clojure (something that I suspect is going to be an ongoing project as I hone the message and the tone) was about whether the languages had problem domains they were more suited too. That’s an interesting question because I think they do and I thought I might be interesting to go through some of the decision making process in a more considered fashion than answering questions after a talk allows you to do.

So some of the obvious applications are that if you want to leverage some Java frameworks and infrastructure then you definitely want to use Scala. Things like JPA, Spring-injection, Hibernate and bean-reflection are a lot easier with Scala; in Clojure you tend to be dancing around the expectations these frameworks have that they are working with concrete bean-like entities.

If you are going to work with concurrency or flexible data formats like CSV and JSON I think you definitely want to be using Clojure. Clojure has good multi-core concurrency that is pretty invisible to you as a programmer. The key thing is avoiding functions with side effects and making sure you update dependent state in a single function (transaction). After that you can rely on the language and its attendant frameworks to provide a lot of powerful concurrency.

Similarly LISP syntax and flexible data go hand in hand so writing powerful data transforms seems second nature because you are using fundamental concepts in the language syntax.

Algorithm and closed-domain problems are interesting. My personal view is that I find recursion easier in Clojure due to things like the explicit recur function and the support for variable-arity function definitions. Clojure’s default lazy sequences also make it easier to explore very large problem spaces. On the other hand if you have problems that can be expressed by state machines or transitions then you might be able to express the solution to a problem very effectively in a Scala case class hierarchy.

When it comes to exploring the capabilities of Java libraries I tend to use the Scala console but for general programming (slide code examples, exploratory programming) I do tend to find myself spending more time in LightTable‘s Instarepl.

When it comes to datastore programming both languages are actually pretty clunky because they devolve handling this down to various third-party libraries. Clojure does pretty well with document databases and key-value stores. Scala is great for interacting with the AWS Java libraries and neither deals particularly well with relational data.

For web programming neither is brilliant but Scala definitely has the edge in terms of mature and full-featured web frameworks. Clojure is definitely more in the log cabin phase of framework support currently.

Standard

20 thoughts on “Horses for courses: choosing Scala or Clojure

  1. ungzd says:

    > For web programming neither is brilliant

    At least better than in plain Java. Especially when using popular but horrible technologies such as JSP.

      • I think the logical first choices for web programming are Ruby and Python along with their mature web frameworks.

        I’m also not someone who hates on PHP although you have to know what you’re doing with that. I realise that some people are going to feel that this is enough to disregard what I have to say but I say look at what has been achieved in PHP versus Scala or Clojure, create great products rather than preach your language.

  2. exim says:

    I know you’re tempting to play with something new – for the sake of fun and maybe you’re bored with your day-to-day job, but please think more deeply – is it worth to switch to dynamically typed language?

    For the sake of fun – you can just do some toy projects, if you really want to try clojure. Bu for the real world project, hell, I’d much prefer 90s raw Java over any “dynamic” language, no matter how cool macros they have…

    • jpn says:

      You can make sure that reflection is never used in clojure (set! *warn-on-reflection* true) and you can use types for example:
      (defn ^Boolean dummy [^String arg1 ^File f](…))

    • I find dynamically typed languages reflect real-world problems far better than limited type-systems. I’ve seen people port Python apps to Scala and the result has been a more complicated solution with more lines of code and no new function.

      If you can’t imagine the utility of a dynamic type system then there’s a whole class of real-world programming problems you either haven’t encountered or haven’t handled very gracefully.

      • exim says:

        I’ve worked with both, quite experienced, I’d say. And engineering systems with static type safety is just easier. I’m not saying that there is no use for dynamic languages – for quick scripts and similar jobs.

        Regarding your statement – “why we should bother to think about types, just leave malleable code” – I’d say, you should start thinking about types in the first place.

      • Here are my thoughts on the issues of “type-first” design in some other posts.

        Cognitive bias and the difficulty of evolving strongly typed solutions

        Intuitive versus Reasoning Programmers

        I regard myself as an Intuitive programmer working in uncertain or poorly understood domains so I prefer dynamic typing. Although as per my talk I think there is more heat than light regarding the idea that dynamic versus static typing is a sensible way to differentiate Clojure and Scala.

    • IntelliJ is a very double-edged sword, I should blog why that it is but essentially IntelliJ allows you to navigate really complicated Java and Scala projects easily and therefore their organisation ends up being really baroque.

  3. naeg says:

    Where can the talk you linked to be watched?

    On Skills Matter it’s not possible (to me). Embedded video just saying that the domain does not have permission to embed it and I can’t find it on Vimeo.

    • Well I’ve only attended a talk by Ambrose Bonnaire-Sergeant rather than used it myself. He’s taking a clever approach to try and add some compile-time verification and it is certainly the code it generates is a lot more attractive than the pre and post-condition brigade. If people are using type-systems as code for IDE assistance I’m not sure Typed Clojure helps but if people want static verification of code then it might be interesting to see if it changes minds.

  4. Pingback: Clojure: Links, News And Resources (17) | Angel "Java" Lopez on Blog

Leave a comment