I’m working on a presentation I’m hoping to give at my local BarCamp this weeekend. The presentation is going to be on Erlang — surprise, surprise — and how it makes concurrent programming easy. One of my goals for the talk is to find a way to bridge the conceptual gap between OOP and Concurrency Oriented Programming (COP). I want OO developers to grok the importance of COP without a lot of mental gymnastics.
A realization hit me this morning while I was brushing my teeth. I was meditating on the relationship between classes and objects in OO languages and Erlang’s modules and processes.
In most OO languages classes define constructors, destructors or finalizers, interfaces and functions, and member variables. Objects take these definitions and turn them into runtime behaviors. OO Theory 101.
I realized if I substituted Erlang’s modules for classes and processes for objects the same relationship would still hold. Erlang modules define runtime behaviors by way of the functions they define and export. Modules are used to create “instances” of themselves by creating processes which use the module. Modules also define a data model by defining the state variables used by the Erlang process.
Erlang’s OTP behaviors are an excellent example of the relationship in action. Behaviors define, well, behaviors by way of the callback functions they define and the management functions they export. They model the class-to-object relationship by creating processes which use the behavior module. Finally, they define a data model because they also define the state variables used by the running process.
I think I’ve intuitively known this for a while because it reflects the way I’ve been writing Erlang for a while now. I tend to write code where a single module implements a certain “type” process. I’ve noticed code written this way is easier to understand later and much easier to debug for the same reasons OO code written in this style is easier to maintain: data encapsulation, well-defined contracts, and separation of responsibilities.
Patrick Logan’s latest missive highlighting the complaints some people have about Erlang’s single-assignment semantics reminds me of something I’ve been wanting to say for a while:
If you are chronically bumping into the limitations of single-assignment then you’re doing it wrong.
Off the top of my head, here are the two reasons I can think of why people don’t like single-assignment semantics (SAS for short):
Looping over a collection of values - If you’re running afoul of SAS then you’re looping iteratively not functionally. You should investigate list comprehensions, recursive functions combined with pattern matching, or map, fold, zip, or zipwith in the lists module. If you really need plain old for-loop style iteration, lists:foreach/2 should do nicely but in a functional style.
Reusing variables in the same function - Quit it. Really. Erlang is trying to tell you your function is either too long or doing too many things.
This isn’t to say that you’ll never bump into SAS. I run into mostly when I’m writing code which makes heavy use of records and qlc although I daresay with a bit of though and factoring I could remove those instances as well. Cobbler’s shoes and all that.
Rather than bring your favorite language’s paradigm to Erlang (Ruby, Python, Java, etc) try working with Erlang’s grain. The style of programming these techniques encourage, namely reducing side-effects and function complexity, are beneficial no matter what language you’re using.
5
Itching my programming nerve Photo: oreillygmt I've just got back from the first ever commercial Erlang conference. Some 40 talks in two days all related in some way or other to Erlang. It was a chance to meet old friends, make new friends and connect people together in the hope that new synergy effects would arise.
The most exciting thing was the emergence of what I think might be the first killer applications written in
9
UBF and VM opcocde design UBF is a data encoding that allows structured terms (rather like XML) to be sent over the network. It also includes a protocol checking scheme to automatically determine if sequences of typed messages follow a particular protocol.
This blog entry was stimulated by this posting on the erlang mailing list.
One of the basic ideas of UBF of was to send programs not data structures. The programs
4
Invasion of Privacy On 18 June the Swedish Parliament passed a law giving sweeping new powers to the FRA (Swedish Defense Radio Establishment) allowing them to wiretap people in Sweden through phone conversations, email, text messages and more.
All people in Sweden using electronic communication can have their communication monitored despite the fact that they are not suspected of committing any crime.
I’ve been playing around a bit with Wrangler—an Erlang refactoring package for Emacs. I like what I’ve seen of it so far but turning it on and off is a little ugly. Typing M-x erlang-refactor-on and M-x erlang-refactor-off gets tiresome after the third time.
So I whipped up a function to toggle Wrangler on and off:
I can now announce my remaining Erlang project has come to fruition. Namely: Erlang By Example is now live and available for download.
I’m always interested in suggestions in how I can make the screencasts better. Send suggestions to kevin at (remove this) hypotheticalabs period com. They’re targeted towards someone completely new to the language, so bear that in mind when writing up suggestions.
If you have downloaded a previous version of the installer, and if it does not work for you, you can give another try with the latest release, from the ejabberd download page.
Erlang R12 is unsupported yet on Windows and will only be supported with the 2.0.2 release.
3
The Road we didn't go down I've been following an interesting discussion on the Erlang mailing list where Steve Vinoski and friends have been telling us what's wrong with RPC.
The discussion started on 22 May, the general topic of conversation was the announcement that facebook had deployed a chat server written in Erlang.
In one of the posts Steve said: "What all those years of CORBA taught me, BTW, is that RPC, for a
8
Facebook chat is developed in Erlang Facebook recently announced that their chat system is based on Erlang code running on a large cluster. It confirms that Erlang is the key tools for building large scale applications, especially for social networks.
Like ProcessOne has used Erlang to build its Instant Messaging suite of tools, Facebook is using Erlang to build its web based chat infrastructure.
The system uses a Comet based programming approach. From our knowledge the system uses Mochiweb as its web server to handle the massive number of long polling connections.
More details are available from Facebook engineering blog.
