Tags

, , , ,

Erlang has been a language that’s been on my long list of “stuff to get around to looking at when I have time”, largely thanks to the evangelism of a colleague of mine, Logan (https://github.com/logaan).  Yesterday I finally popped managed to pop it off the stack, although the means by which I got it to the top of the stack violates all  rules behind these data structures that I’m aware of.  

In total, I spent roughly three pomodoros (hence the 75 minutes: 3 x 25) downloading/installing and running through the early bits of the main tutorial and here’s what I’ve found so far.  Much of this stuff is gut reaction from first practical exposure to the language and is bound to be invalidated over time as I get deeper into Erlang, but I thought it might be worthwhile capturing it whilst still fresh…

Installation

All went as documented.  Downloaded the R15B ZIP from http://www.erlang.org/ it a short “./configure” and a couple of “makes” later, the REPL and compiler were ready to go…

Editing

My current text editor of choice, Sublime Text 2, ships with Erlang syntax highlighting which works a treat.  I wasn’t really paying attention to how well the completion functionality worked, so I cannot comment on that.

REPL

The REPL seems to work in all the way I expected; with cursor based command history, VI key bindings for navigation, etc.  From my naive perspective, it was intuitive and unsurprising in an IRB-like manner.

The REPL also provides a history method called (for some reason) “v” which allows you to retrieve past responses to your commands.

The Language

I’d previously sat through a couple of presentation Logan had given on Erlang (one of which can be found at https://github.com/logaan/erlang-presentation) so the initial sticker shock wasn’t there for me.  Indeed, I found myself quite drawn to the pattern matching approach the language takes to method invocation and how it declares which methods are exported.  

Indeed, I’m hoping the naturally recursive way Erlang likes to steer your solutions will force me to think along different lines when I’m building larger-sized solutions.  At the moment, it’s a bit of an enjoyable mental hurdle to think through this mechanism even in the basic tutorial examples like reversing lists.

Playing around with the toy programs in the tutorial was pretty simple and demonstrated these aspect of the language quite well.

Here’s one to make you think twice… how does Erlang evaluate a list of numbers?  It depends:

“[1, 2, 3]” is evaluated to the list of three numeric elements [1, 2, 3].

However the list “[65, 66, 67]” becomes the string “abc” because Erlang has second-guessed that these characters can also represent numbers… surely this is the cause for defects all over the place!?!

The Syntax

I’m not sure how best to describe some of the things in the syntax of the language… Idiosyncratic?  Baroque?  The main one of these that kept tripping me up was the need for the period to terminate statements.  My eyes aren’t trained to what to expect from the REPL when I miss one of these, so I found myself cursing them under my breath for quite a while.

The rules behind using upper case letters for (immutable) variables really grates on me as well.  Call me snobbish, but whenever I see variables named this way, I cannot help but think of Visual Basic code and all the nastiness that often accompanies it.

That said, having naturally immutable variables is very nice, although the standard error message you get when attempting to re-assign to a variable isn’t one that conveys it’s intent well: “no match of right hand side value <X>”.  Still, that’ll grow on me quickly I’m sure and it’ll just become more sublimated knowledge.

Overall

I’m still very much at the early stages of my investigation and looking forward to getting deeper into the syntax and building more complicated programs to see how the language/syntax/my brain scales up.  I’m especially keen to look at the actors and concurrency support for which Erlang is so well known. 

Advertisements