Over a million developers have joined DZone.

I Wish Ruby Had Interfaces

DZone 's Guide to

I Wish Ruby Had Interfaces

· Performance Zone ·
Free Resource


Types have a bad reputation for making code harder to read, adding unnecessary ceremony, and in general complicating things. In this article I’d like to show that a type system done right can help make code more readable and toolable without constraining the expressiveness of the language. Or in other words, I will show how a type system can allow the flexibility of Ruby and the toolability of Java to coexist in one language.

Documentation for Humans and Machines

First, I want to show how type annotations can be used as documentation for both humans and machines.

Let’s look at this function jQuery.ajax() and just pretend that we are not familiar with it. What kind of information can we get from only its signature?

    jQuery.ajax(url, settings)

The only thing we can tell for sure is that the function takes two arguments. We can guess the types. Maybe the first one is a string and the second one is a configuration hash/object. But it is just a guess and we might be wrong. We have no idea what options go into the settings object (neither their names nor their types) or what this function returns.

There is no way we can call this function without checking the source code or the documentation. Everyone who advocates checking the source code does not understand why we have functions and classes. They can be used without us knowing anything about their implementation. In other words, we should rely on their interfaces, not on their implementation. Which brings us to my first point.

Types help define an interface of a function or a class.

The only option we have is to check the documentation. And in my view, there is nothing wrong in doing that. Except that it takes time.

Now, contrast it with a typed version.

Future ajax(String url, {bool async: true, Function beforeSend, bool cache: true});

It gives us a lot more information.

  • The first argument of this function is a string.
  • The function takes a few options, and we see all of them in the signature. We can see not only their names, but also their types and default values.
  • The function returns an instance of the Future class. And, of course, our tools can show us the public methods of this class.

The typed version gives us enough information to call this function without checking the source code or the documentation.

One might argue that good documentation can convey more information than a type system. Though this is certainly true, types give you much faster feedback. Autocomplete is instant whereas checking documentation takes time. What is more, types serve as documentation for machines enabling such features as structural search and refactoring. Another thing is, not all projects are well documented. Good luck finding any documentation for a 200K-line Rails application, which has been around for many years.

Summing up:

Types are great for defining APIs because they serve as documentation for humans and machines.

Types Provide a Conceptual Framework for the Programmer

A good design is all about well-defined interfaces. And it is much easier to express the idea of an interface in a language that supports them.

For instance, imagine a book-selling application (let’s say a Rails app) where a purchase can be made by either a registered user through the UI or by an external system through some sort of an API.


As you can see, both classes play the role of a purchaser. Despite being extremely important for the application, the notion of a purchaser is not clearly expressed in the code. There is no file named purchaser.rb. And as a result, it is possible for someone modifying the code to miss the fact that this role even exists.

def process_purchase purchaser, details

class User

class ExternalSystem

Can you, by looking at this code, tell what objects can play the role of a purchaser? What methods does this role comprise? We do not know for sure and we will not get much help from our tools.

Now, compare it with a version where we explicitly define the Purchaser interface.

processPurchase(Purchaser purchaser, details){

abstract class Purchaser {
    int id();
    Address address();

class User implements Purchaser {}
class ExternalSystem implements Purchaser {}

The typed version clearly states that we have the Purchaser interface, and the User and ExternalSystem classes implement it. What is more, our tools can see it as well and, as a result, they can help us navigate around. Which brings us to my second point.

Types provide a conceptual framework for the programmer. It is useful for defining interfaces/protocols/roles.

I spend most of my time programming in Ruby and JavaScript, and I find these languages extremely powerful and flexible. But after working on sizeable apps written in these languages, I came to the conclusion that the lack of interfaces pushes developers toward building tightly coupled systems.

In a statically typed language boundaries between subsystems are defined using interfaces. Since Ruby and JavaScript lack interfaces, boundaries are not well expressed in code. Not being able to clearly see the boundaries, developers start depending on concrete types instead of abstract interfaces. And it leads to tight coupling. Please, do not get me wrong. It is still possible to build a decoupled system in JavaScript or Ruby, but it requires a lot of discipline.

Statically Typed Languages?

It may seem that I am advocating statically typed languages, but I am not. The arguments against a mandatory static type system are still sound.

  1. It complicates the language. Writing a mock library in Ruby is an exercise that almost everyone can undertake. Doing similar stuff in Java is far more difficult.
  2. It constrains the expressiveness of the language.
  3. It requires type annotations even when they are not desirable (e.g., in a domain specific language).

What we want is something that combines the power of a dynamically typed language with the benefits of having explicit interfaces and type annotations.

Optional Type Systems

An optional type system is one that has no effect on the runtime and does not require using type annotations. Type annotations are used only during development to help you communicate your intent and get better tooling. They have zero effect on a program’s execution in production.

In other words,

processPurchase(Purchaser p, OrderDetails o){}

is the same as

processPurchase(p, o){}

when it runs in production.

Optional type systems are very forgiving. You do not have to satisfy the type checker (like in Java). Quite the opposite, the type checker is there to help you find typos, search, and refactor. You do not rewrite your program to make the types work. If you are prototyping something, and duck typing works, just do not use types. Use them only when they add value.

It would not be completely fair to say that optional typing is only good stuff without any drawbacks. It still adds some complexity to the language (nothing compared to a mandatory static type system though). Also, to fully see the benefits of such a system you need more sophisticated tools than a plain text editor. However, because of the reasons I outlined at the beginning of this article, I am willing to pay this price.


A common misconception among developers is that a language with optional static typing is “like Java”. On the contrary, it is much closer to Ruby, Smalltalk, or JavaScript. It is a dynamically typed language with a type system built on top to improve the development experience.

If you would like to get your feet wet, I can recommend the following languages.

Modern languages for building web applications:

And a few for Smalltalk fans:

  • Strongtalk - an implementation of Smalltalk with optional static typing.
  • Newspeak - another language in the Smalltalk family.

There are also some languages that do not have optional type systems in the strict sense, but have something similar (for instance, Groovy).

Read More

  • Gilad Bracha is a leading expert in this area. I highly recommend reading his paper on the subject: “Pluggable Type Systems”

  • He is also working on Dart, so you can read his thoughts on Dart’s type system: “Optional Types in Dart”

  • I have been using Dart for some time. If you are interested in this language, you may find these screencasts useful: DartCasts.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}