In mathematics, functions have a domain and a codomain. These are respectively the set of inputs and the set of possible outputs. The function then simply relates an input to an output.

For example, consider the square root function:

A function’s definition is only complete when its domain and codomain[1] are defined.

For such a common function we generally implicitly assume that the domain and codomain are the set of nonnegative real numbers:

You could, however, change the function by simply extending the domain to all real numbers, which would require you to define the codomain as the set of complex numbers:

This function can then relate, say, -1 to i.

When it comes to programming, things are not much different.[2] In most languages, we still call them functions, and they still relate an input to an output (after some computation).[3]

Much like in mathematics, the input doesn’t necessarily have to be a number and can often be a composite data type, a list of arguments, or even other functions (in the case of higher-order functions, for example).

Domain and Codomain Defined via Type Signature

As far as most mainstream programming languages go, the parallels essentially stop there. In fact, most languages fail to provide us with built-in features to completely define the function by specifying its domain and codomain. And I would argue that we are missing out.

Statically typed programming languages partially offer a way to define the domain and codomain of a function, by specifying the parameters and return value types. Take the Sqrt method definition in C#:

public static double Sqrt(double x)
{
  //...
}

An exception will occur if the argument passed to the function is not a double (or can’t be cast into a double). The same goes for the return value.

This type signature provides a basic element of safety. It ensures that we are actually passing a number to the function, instead of, say, null by mistake. It also ensures that we are returning a value in the first place and that the function’s return value is of the double type.

We essentially narrowed down[4] our domain and codomain to:

Amusingly, if we call Math.Sqrt(-9) in C#, the function will not raise an exception because both the argument and the return values fit the type declaration.

In fact, the function would return Double.NaN, which is the result of an undefined operation, but still technically a double. Other languages will handle the situation differently.[5]

A significant number of software bugs are caused by programmer expectations being silently violated. Wouldn’t it be nice if we could use a feature to easily specify fine-tuned conditions on the acceptable input and output values like we do in mathematics?

For instance, ensuring that an error is automatically raised at runtime if the return value of the square root function isn’t a nonnegative number?

Preconditions and Postconditions

While developing the Eiffel programming language, Prof. Bertrand Meyer came up with the idea of Design by contract (DbC). Two key concepts of this software methodology are preconditions and postconditions, which are enforced integrity checks on specified input and output values, respectively.

Preconditions are slowly becoming more common. For example, Elixir has guard expressions, which allow us to limit the set of values the function will accept:

defmodule Math do
  def sqrt(x) when x >= 0 do
    :math.sqrt(x)
  end
end

IO.puts Math.sqrt(9)    # Prints 3
IO.puts Math.sqrt(-9)   # Raises a FunctionClauseError

Notice how an error is raised when we are trying to call the function with an input outside of the domain specified by the guard.

Guard expressions in named functions were introduced in Elixir in order to fully flesh out its powerful pattern matching capabilities.[6] Nevertheless, they act as preconditions that enable us to define the domain of the function.

To enforce checks on return values we need postconditions. For this example, I’ll use Clojure since it provides both preconditions and postconditions:

(defn limited-sqrt [x]
    {:pre  [(pos? x)]
     :post [(>= % 0), (< % 10)]}
    (Math/sqrt x))

(limited-sqrt 9)   ;; 3.0
(limited-sqrt -9)  ;; AssertionError Assert failed: (pos? x)
(limited-sqrt 144) ;; AssertionError Assert failed: (< % 10)

I intentionally made the example contrived by limiting the function codomain to values between 0 and 10, to demonstrate how postconditions are also caught at runtime (line 8).

Extended Static Checking

Some programming languages take the concept further by introducing verifying compilers that check the mathematical correctness and adherence to the formal specification.

The compiler will essentially take care of traversing all possible branches to determine whether the range of values the program could calculate meets the specification for the given function.

Creating such a compiler for an existing language is extremely hard. We are always contending with the halting problem. It is possible, however, to design languages specifically with that aim in mind.

Whiley is one such language for the JVM.

Consider this example:

import whiley.lang.System

function max(int x, int y) -> (int z)
ensures x == z || y == z
ensures x <= z && y <= z:
    if x > y:
        return x
    else:
        return y

method main(System.Console console):
    console.out.println(max(4, 10))

Whiley’s compiler will verify that x, y, and z meet the conditions indicated in the specification (on lines 4 and 5). Namely, that the returned value is either of the two arguments and that both of them are less than or equal to it.

If we create a faulty version of the algorithm as shown below, we’ll catch the error before even running the program:

import whiley.lang.System

// Bad implementation
function max(int x, int y) -> (int z)
ensures x == z || y == z
ensures x <= z && y <= z:
    if x > y:
        return y
    else:
        return x

method main(System.Console console):
    console.out.println(max(4, 10))

In fact, although max(4, 10) does not enter the if branch, the compiler determines that there are inputs for which that return y would not satisfy the highlighted postcondition.

True enough if you consider max(3, 2) for a moment. x (3) > y (2), so in this faulty implementation, we return z (2). However, x (3) is not less than or equal to z (2), so the postcondition fails.

Whiley is an extreme case of course, and as discussed, its verifying compiler is a virtually intractable problem for regular programming languages which were not specifically designed for it. Nevertheless, I wanted to show you how far this powerful concept can be pushed.

Conclusion

I would love to see pre and postconditions become built-in features of more mainstream programming languages.

Especially since many mainstream programming languages don’t offer referential transparency. Side effects caused by mutable data structures and having to account for state mean that we have even less predictability about return values than in purely functional programming languages.

As shown by Elixir, Clojure, and even Whiley, adding such specifications doesn’t require any significant syntactic overhead either.

With dynamically typed programming languages we stress the importance of having tests because we don’t have a compiler to catch as many of our mistakes. (Though testing is key either way.)

Pre and postconditions add a complementary layer of safety, regardless of the language’s typing system. By using both Design by Contract principles and testing, we can build more robust software. (Definitely check out other features of DbC as well, including class invariants. There are lots of good ideas in there.)

If you’d like to get started, you can probably find a library for your favorite language. If not, creating your own should be fairly easy.

However, I’d advocate for such conditions/assertions to be a core part of most languages. And that’s because of the difference in the adoption rate of opt-in vs opt-out features.

With pre and postconditions built into the language, documented in the intro tutorial that everyone reads, you’ll cultivate a community with a penchant for defensive programming, who will actually make use of the feature.

The post In Praise of Function Pre and Postconditions appeared first on Programming Zen.

During a meeting with a few high-profile engineers, I presented what Ruby brought to the table. An IBM Distinguished Engineer[2] stopped me in my tracks and said, “It sounds slow”.

I love Ruby as much as a programmer can possibly love a programming language, but that engineer’s conjecture was right on the money. Ruby’s emphasis has always been on programmer efficiency, not execution efficiency.

Generally speaking, Ruby programs are significantly slower than equivalent programs in C or Java.

A lot of work has been done to improve Ruby’s performance, with a good degree of success, and that’s terrific – but is it enough in today’s world?

In many ways, yes. You’re not going to employ Ruby to calculate 13 trillion digits of Pi, nor will you use it to power the backend of a messaging app with millions of users.

However, Ruby will suit most scripts just fine. Further, I would argue that Rails still gives you the best bang for your buck in terms of web frameworks, when it comes to a large subset of CRUD-based web applications.

Ruby is lovely and has many uses, however, what Ruby is not, is the language that will define the next ten years. As beautifully designed as it is, it simply isn’t the ideal language to tackle the challenges that an increasingly distributed world throws at us.

Concurrency is the name of the game, and Ruby is, for the most part, limited in its ability to cope with it (despite valuable efforts). It’s not that you can’t do concurrency in Ruby, it’s that there are much better, battle-tested tools to do so.

If you are a fellow Ruby developer who would like to remain relevant in the next decade, I highly suggest that you start looking for something new to pair to Ruby as your main language. (Though, fair warning, you might end up replacing Ruby with it.)

Your main language for the next ten years will be highly dependent on the development context, of course. If you develop iOS apps, Swift is such a language. Android apps? Kotlin is looking good and might have a shot at that. Data Science? Julia, if they can sort out a few performance issues, could get the edge over Python and R. System programming? Rust and Go will be worth a close look, too.[3]

I’m enough of a generalist to dabble in many programming domains, but above all, I’m a web developer, so my main language for the next decade will have to excel in distributed environments where n machines make m requests, for large values of n and m (e.g., IoT alone enables this scenario).

So what comes after Ruby? Some people might argue that it’s Node.js. Not for me personally, though. I’m afraid Ruby has spoiled me. I find Ruby to be a joy to use. JavaScript, not so much.

We are looking for a high-level language that can handle concurrency like a champ, has an elegant, highly readable syntax, provides a great user experience for the developer, and… is functional. In short, fun and functional. 🙂

I find functional programming (with immutable data types) to be a significantly better approach to thinking about most problems, and modeling solutions for them, than Object Oriented programming.[4] I blame my past dabbling with Haskell and Clojure for this.

Speaking of Clojure, on the JVM, both Scala (w/ Akka), and Clojure (w/ STM & Pulsar) are valid options.

Of the two, Clojure is the one that comes closer to a great fit for me. Very close. Unfortunately, I’m somewhat of an aesthete, and coming from Ruby, the Lisp syntax still feels like a downgrade.[5]

Further, the JVM is great, but when it comes to dependable concurrency, you really can’t beat what the Erlang VM (i.e., BEAM) has to offer (ask the team at Whatsapp).

The problem with Erlang is that its Prolog-like syntax feels obsolete. I have never seen an Erlang program and said to myself, “Wow, that was a joy to read”. Or refactor. It’s not the worst, but I personally find it to be a fairly uninspiring language to work with.

Thankfully Erlang is not the only language for its highly fault-tolerant and concurrent VM. There is indeed a language worth getting excited about.

For me, that language is Elixir. Elixir fits all the requirements above and feels like a joy to both read and use.

Like many other Rubyists, when I first found Elixir I thought of it as Ruby for the Erlang VM, due to its largely familiar syntax. But it turns out to be so much more than that. In fact, it’s much more than Erlang as well.

To hastily summarize, we get:

• A highly readable, elegant, concurrent, functional programming language.
• The fantastic Erlang VM (i.e., BEAM) and OTP integration.
• Shared nothing Actor-based concurrency.
• Metaprogramming via macros.
• Polymorphism via protocols.
• A whole host of other nice features (pipeline operator, pattern matching, docstrings, streams, mix, etc).
• An excellent web framework called Phoenix.
• A fast growing supportive community, that it’s reminiscent of Ruby during the early days of Rails.

Ruby’s usage skyrocketed in the past decade and I would argue that Elixir, though not widely adopted as of yet, is well equipped to do the same in the coming ten years.

Give it a try and let me know how you like it.

The post A Language for the Next 10 Years appeared first on Programming Zen.