In the following example, we take a list of integers and pass it to the Enum.uniq/1 function which removes duplicates from the list without altering the original order of the remaining elements.

list = [1, 2, 2, 3, 3, 1, 2, 4]
Enum.uniq(list) # Returns [1, 2, 3, 4]

If you are trying to only remove consecutive duplicate elements, then there is Enum.dedup/1:

list = [1, 2, 2, 3, 3, 1, 2, 4]
Enum.dedup(list) # Returns [1, 2, 3, 1, 2, 4]

(Note: We append /1 simply as a notation indicating the arity of a function, that is how many arguments it accepts. my_func/1 accepts one argument, my_func/2 two, and so on.)

Enum is full of helpful functions when working with collection data types that implement the Enumerable protocol (e.g., lists, maps, ranges, streams, etc.) and it’s worth getting acquainted with.

Removing duplicates using recursion

Alright, Elixir does the heavy lifting for us in this case, but how would we go about removing duplicates from a list in Elixir without using Enum.uniq/1? I mean from scratch, simply using recursion without relying on Enum, sets, :lists.usort/1, etc.

It is worth asking such a question to both exercise our recursion muscle (something that doesn’t come naturally to most programmers) and so that we’re ready to handle conceptually similar problems that do not have pre-made functions but could benefit from a recursive solution.

There are likely a few ways to implement this, but this what sprang to mind when I thought about it:

defmodule MyList do
  def uniq([]), do: []

  def uniq([head | tail]) do
    [head | for(x <- uniq(tail), x != head, do: x)]
  end
end

Calling MyList.uniq(list) will then return the same list without duplicates as Enum.uniq(list)did. (Although, it’s worth noting, that we implemented a List-specific version of the uniq/1 function).

Let’s see how this works. If the list is empty (i.e., []) we obviously return an empty list, as there is nothing to remove. This is our base case for the recursion.

If the list is not empty, it will have a head and a tail, and we use Elixir’s pattern matching to bind the first element of the list passed to the function to head and the rest of the elements to the list tail.

Note that a proper list with a single element will simply have an empty list as its tail. So writing [3] is equivalent to writing [3|[]] where 3 is the head, [] is the tail, and | is the cons operator (short for constructor operator, as it’s used to construct lists).

So far so good. Here is where things get a little trickier. Let’s analyze this line:

    [head | for(x <- uniq(tail), x != head, do: x)]

The code is wrapped in square brackets [...]which means that we are returning a list. Then you’ll notice the | cons operator. So we are constructing a list that has head as its first element and whatever the rest of that line of code does, as its tail.

This makes sense if you think about it. Sure, the list might have duplicates, but the first element will always be included. If a duplicate of the first element exists, that’s the one that is going to be removed and not the first element.

So we are building a list and the first element of the original list is also the first element of our deduplicated list. What goes into the rest of the list?

Comprehensions

We see a for. Unlike many programming languages, for is not a loop keyword in Elixir. Rather, it is used for comprehensions (a form of syntax sugar to generate lists from existing collections). Syntax, which is not too different from mathematical notation.

Here is a simple example of how to use them:

for x <- [1, 2, 3, 4], do: x + x # Returns [2, 4, 6, 8]

“For each element x in [1, 2, 3, 4] do x + x and put the result in a list.”

It also accepts filters, which allows us to specify a condition:

for x <- [1, 2, 3, 4], x < 3, do: x + x # Returns [2, 4]

In this example, the condition is that x is smaller than 3, so only the first two elements, which are lesser than 3, get doubled and added to the resulting list.

Recursing our way to the base case

OK, back to our “cryptic” line:

    [head | for(x <- uniq(tail), x != head, do: x)]

head is our first element and then we are using a comprehension to generate a list without duplicates.

We are saying, for each x in a deduplicated tail, add x to the list if it’s different from our first element head.

The part that gets people weirded out about is recursively calling uniq(tail). We can get away with this because we have a base case that ensures we don’t recurse forever.

At each call of uniq(tail) we are making the tail shorter by one element.

For example, executing MyList.uniq([1, 2, 3, 3]) will make the following recursive calls:

• MyList.uniq([1, 2, 3, 3])
• MyList.uniq([2, 3, 3])
• MyList.uniq([3, 3])
• MyList.uniq([3])
• MyList.uniq([])

When we eventually get to the tail being [], which is our base case,[] is returned and MyList.uniq/1 is no longer called.

Recursion can be hard to grasp at first, but it’s a powerful tool and a staple of functional programming, so it’s well worth practicing.

As pointed out in the comment section, this implementation is quite illustrative but not very efficient. In production, you’d want to opt for the built-in functions or implement a tail-recursive version that leverages MapSet. And although tail recursion is faster in this case, it’s worth noting that even that is not a silver bullet.

The post Removing Duplicates From a List in Elixir appeared first on Programming Zen.

You’ll need to edit your config/dev.exs configuration file to change the host key as follows:

http: [port: System.get_env("PORT", "4000")],

System.get_env("PORT", "4000") retrieves the value of the PORT environment variable if one has been set. If the environment doesn’t have the specified variable (i.e., PORT), it will default to 4000.

You can then boot your Phoenix server by passing the variable value to the command as follows:

$ PORT=5000 mix phx.server

This will run the server on the port you specified, in this example 5000.

The name of the environment variable is arbitrary. We used PORT but we could have opted for PHX_PORT or something else altogether. Just so long as your configuration file and environment use the same name.

You can, of course, set the environment variable outside of the mix phx.server command, for example in your shell profile.

The post Specify a Port when Booting a Phoenix Application appeared first on Programming Zen.

I can appreciate the usefulness of Python, the simplicity of Go, and the mind-expanding nature of Haskell. Yet, anything that isn’t Ruby felt like a usability downgrade. It’s all highly subjective, ça va sans dire, but Ruby was always my favorite.

It’s not every day that a language comes along and genuinely excites me to the point of putting Ruby aside (within the scope of what it’s great at doing).

I <3 Elixir

That language is Elixir. I’ve been using it on and off for a few years now. I first talked about it back in 2016 and even managed to convince my team at IBM to adopt it to an extent. It’s working out well for us so far and I have a hunch we might double down on it soon.

Since I have a little more time, due to being stuck inside, I’ve been on a “study anything in sight related to Elixir and Phoenix” kick lately.

I am a big fan of Mike and Nicole Clark of The Pragmatic Studio and in the past have highly recommended their Ruby and Rails courses. So I decided to start taking their Elixir courses as well. In this post, I’ll give you a fairly detailed review of their largest course on the subject, Developing with Elixir/OTP.

Who is it for?

Developing with Elixir/OTP is aimed at programmers. It’s so well explained that beginners can give it a shot, however, they are not the target audience.

The course assumes you have zero knowledge of Elixir itself but it’s not going to explain basic programming concepts when they are not novel or unique to Elixir.

Experience with Ruby is not required nor assumed, but it’s beneficial. This isn’t so much due to the way the course is presented (though there are a couple of nods to Ruby programmers). Rather, it’s the similarity (on the surface) between the two languages.

How much time do you need to invest?

Developing with Elixir/OTP is a 6.5 hour course divided across 30 modules. There is no way for you to take this course in 6.5 hours and get anything worthwhile from it.

In fact, the secret sauce is that each module has a Notes section dedicated to expanding on the topic, providing tips and tricks, as well as exercises. 

I would estimate that it took me around 20 hours or so to finish, despite being very familiar with the subject matter. Mind you, I do like to experiment quite a bit within IEx to veer off the beaten path.

Estimate 30 hours of your time, an hour per module, if you intend to fully absorb and experiment with the material presented.

Unlike their Rails course, you won’t develop two applications (one while watching the videos and one in the Notes section). In this course, there is only one application that is mostly developed in the videos and then enhanced in the Notes through exercises.

This will save you a lot of time at the small expense of having to pause and resume the video to type along.

Another time-saver is that the code for each module in the course is provided so that you’re never lost. Particularly useful to copy and paste the more tedious parts (e.g., sample data and template code).

What will you build?

The course starts off by developing a simple web server. Think, high-level transformations of requests into responses. It builds it from the ground up and then layers a simple RESTful API for a fictitious wildlife reserve on top.

They start off with the simplest thing, a function that transforms one specific request into one specific response, and then move up all the way to actually serving the API over HTTP.

The goal, as often stated in the course, is not to replace an established and much more robust web server like Cowboy or a framework like Phoenix. At all.

Instead, it serves two pedagogical purposes. First, it teaches you how to use the language to solve a fairly complex problem. Second, it gives you a deeper understanding of how the production-ready tools you are going to adopt actually work within.

This approach is endemic to their teaching method. For example, they’ll develop a simple web server and API from scratch and then show you how similar it is to the equivalent Phoenix version. By the time you hit module 17 on Phoenix, you don’t quite know Phoenix but it should feel oddly familiar. After all, you built a naïve/simplified version of the same controllers, router, templates, etc. from scratch. This is, of course, a deliberate choice.

The same is true when they implement a simple GenServer from scratch and then are able to seamlessly replace it with the real deal (with use GenServer). Yes, you developed the Fisher-Price version of the production-ready tools, but you now understand how they work under the hood. All before Mike and Nicole proceed to teach you how to use the battle-tested ones.

I’m a fan of this didactic approach and I think it will serve most people well.

What will you learn?

It might be surprising to some but this course does not provide the typical tour of data types and data structures available in the language.

Instead, it uses the language to build something from the beginning and, in the process, it quickly exposes you to a variety of concepts, including how to use common data types.

It doesn’t cover them thoroughly, however, so reading the Elixir tutorial on the official site would be very beneficial prior to or after taking this course.

The course starts off with several modules that are heavily focused on pattern matching. This is a good choice because pattern matching is one of the most valuable and pervasive features of Elixir.

As you would expect, there is also quite a bit of emphasis on immutable data structures, the pipe operator, recursion, and the Enum module.

In the process you’ll also learn a lot about IEx, Mix, organizing your code in a logical and idiomatic manner, defining Structs as the safer alternatives to maps, and comprehensions. 

Testing is covered adequately but not extensively in its own module. Not in a TDD manner from the very start of the course like they did in some of their previous courses. This has, again, didactical advantages even if you choose to adopt TDD in your actual work.

In the second half of the course, things get a little more serious courtesy of OTP, delving deeper into working with sockets, the actor model, Task, GenServer, and linking and monitoring processes.

Other points worth making

In more or less random order:

• The course is up to date to Elixir 1.10.x, somewhat rare among Elixir courses. Some of the videos show Mike and Nicole using a previous version (i.e., 1.5), but the Notes use the latest version and the rare differences are noted.  For example, the video shows the old mix new project format which included a config folder. In their hands-on notes for the video, they have a comprehensive “I don’t see a config directory” section to address it. You’re basically never lost or confused due to version discrepancies.
• The overall quality is excellent. It’s a really polished product in terms of audio, video, text, and visuals used to aid in explaining the more conceptual parts.
• They answer the overwhelming majority of your “wait a second” questions and objections. Either later in the video or right in the notes for that particular module. They genuinely anticipate most questions, which is the hallmark of a great course.
• Most modules have a single 5-15 minute video, but some modules include two videos. So the modules are… well, modular.
• Although this course will equip you to start studying Phoenix, it doesn’t really cover the subject. There is a module, as I mentioned, which is just enough to whet your appetite for the framework.
• Erlang interoperability is at least in part addressed in module 20, where sample code from the documentation of gen_tcp is converted from Erlang to Elixir code.
• The course is full of small tips like enabling command history in IEx (with export ERL_AFLAGS="-kernel shell_history enabled"), speeding up unit tests by making them asynchronous (i.e., use ExUnit.Case, async: true), using flush() to clear a process’ mailbox, etc.

Is it worth the price?

At $89, Developing with Elixir/OTP is not your average Udemy course that’s routinely discounted to $12. That’s because it’s not your average course.

If I had to rate it, I’d give it a 4.5 out of 5. I highly recommend it to working programmers who are interested in picking up Elixir quickly.

I would argue that it’s a great, current resource that is well worth the price of admission if you favor learning from videos.

The post Developing with Elixir/OTP Course Review appeared first on Programming Zen.

Simple enough, but there is more than meets the eye.

Elixir String Length

In Elixir, you can return the number of characters in a string with the String.length/1 function:

String.length("Antonio") # 7
String.length("")        # 0
String.length("résumé")  # 6

Discussion

In the case of a string like, "Antonio", there isn’t much to discuss. String.length("Antonio") returns the number of characters in the string.

The string clearly has 7 characters and since each character in this particular string can be represented with a single byte, its raw representation is 7 bytes as well.

Things become more interesting when a string contains special characters.

Consider the string, "résumé". In this case, String.length/1 returns 6. You can think of this as the number of “visible” or “user-perceived” characters in the string. However, let’s investigate its raw representation:

iex(2)> i "résumé"
Term
  "résumé"
Data type
  BitString
Byte size
  8
Description
  This is a string: a UTF-8 encoded binary. It's printed surrounded by
  "double quotes" because all UTF-8 encoded code points in it are printable.
Raw representation
  <<114, 195, 169, 115, 117, 109, 195, 169>>
Reference modules
  String, :binary
Implemented protocols
  Collectable, IEx.Info, Inspect, List.Chars, String.Chars

You’ll notice that the string’s actual data type is BitString. Specifically, this binary is made up of 8 bytes, even though there are only 6 user-perceived characters. This is because it takes 2 bytes to represent its accented é characters.

If you are interested in the number of bytes within a string, instead of its length, you can use the Kernel.byte_size/1 function:

iex(3)> string = "résumé"
"résumé"

iex(4)> String.length(string)
6

iex(5)> byte_size(string)
8

From a performance standpoint, it’s worth noting that Kernel.byte_size/1 is more efficient than String.length/1. Unlike the latter, which takes longer as the string grows, Kernel.byte_size/1 will return in constant time.

Strings in Elixir are UTF-8 encoded binaries. You can think of them as collections of code points. A code point is a Unicode character, whose underlying representation might require one or more bytes. For example, the é characters in the string "résumé" are code points whose representation requires two bytes each.

The Unicode standard also defines some special characters as the combination of other characters. In other words, even though they appear to the reader as a single character, they are in fact a combination of two or more code points. These are known as grapheme clusters.

For example, the e-acute letter can be represented as a single code point as we’ve done so far (this is also known as a precomposed character) or as a combination of two code points (the letter e and a combining acute accent). These look the same but they are technically two different characters as far as Elixir is concerned; so the two strings below end up representing two different binaries:

iex(6)> "é" == "é"
false

When working with strings, you’ll often want to consider them in terms of the user-perceived characters, rather than their code points or the binary they actually represent.

To help us out, the Elixir String module provides us with String.graphemes/1 which returns a list of characters, without splitting grapheme clusters into the underlying code points. If you need the codepoints, you can always use String.codepoints/1.

To see the distinction between code points and graphemes in action, consider the following string (using the grapheme cluster built from two code points):

iex(7)> String.codepoints("cliché")
["c", "l", "i", "c", "h", "e", "́"]

iex(8)> String.graphemes("cliché")
["c", "l", "i", "c", "h", "é"]

As you can see, String.codepoints/1 shows us a list of code points in the string, and the special e-acute gets split into two code points. If you look closely, you’ll notice the accent as the last code point in the list.

String.graphemes/1 simply returns the list of graphemes and is the closest thing that we have to a function that provides a list of user-perceived characters.

Now, consider its length and byte size:

ie(9)> String.length("cliché")
6

iex(10)> byte_size("cliché")
8

String.length/1 returns 6, the number of user-perceived characters in the string. Kernel.byte_size/1 returns 8 because it takes 3 bytes to represent the special character/grapheme (1 for the letter e, and 2 for the combining acute accent).

We used the expression “visible” or “user-perceived” characters to give us an intuitive understanding. Now that you know more about bytes, code points, and graphemes, we can be a little more precise and say that String.length/1 returns the number of graphemes in a string.

Finally, if you wanted to know the number of codepoints, you could trivially compose the Kernel.length/1 function and the String.codepoints/1 function:

"cliché"
  |> String.codepoints()
  |> length()

Note that if you are trying this in IEx, you’ll need to use the backslash character to continue on new lines:

iex(11)> "cliché" \
...(11)> |> String.codepoints() \
...(11)> |> length()
7

So in summary, our string contains 6 graphemes, 7 code points, and 8 bytes.

The post String Length in Elixir appeared first on Programming Zen.

As you likely know, a Hello World is a very simple program that displays the phrase, Hello, World!

Our Elixir Hello World might not be too exciting but it will allow us to discuss quite a few fundamental concepts.

Hello World in Elixir

As you might expect, this is very straightforward:

IO.puts("Hello, World!")

How to run it

The easiest way to run this line of code is to launch IEx (i.e., Interactive Elixir). This will also act as a sanity test to ensure that you have installed Elixir correctly on your machine.

$ iex
Erlang/OTP 22 [erts-10.4.4] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe] [dtrace]

Interactive Elixir (1.9.1) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> 

For the best experience on Windows, including tab-based autocompletion in IEx, it’s worth passing the --werl flag to IEx or permanently enabling it by setting the environment variable IEX_WITH_WERL to true.

C:\> iex --werl

Once you type your Elixir Hello World and press enter, IEx will print out the message Hello, World! and then display the return value of the function, which is the atom :ok¹ (indicating that the function executed successfully):

iex(2)> IO.puts("Hello, World!")
Hello, World!
:ok
iex(3)>

Alternatively, you could place our one-liner in a hello.exs file and execute it as a script:

$ elixir hello.exs
Hello, World!

You could also create a whole (Mix) project for this, but arguably that is overkill for our humble Hello World.

Discussion

puts is a function that prints a message and adds a newline character. write is the variant that does the same but doesn’t append a newline. They both belong to the IO module, a module that includes, as the name implies, various functions for handling input and output.

At any time, we can learn more about a function by using the h helper within IEx:

iex(3)> h IO.puts

                        def puts(device \\ :stdio, item)

  @spec puts(device(), chardata() | String.Chars.t()) :: :ok

Writes item to the given device, similar to write/2, but adds a newline at the
end.

By default, the device is the standard output. It returns :ok if it succeeds.

## Examples

    IO.puts("Hello World!")
    #=> Hello World!

    IO.puts(:stderr, "error")
    #=> error

iex(4)>

Unlike languages like Python and Ruby, in Elixir you need to use a qualified call that includes the module name in order to invoke this function.

If we don’t qualify the call, we get a compile error:

iex(4)> puts("Hello, World!")
** (CompileError) iex:1: undefined function puts/1

If you wanted to omit the module name, you could import the module (i.e., import IO) beforehand, or more realistically, limit the import to the function(s) that you need:

import IO, only: [puts: 1]

puts("Hello, World!")

That puts: 1 indicates that we are specifically importing the version of the function that accepts one argument. You’ll see that function referred to as IO.puts/1 and we say that it has an arity of one or it’s a one-arity function.

The arity of a function (i.e., the number of arguments it accepts) is important because in Elixir you can have functions with the same name but different arities.

In fact, there are technically two variants of the puts function, IO.puts/1 which we just used, and IO.puts/2 which also allows us to specify an IO device as its first argument. (I say technically because they are both declared within a single function definition.)

By default, the function prints to the standard output. This can be easily verified by looking at the Elixir source code:

def puts(device \\ :stdio, item) do
  :io.put_chars(map_dev(device), [to_chardata(item), ?\n])
end

As you can see, the underlying implementation makes a call to the Erlang’s IO.put_chars/2 function.

What’s worth noting here is that:

• In Elixir, default parameters can be specified using \\.
• The default IO device for the function is the atom :stdio which maps to :standard_io in Erlang. Basically, by default, it will print to your stdout unless you pass a different device to the function.
• Another common value for the device is :stderr which is a shortcut for Erlang’s :standard_error.
• When we call the function without a device (leveraging the default parameter) we are calling IO.puts/1. When we pass it a device as its first argument and a string as its second argument, we are calling IO.puts/2.

In practice, you’ll most commonly use IO.puts/2 when printing to the standard error, instead of the standard output:

iex(5)> IO.puts(:stderr, "Hello, Post-Apocalyptic World!")
Hello, Post-Apocalyptic World!
:ok

For such messages, there are also IO.warn/1 (used below) and IO.warn/2 which output to the standard error and in addition, include a stacktrace (provided by the developer in the case of IO.warn/2).

iex(6)> IO.warn("Hello, Post-Apocalyptic World!")
warning: Hello, Post-Apocalyptic World!
  (stdlib) erl_eval.erl:680: :erl_eval.do_apply/6
  (elixir) src/elixir.erl:275: :elixir.eval_forms/4
  (iex) lib/iex/evaluator.ex:257: IEx.Evaluator.handle_eval/5
  (iex) lib/iex/evaluator.ex:237: IEx.Evaluator.do_eval/3
  (iex) lib/iex/evaluator.ex:215: IEx.Evaluator.eval/3

:ok

In most cases, parentheses are optional in Elixir, so we could omit them.²

IO.puts "Hello, World!"

It’s worth noting that strings are double-quoted literals in Elixir. Unlike other languages, single-quoted literals are not an alternative way of representing strings.

In Elixir, single-quoted literals represent a related but ultimately different datatype (i.e., List), as we can verify by using the handy data type information helper i in IEx:

iex(7)> i "Hello, World!"
Term
  "Hello, World!"
Data type
  BitString
Byte size
  13
Description
  This is a string: a UTF-8 encoded binary. It's printed surrounded by
  "double quotes" because all UTF-8 encoded code points in it are printable.
Raw representation
  <<72, 101, 108, 108, 111, 44, 32, 87, 111, 114, 108, 100, 33>>
Reference modules
  String, :binary
Implemented protocols
  Collectable, IEx.Info, Inspect, List.Chars, String.Chars

iex(8)> i 'Hello, World!'
Term
  'Hello, World!'
Data type
  List
Description
  This is a list of integers that is printed as a sequence of characters
  delimited by single quotes because all the integers in it represent printable
  ASCII characters. Conventionally, a list of Unicode code points is known as a
  charlist and a list of ASCII characters is a subset of it.
Raw representation
  [72, 101, 108, 108, 111, 44, 32, 87, 111, 114, 108, 100, 33]
Reference modules
  List
Implemented protocols
  Collectable, Enumerable, IEx.Info, Inspect, List.Chars, String.Chars
iex(9)>

Strings are encoded in UTF-8, so you can use special characters and even emojis.

iex(9)> IO.puts("Fabrizio De André")
Fabrizio De André
:ok

iex(10)> IO.puts("Hello, 🌎!")
Hello, 🌎!
:ok

It’s also possible to print a given character by specifying its UTF-8 codepoint.

iex(11)> > IO.puts("Hello, #{<<127758 :: utf8>>}!")
Hello, 🌎!
:ok

If you are familiar with Ruby, you’ll recognize the same string interpolation syntax in which the expression that needs to be evaluated is enclosed within #{}.

Windows users encountering issues related to special characters can improve their experience by changing the active console code page by executing chcp 65001 in their Command Prompt, before executing IEx.

It doesn’t get any simpler than a Hello World program, but as you can see, if you dig a little deeper, you can find out quite a few things about a given programming language.

In the next Elixir-related post, I’ll publish a similar discussion for another seemingly trivial problem: the length of a string in Elixir. It will give us an opportunity to discuss strings more deeply. Subscribe, if you don’t already, to be notified of its publication.

Footnotes

1. Atoms are constants whose values are their own names. The value of :ok is :ok. If you are familiar with Ruby, atoms are equivalent to symbols.
2. A glaring exception to the parentheses being optional are non-qualified/local calls with zero-arity. In those cases, parentheses are required to distinguish simple variables (e.g., user_list) from actual function calls (e.g., list_user()). To avoid ambiguity, it’s also important to include parentheses with one-arity functions within pipelines (e.g., "Hello, World!" |> IO.puts()). For stylistic recommendations of when to use parentheses and when to omit them, consider reading these two style guides (1, 2). At any rate, do not obsess over this. mix format or a properly configured editor will typically take care of applying idiomatic and consistent styling for you.

The post Elixir Hello World appeared first on Programming Zen.

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.

I don’t see this as a negative, true as it might be. When Rails arrived on the scene a decade ago, it was thoroughly impressive and quite the improvement over the status quo in the PHP, Java, and even Ruby communities. At the time, despite some shortcomings, it was revolutionary.

Not surprisingly, as time went on the framework evolved, improved, and became more mature. The whole ecosystem around it grew exponentially. You can now deploy scalable Rails applications. It is the darling framework of most startups in Silicon Valley. You can leverage advanced support in editors and IDEs, run it on different platforms (e.g., on the JVM via JRuby), and find Rails developers to hire with relative ease.

As it grew to become the tool of choice of countless web developers, it managed to have a massive influence on other communities as well. It contributed to raising the bar for frameworks in other languages and as a result we have at least a bit of Rails inspired frameworks in virtually every language today. We are more productive almost regardless of the language we choose, and in many cases we have Rails to thank for it.

What Rails lost in the process is the massive competitive advantage it had in its early days over virtually everything else that was out there. [1] It hasn’t failed to grow. It hasn’t failed to innovate. It simply matured and so did the rest of the web world.

I think it’s important for developers to reinvent themselves, or at least stay up-to-date on what’s available out there. That’s how I came to discover Rails in the first place. This is true for programmers in general, and its especially true for my professional role which includes technical evangelism in a team that continually reinvents itself.

When you go talk to a new generation of programmers, you need to be able to speak their language. And today for many, in my experience, that means speaking Node.js, instead of Rails.

That’s okay. Ruby on Rails might be old news by now, but it remains a perfectly capable solution for a wide array of problems. It has become the status quo and there is nothing wrong with that.

As we look for new runtimes, languages, and frameworks that innovate further and better solve those particular use cases where Rails doesn’t shine, we might stumble upon a new and innovative solution that make today’s Rails look like J2EE or PHP did to us back in 2004. [2] Until then, it’s worth keeping an eye open while still wearing that old, comfortable, and very trusty hat that has been helping us get the job done for a decade now.

The post Rails Is Old Hat, and That’s Okay appeared first on Programming Zen.

I share this as a way of illuminating the fact that there is a reward to be had if you enjoy keeping up with technology and the programming world – and it’s a payoff that goes hand-in-hand with the sheer fun of exploring and using new cool technologies.

We live in a world that moves quickly, with significant innovations being introduced every couple of years and entire tectonic shifts coming along every decade or so.

This doesn’t just apply to programming languages either – we’re talking databases (e.g., NoSQL), paradigms (e.g., parallelism and concurrency), new approaches (e.g., Big Data in the Cloud), new frameworks (e.g., Meteor), and many other corners of this vast field.

In the programming world, in order to stay competitive, you can not ever stop learning. If you’re not leading the pack, you apt to be left in the dust.[2]

One way to keep up is to never stop experimenting, playing with new languages and technologies in your spare time and applying them to non-mission critical projects. That’s the strategy I have grown accustom to at least, and again, no complaints from me when it comes to taking such an approach.

Wayne Gretzky, arguably – if not flat out – the best hockey player of all time, has a great quote that applies to hockey as much as it does to life in general.

I skate to where the puck is going to be, not where it has been.

Damn, Gretzky was good on the ice. Anyway, back to the topic. Some developers might consider R or Node.js to be the future. In reality, that’s where the puck is now.

Where will the puck be in three, five, or ten years? We’ll have to wait and see to know for sure. Meanwhile, I encourage you to explore three programming languages that might very well be headed in the same direction of that most iconic of Canadian sports equipment, the humble yet mighty, puck.

• GO: A fast, truly cross-platform, concurrent language that resembles a modern C on steroids.
• Julia: A very high level language that’s aiming to be the future of scientific computing and data science, including integrating with existing solutions such as Python scientific packages. Think of it like a modern Fortran on steroids.
• Elixir: This language fully leverages the power, reliability, and concurrent nature of the Erlang VM, but does so with an elegant Ruby-like syntax. It’s Ruby taking steroids in the gym she goes to seven times a week.

I make no promises or guarantees that these languages will pick up massive momentum over time. What I can promise you is that you’ll enjoy and learn from them in the moment. Each one is not only promising, but already delivering and is well worth checking out, if you haven’t already.

Let me know where the puck is headed for you.

The post 3 Upcoming Languages That Are Worth Exploring appeared first on Programming Zen.