Joel Hughes's Blog

It's a little over a week since I started working through Programming Erlang and it has been a very pleasurable/rewarding few days.

I like to learn new languages for a number of reasons, including: adding skills to my repertoire and gaining new perspectives on my other programming techniques and languages. Despite only being able to grab a half hour here and there I feel these aims have already been achieved in some measure, and it had certainly given me an appetite to learn a lot more. My advice to any developer looking to experience functional languages for the first time is: pick a language (Haskell, Lisp, Scala etc...) and just give it a try. I'm sure some will end up being the more widely adopted than others, but as a learning experience all will be rewarding.

So, as a PHP developer with experience of other Object Oriented and Scripting Languages (Ruby, Python, ECMA etc...) the transition has been interesting to say the least. The key differences when programming in a functional language are the similarities to writing algebra (something I haven't thought seriously about since maths lessons aged 16).

These differences are down to:

• variables can be set only once
• the equals symbol is used for pattern matching rather than setting

1> X = 10.
10
2> X = 5.
** exception error: no match of right hand side value 5
3> 5+5 = X.
10
4> X = 2*5.
10

As you can see from the Erlang Console (above periods/full-stops terminate an instruction), as long as both sides of the equals equate to the same result, the program succeeds, I suppose = is used to set X in the first place but from there onwards it's matching/balancing the two sides – as it would in maths.

Combining balancing/pattern-matching with unchangeable variables (variables that don't vary if you like) is a method of preventing/reducing the opportunity for broken code. For example:

1> X = 100.
100
2> Y = X * 2.
200

The statement Y = X * 2. means that Y always equates to 200 as long as X is 100, if you could change X that statement would break. However, you can't change X so in this case Y = X * 2. will always be 200!

This is a very basic observation and one of the smallest hurdles in making the transition from OOP to functional programming, but if you have never seen it before it represents a fairly significant change to the norm.

There are plenty of other changes to adjust to such as: code isn't separated into Classes and Methods, but instead Erlang uses Modules and Functions (Modules are essentially containers for function groups) but these don't produce objects. Something I'm yet to get used to. I'm not yet far enough along to see how complex chunks of information/functionality are handled. A more thorough introduction can be found in the first couple of chapters of Getting Started With Erlang.

This post is just about giving the briefest taste of what Erlang and Functional Programming are like to use, and hopefully encourage others to investigate a little further. In my next post I'm going to run through a simple task I set myself and completed last week: FizzBuzz (as noted by Jeff Atwood as a simple test of programming competence), and give some comparisons to PHP, Python and Ruby.