24

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?

Jonas
  • 121,568
  • 97
  • 310
  • 388
yazz.com
  • 57,320
  • 66
  • 234
  • 385

4 Answers4

37

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
  • 10,412
  • 1
  • 23
  • 24
  • 4
    Process isolation and lack of shared state is one of the key properties of the Actor model. I love the Actor model. – kyoryu Feb 16 '10 at 09:23
  • 5
    Yes... but what does the actor model have to do with being a functional language or not? – Zed Feb 16 '10 at 09:59
  • 2
    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? – yazz.com Feb 16 '10 at 11:02
  • 3
    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 Feb 16 '10 at 14:03
  • 10
    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 Feb 16 '10 at 20:18
  • 2
    ... a message *is* a side-effect. – Jörg W Mittag Feb 16 '10 at 20:18
  • 2
    @JörgWMittag ...except even inside an actor arbitrary side effects are allowed which _doesn´t_ make it purely functional. – Magnus Kronqvist Dec 29 '11 at 09:27
16

There's a meme that functional languages must have immutable values and be side-effect free, but I say that any language with first-class functions is a functional programming language.

It is useful and powerful to have strong controls over value mutability and side effects, but I believe these are peripheral to functional programming. Nice to have, but not essential. Even in languages that do have these properties, there is always a way to escape the purity of the paradigm.1

There is a grayscale continuum between truly pure FP languages that you can't actually use for anything practical and languages that are really quite impure but still have some of the FP nature to them:

  • Book FP: Introductory books on FP languages frequently show only a subset of the language, with all examples done within the language's REPL, so that you never get to see the purely functional paradigm get broken. A good example of this is Scheme as presented in The Little Schemer.

    You can come away from reading such a book with the false impression that FP languages can't actually do anything useful.

  • Haskell: The creators of Haskell went to uncommon lengths to wall off impurity via the famous I/O monad. Everything on one side of the wall is purely functional, so that the compiler can reason confidently about the code.

    But the important thing is, despite the existence of this wall, you have to use the I/O monad to get anything useful done in Haskell.2 In that sense, Haskell isn't as "pure" as some would like you to believe. The I/O monad allows you to build any sort of "impure" software you like in Haskell: database clients, highly stateful GUIs, etc.

  • Erlang: Has immutable values and first-class functions, but lacks a strong wall between the core language and the impure bits.

    Erlang ships with Mnesia, a disk-backed in-memory DBMS, which is about as impure as software gets. It's scarcely different in practice from a global variable store. Erlang also has great support for communicating with external programs via ports, sockets, etc.

    Erlang doesn't impose any kind of purity policy on you, the programmer, at the language level. It just gives you the tools and lets you decide how to use them.

  • OCaml and F#: These closely-related multiparadigm languages include both purely functional elements as well as imperative and object-oriented characteristics.

    The imperative programming bits allow you to do things like write a traditional for loop with a mutable counter variable, whereas a pure FP program would probably try to recurse over a list instead to accomplish the same result.

    The OO parts are pretty much useless without the mutable keyword, which turns a value definition into a variable, so that the compiler won't complain if you change the variable's value. Mutable variables in OCaml and F# have some limitations, but you can escape even those limitations with the ref keyword.

    If you're using F# with .NET, you're going to be mutating values all the time, because most of .NET is mutable, in one way or another. Any .NET object with a settable property is mutable, for example, and all the GUI stuff inherently has side-effects. The only immutable part of .NET that immediately comes to mind is System.String.

    Despite all this, no one would argue that OCaml and F# are not functional programming languages.

  • JavaScript, R, Lua, Perl...: There are many languages even less pure than OCaml which can still be considered functional in some sense. Such languages have first-class functions, but values are mutable by default.

Foototes:

  1. Any truly pure FP language is a toy language or someone's research project.

  2. That is, unless your idea of "useful" is to keep everything in the ghci REPL. You can use Haskell like a glorified calculator, if you like, so it's pure FP.

Warren Young
  • 40,875
  • 8
  • 85
  • 101
  • 4
    Having "first-class functions" doesn't make a language FP. The "functional" part in Functional Programming refers to _mathematical_ functions, meaning functions where each input has a single output. This property then gives you referential transparency, immutability, which leads to equational reasoning. If you want a term for "programming with functions that aren't mathematical", then a better term is "procedural programming". Otherwise "FP Languages" are those that actively encourage the use of FP. JS, R, Lua, Perl will never qualify. Please don't dilute terms for marketing purposes. – Alexandru Nedelcu Jun 08 '16 at 10:27
  • 2
    @AlexandruNedelcu: I addressed that obliquely above with my comments about escaping the purity of the paradigm. By that I mean that any practical FP language lets you write programs that violate your mathematical ideal. If you insist on that definition, then even Haskell is not FP. Your definition is therefore untenable. – Warren Young Jun 09 '16 at 17:16
9

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
  • 12,848
  • 2
  • 29
  • 33
  • 4
    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 Feb 16 '10 at 20:13
  • Doug Hoyte argues that LISP isn't functional: http://letoverlambda.com/index.cl/guest/chap5.html . He's hardly "nobody" in the LISP world. He's talking about Common Lisp, of course and not Scheme (which is more functional in several important respects - and it's new cousin Clojure even more so). – itsbruce Jan 27 '15 at 09:34
1

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.

falstro
  • 34,597
  • 9
  • 72
  • 86
  • So maybe Erlang and others like it should be called non-mutable languages? – yazz.com Feb 16 '10 at 08:21
  • @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. – falstro Feb 16 '10 at 08:24