Why blog about Erlang now?

For me writing blog posts is often a therapeutic way to work out puzzles and clarify my own understanding of a concept. I have been writing Erlang on and off for around 1.5 years now. As of late I have also been typing a lot more Haskell and some OCaml. This has all been great and I love these languages. I have decided to commit a bit more to Erlang lately and I thought I would start blogging again in earnest – mostly with small-ish Erlang examples just to force myself to be able to explain the concepts. I can program in Erlang (to some level at least) – now I want to be able to be good enough to explain Erlang software to people.

Essentially – I think that erlang the language is OK, I think that Erlang the runtime is amazing and I think that OTP – the common set of Erlang behaviors is very powerful. The entire ecosystem puts together a very compelling offering. You can achieve massively parallel, manageable bits of software in small enough bits of code that it is ownable. So – Erlang it is…

So in that spirit – I will start here with some very simple Erlang concepts.

Erlang is Dynamically Typed

Erlang is a dynamically typed language that to be honest – I found pretty ugly (syntactically) at first. I have done plenty of programming in dynamic languages – especially in Ruby (and to a slightly lesser extent – Python). I really do like dynamic languages but to be honest; I do believe that in larger software projects today that static typing can really by you a generally higher degree of assertable ‘correctness’. I prefer Haskell’s type system to many others – but my basic point is that I think types are powerful. In any case – I still think Erlang’s total offering is powerful enough to make a concede this point.

While Erlang is dynamically typed it does have a simple way to organize primitive data elements into composite types – this is Erlang records. You can also of course use tuples (a sort of anonymous type). In addition, Erlang code is organized into modules. So – while we may organize our code differently than in other languages – we have some good organizational concepts.

Modules

-module(exchange).

Records and Tuples

As I mentioned – erlang lets us organize primative elements into composite data types. The anonymous way of doing this is tuples. The ‘named’ way of doing this is records.

-record(order,{market, price, size, side}).

This is the declaration of a record in Erlang. You can declare an instance of a record like this:

#order{market=vodln,price=127.95,size=350,side=bid}

It is essentially a nice dress on top of a tuple which would look like this:

{vodln,127.95, 350, bid}

So – records are really just nice ways to put together composite types with names. Tuples are ways to assembly composite types anonymously. Both have their usages.

Object Orientation vs Functional Programming

Notice that these records/ tuple things have no methods ‘on’ them. Typically when you declare a type in OO languages – you put methods on them. This whole bundling up of methods and data IS OO programming. Functional Programming lets you have data and describe functionality. What this means is that it is usually easier to add more functions on a given data type in a functional language – but harder to change the data structures. This is because in an OO language – the data is WITH the functionality. In a functional language the data is apart from the functionality. It is all a tradeoff, but I think the functional paradigm is often much closer to the domains I have been working in (trading specifically). So – FP takes away the general encapsulation of data/ methods together. Note that you can still hide private functions inside a module. Eg; you implement a module and export 1 of 10 methods. This is still a good way to expose a minimal surface area of your software to the outside consumer of it.

Functions

Functions are – as you may have guessed at the heart of Erlang.

levelFor(Order, Exch) when Order#order.side == bid ->

levelForSide(Order, Exch, bid, fun(E) -> E#exch.bids end);

levelFor(Order, Exch) when Order#order.side == offer ->

levelForSide(Order, Exch, offer, fun(E) -> E#exch.offers end).

Here we have an example function that I will use as a demonstration for several points.

• You declare functions in erlang as a top level item. You do not put them inside of records, you put them in a module – but that is it.
• Values/ Parameters all start with upper case letters (I found this very odd at 1st).
• You can declare the same function N times each with different ‘guard clauses’ and the order of the declrations is the order in which the runtime attempts to bind to them.
• This example shows how to extract values from records.
• This example shows  simple funs- anonymous functions.

Declaring functions, Guard Clauses, Extracting data from records

“levelFor” is the name of our function. This function takes 2 arguments named Order and Exch. The arguments come after the name in the (…).

After that is a guard clause – this ‘when’ is evaluated by the runtime to see if the method should be executed. So – we can see in case 1 – if the side == bid – then we will execute the method. The actual method body comes after the ->.

You can extract values from records using this syntax ValueName#recordName.fieldName. So our example above has several of those.

Funs and multiple function Declarations

The bit after the -> is invoking another method and passing in as the last argument an anonymous function. That bit that starts with fun(E) and ends with “end”. This is simply an unnamed function (delegate, function ptr, etc) passed to the next function.

Also notice that I declared the function 2x – at the end of the 1st declaration I put a ; and at the end of the 2nd I put a “.” ( a dot). This is a convenient way to get switch statements out of our code nesting. We use the guard statements to see which of the functions get bound to at runtime. We could have also used if or case statements – but for this example’s sake – we are not

OK – that is all the time I have for today… more next weekend

-Chris

Responses are currently closed, but you can trackback from your own site.