Scala Does a Bad Job of Telling Its Story

EDIT: I just saw Martin Odersky’s very good talk at Scala Days 2016 (see here) and I take back everything. Scala does do a pretty good of telling it’s story. Below is my original post unchanged:

Oh man, it’s a been a while. I’ve been super busy and I don’t see that changing any time soon. I do want to be more regular with this posts but I don’t think I’m going to be able to do that just quite yet. I want to eventually get to a point where I can release these bi-weekly or at least monthly.

So today’s video is about Scala. These are just my current thoughts about the language and how I think about it. I feel like this way of thinking about it has made me more comfortable with the language. I hope it’s helpful to other Scala users out there!

Coding With Stella

Check it out a new video’s up:

This video is definitely something new for me but it was a lot of fun and I hope to do more videos like this in the future. (One more should be coming up soon-ish.)

But don’t take that the wrong way. This is still a serious programming blog and most of the upcoming posts I have planned are all pretty technical and heavy. And that’s the way I like it. 🙂

Singleton Objects in Scala

I’ve been using Scala at work lately and one of its strangest features has been the ability to create singletons with the “object” keyword. This is considered a “beginner” feature but it I’m struggling to feel totally comfortable with it. I think the reason that it feels so unnatural is that this single feature packs in several unrelated concepts. Let’s try to get some clarity on this by breaking this feature down a bit.

So what does the “object” keyword even do? Let’s look at a simple example:

This code has the following effects: It creates an underlying type for the singleton called MyObject.type (which contains SomeField and SomeMethod). And it makes the value MyObject available in the current package. Objects are not instantiated until they are used, so the following is okay:

But this would cause your program to crash:

Since this is just a language-supported implementation of the singleton pattern, all the benefits that singletons have over static methods and classes also hold here. You can pass around variables that point to the singleton and you can use it as the argument and return type of a method. (This is also where the object.type underlying type comes into play.) You can also inherit from base classes and implement traits as you would a normal class, though extending objects is not allowed.

Objects can also be “companions” to classes. That is, if an object and class with the same name are defined in the same source file then they are companions to each other. The object is the “companion object” of a class and the class is the “companion class” of the object.

The companion object can be used as a place where you can put functionality that’s related to a class but isn’t directly tied to any particular instance. Things you would make static in other languages would go here, as would things like factories.

But this is more than just a coding convention, companion objects and classes actually have access to each other’s private fields:

So all this above explains the what of this feature, but what about the why?

The more I look at it the more it feels not-quite-right. I haven’t used Scala that much so it could be that this is something that will grow on me, but I don’t think the issue is unfamiliarity.

As far as I can tell things turned out this way because of two competing goals the language designers set for themselves:

  1. To be a pure object oriented language.
  2. To be compatible with Java.

By pure OO, I don’t mean only OO, of course blending OO and functional programming is like the whole point of Scala. This quote from Programming in Scala (2nd ed, pg 56), which is authored by Scala’s creators, explains it:

For instance, many languages admit values that are not objects, such as the primitive values in Java. Or they allow static fields and methods that are not members of any object. These deviations from the pure idea of object-oriented programming look quite harmless at first, but they have an annoying tendency to complicate things and limit scalability.

By contrast, Scala is an object-oriented language in pure form: every value is an object and every operation is a method call.

I can appreciate the thinking behind that but the problem is that Java does have static members. So you get into this situation where you have to take your pure building blocks and build something that imitates the impure. (Kind of like how pure FP languages have to imitate side-effects.)

So with these competing goals they eventually landed on this singleton / companion object solution. And I’m sure lots of thought went into it and that the people behind Scala are all brilliant but as an end user of the language this feature just feels off to me. More specifically:

  • Singletons as a language feature – Cool, makes perfect sense.
  • Companion objects to store misc. functionality – It’s okay but could potentially go against single-responsibility principle.
  • Companions having access to each other’s private data – Seems to be breaking encapsulation. If they’re in the same file, why should they separate things in the first place?

So it’s not a complete disaster or anything, it’s just kind of imperfect. IMO allowing static into the language and giving up on purity would have been the better way to go, but hey, I’m sitting here struggling with “beginner” features, so what do I know?

Tinder UI Automation

I’ve been looking into Android UI automation for my thesis project and I found this be a good project to gently explore this area.

You can check out the repo on GitHub here.

Static vs Dynamic Typing

This is a summary of arguments and counterarguments I’ve heard in the classic static vs dynamic typing debate. Overall I think this debate doesn’t make a lot of sense. As usual when you’re confronted with a question of X vs Y, the answer is “it depends”.


This is probably true but…

Dynamic languages are more concise.

Type inference and other language constructs can reduce verbosity.

Compile-time type safety catches errors the programmer missed.

These can be caught with unit tests, and there’s a lot of other things that can go wrong with your program that the compiler can’t catch.

Static languages are more performant.

You can always just scale your hardware and there are plenty of examples of dynamically typed code that’s highly performant.

Dynamic languages let you rapidly prototype, try out new things, fail faster, and build things more quickly.

You can still move reasonably fast with the right expertise, and it may be that moving fast is a lower priority than long-term maintenance.

Statically typed code bases are more maintainable in the long run because types serve as documentation and allow for better tool support.

You can get around this with good design, and it may be that moving fast is a bigger priority than long-term maintenance.

Dynamic languages are simpler to work with. You don’t have to worry about pleasing the compiler so you can just work on your actual problem.

For more sophisticated type systems, the compiler can actually help you prove the correctness of your code.

More sophisticated static type systems like Haskell’s and Ocaml’s actually give you the malleability of dynamic typing without giving up safety.

The complexity burden for developers is much higher.

Other points:

  • You can always build tools to make up for what you lack (like linters).
  • Gradual typing exists, as does the ability to have optional dynamic typing is static languages so it’s not necessarily one or the other.
  • These categories ignore all the nuances within individual languages (i.e. JavaScript vs Python or C++ vs C#) 

Basically the bottom line is that there isn’t a clear winner. There are pros and cons. You have to weigh them out and pick the languages that work best for you and that may even mean a mix of both kinds of languages. There’s no one exact right answer here and that’s part of the fun.