Scalar 2014

Last weekend I attended Scalar, a Scala conference in Central Europe. It's the first Scala conference in Poland. It was a great time full of inspiration.

The talks were 30-min long which I think was a good decision. Even though there was just a single track, you could really enjoy a great variety of topics. It's very impressive, because the shorter the talk, the more difficult it is to make it good. Both the organizers and the speakers did a great job.

It was definitely worth to spend more than 12 hours on travelling to attend Scalar. Kudos to Softwaremill for organizing this wonderful event. Below are my afterthoughts regarding some of the talks I attended.

The dark side of Scala

An excellent one! Scala is a great language, but I think we cannot be blind to the pitfalls. The presentation pointed out some of them. I was especially happy to finally hear somebody openly comparing this kind of pattern matching:

account match {  
  case trial: TrialAccount => ...
  case regular: RegularAccount => ...
  case premium: PremiumAccount => ...
}

to something like the following in Java:

if (account instanceof TrialAccount) {  
  TrialAccount trial = (TrialAccount) account;
  ...
} else if (account instanceof RegularAccount) {
  RegularAccount regular = (RegularAccount) account;
  ...
} else if (account instanceof PremiumAccount) {
  PremiumAccount premium = (PremiumAccount) account;
  ...
}

We would never code like that, right? It's definitely an antipattern -- the better way would be to use OOP techniques based on polymorfic method invocation. The point is, the first snippet is the same kind of bad design decision as the latter. The fact it looks much nicer makes it even worse -- it might be tempting to go that way and overuse it.

Actually, Martin Odersky commented this issue in an interview once:

So the right tool for the job really depends on which direction you want to extend. If you want to extend with new data, you pick the classical object-oriented approach with virtual methods. If you want to keep the data fixed and extend with new operations, then patterns are a much better fit.

That's it. For some cases it might be good to use the mentioned kind of pattern matching, but for sure it's not a full-fledged replacement of OOP.

Event sourcing with akka-persistence

An overview of Akka Persistence. I had known the concepts before (from Principles of reactive programming), but it was very good to refresh it. And by the way, I learned there is a new book about DDD -- definitely will have to take a look on it.

Doing Crazy Algebra with Scala Types

I loved this talk. The introduction was a masterpiece -- very amusing. The rest was extremely abstract. It reminded me my courses of algebra at the university. The good summary of this presentation is to say that a result of differentiating a Scala type (sic!) may have some practical interpretation! It's not kind of stuff you would use in your daily work, but I consider it an excellent, instructive excercise. I was proud I followed it, because the pace was quite challenging.

Simple, fast & agile REST with Spray.io

I once had taken a look on Spray and not liked it. After this presentation I decided to give it another try. A very good talk with a lot of live coding. I'm always impressed by the speakers who effectively build working examples during a presentation.

ScalaJS and ReactJS

Interesting stuff, but I felt being thrown in at the deep end. It's a good inspiration to take a closer look on ScalaJS and ReacJS later on, though.

Scalaz — the good, the bad and the ugly

The presenter for sure has working knowledge about Scala and Scalaz. I liked the presentation -- it's always great to hear from someone about solutions they use in real projects. Unfortunately I still don't get how the validation with Scalaz, which was considered the good part, is better than collecting errors in a simple list. Not to mention approaches like Bean Validation in Java. Scalaz-based solution seemes just overcomplicated to me.

Lambda implementation in Scala 2.11 and Java 8

Very good explanation of the differences between the implementaion of lambdas in Scala and Java 8. If you are wondering what that difference is, I encourage you to use javap and decompile the simplest lambda code compiled with scalac and javac.

The presenter explained JVM invokedynamic opcode a bit (I liked the comparison to macros). Long story short: it allows JVM to generate an anonymous class (that implements the lambda) at runtime (as oposed to generating it during the compilation phase). This approach enables future improvements without breaking the backward-compatibility.


comments powered by Disqus