tags:

views:

256

answers:

3

I hear all the time that Erlang is a functional language, yet it is easy to call databases or non side-effect free code from a function, and commands are easily ordered by using "," commas between them just like Ruby or another language, so where is the "functional" part of Erlang?

+1  A: 

The functional part is that you tend to pass around functions. Most langauges can be used both as a functional language, and as an imperative language, even C (it's quite possible to make a program consisting of only function pointers and constants).

I guess the distinguishing factor is usually the lack of mutable variables in functional languages.

roe
So maybe Erlang and others like it should be called non-mutable languages?
Zubair
@Zubair: Perhaps, but I guess it's more the fact that the language itself makes it easier to work with functions rather than varaibles. I guess the name is derived from mathematics' functional analysis (http://en.wikipedia.org/wiki/Functional_analysis), but that's just my speculation.
roe
Ok, that makes sense, thanks
Zubair
+5  A: 

The central idea is that each process is a functional program over an input stream of messages. The result from the functional program is an output stream of messages to others. From this perspective, Erlang is a rather clean functional language; there are no destructive updates to data structures (like setcar in Lisp and most Schemes).

With few exceptions, all built-in functions such as operations on ETS tables also follow this model: apart from efficiency issues, those BIFs could actually have been implemented with pure Erlang processes and message passing.

So yes, the Erlang language is functional, but a collection of interacting Erlang processes is a different thing. Each process is an ongoing computation, and as such it has a current state, which can change in relation to the other processes. Even a database is just another process in this respect.

In my mind, this is one of the most important things about Erlang: outside the process, there could be a storm raging, but inside, things are calm, letting you focus on what that process should do - and only that.

RichardC
Process isolation and lack of shared state is one of the key properties of the Actor model. I love the Actor model.
kyoryu
Yes... but what does the actor model have to do with being a functional language or not?
Zed
I'm confused now with the actors part of it. I guess calling a language "functional" does not mean it is 100% functional then. How are actors related?
Zubair
It depends on what you consider to be "the language". The actor model in Erlang (processes and their current state and output) can be regarded as being on another level than the language, and in that case, Erlang clearly deserves to be called functional. But if you regard the actor model as part of "the language", then you are suddenly dealing with effects, time, and nondeterminism. This makes some people say "oh, but Erlang uses side effects". The answer is both yes and no.
RichardC
I think Joe Armstrong usually calls those sublanguages of Erlang Functional Erlang, Concurrent Erlang, SMP Erlang, Distributed Erlang and Reliable Erlang, where each one is a proper superset of the one before. So, Functional Erlang is what runs inside an Actor, and it is purely functional. Concurrent Erlang is when you have multiple Actors, SMP Erlang is when you have multiple schedulers (i.e. multiple CPU cores), Distributed Erlang is when you have multiple nodes and Reliable Erlang is when you use supervisor trees and all of that stuff. Only the first one is purely functional, since sending
Jörg W Mittag
... a message *is* a side-effect.
Jörg W Mittag
+4  A: 

Yes, it's a functional language. It's not a pure functional language like Haskell, but then again, neither is LISP (and nobody really argues that LISP isn't functional).

The message-passing/process handling of Erlang is an implementation of the Actor model. You could argue that Erlang is an Actor language, with a functional language used for the individual Actors.

kyoryu
I'm pretty sure there are people in the Haskell community that would argue that Lisp is not functional. There are also people in the Lisp community who argue that - in fact, the CommonLisp community adamantly insists that CommonLisp is a multi-paradigm language.
Jörg W Mittag