Remember fear is the mind killer, so just get over it and learn Functional Programming ~ Kevin Smith talking about Erlang
The two afternoon sessions, Erlang the Basics and Functional Concepts for OOP Developers, were one – two punches to the gut, in a good way. If you tried to read a Functional Programming tutorial, maybe waded into the Lamda Calculus pool and found it didn’t have a bottom, you’re not alone. I remember just innocently hitting Wikipedia for a definition of Functional Programming only to be turned back by the first sentence comprised entirely of mathematical symbols and polysyllabic words without definitions that didn’t also have mathematical symbols and polysyllabic words.
Thankfully, for the cost of gas, a room and a cheap ticket to this conference, I got the opportunity to let real functional programming masters explain it to me in English.
Kevin Smith, of EngineYard, does Erlang for a living. That kind of makes him a grand pooba of Functional Languages in my book since OOP just about buries the list of code written today. Still, as Kevin noted in his talk, there are high profile sites using Erlang today – Facebook is using it for chat, Amazon uses it as does CouchDB. Unlike Haskell with its academic background, Erlang is the programmers functional programming languages ‘to make hard things eas(ier)’. So what are those really hard things? Well concurrency is the big one.
Not long ago, programmers had a one-machine-one-CPU view of the world that served them well in the Object Oriented Programming universe. Software was rarely written to work as a unit over more than one CPU at a time because it was 1) very very hard and 2) impractical and unneeded for most cases. Today, however, programmers are realizing that the multi-core growth path of hardware manufacturers has hijacked the stage, forcing us all to become concurrency experts. While OOP languages are saddled with the baggage of supporting shared memory and mutable variables, reducing them to a one legged man in a ass kicking contest, their distant cousin Functional Programming Languages aren’t feeling the same strain. FP’s have immutable ‘variables’ (really they are unchanging pointers, so more like constants) and a very low cost for spinning up processes. This frees them to run in a highly distributed way on many cores and many machines collaboratively. Erlang, written by the team at Computer Science Labs at Ericisson, had a real world need for a highly concurrent language to write their phone system on. Its design works wonderfully to harness that 8 core desktop you have sitting under your desk.
Bryan Weber was kind enough to expond on this foundation talk by exploring Functional Concepts for OOP Developers. My take home from this talk was the message model used by most Erlang programmers to achieve concurrency. Like Scala, Erlang uses a mailbox with a send and receive paring to smoothly weave a web of interconnected processes that can be located anywhere on the network. Simply spawn a process, which gives you a pid in response. Now send a message to the pid. The spawned process does a recieve to check the mailbox for the message. Want to send a response, no problem. Have the spawned process send to the parent and have the parent check the mailbock. Done, you just did concurrent work. This little scene is played out using Actors, which naturally, is an apt analogy.
I don’t know yet if FP will make it into my world any time soon. Our concurrency neeeds are small so far. I would say that Functional Programming isn’t the solution to all problems, but it just may be the answer to that tricky problem defying all other solutions.