Erlang

From Epowiki

Jump to: navigation, search

Erlang is Single Assignment Language but not a pure Functional Programming Language because it has impure I/O including a simple yet powerful distributed message passing model partially based on Communicating Sequential Processes and partially based in functional programming's common pattern matching mechanisms.

Erlang has been used to implement a half dozen or so real Ericsson telecommunications products. There is also a ton of freeware for it. The entire Erlang distributed programming system recently was released under an open source license. This includes a distributed database with a lot of features including use of Erlang's "list comprehensions" extended to tables, forming a simple and powerful query language.

References


Question (having just bought the Erlang book and had a lookee-see): Erlang does not support inheritance or polymorphism. Is anyone aware of a way to do decent OO programming in Erlang, or is that just a give-up? thanks, AlistairCockburn

Yes, just remember that what everyone else calls an 'object', Erlang calls a 'process'. There's pretty much a one-to-one mapping of concepts, with one huge difference: Erlang processes have a control flow thread associated with them. It's hard to communicate how powerful this is, unless you've programmed in Erlang (or the SimulaLanguage; it had a thread-per-object too).

I recall reading a flamewar somewhere about Erlang vs. OO languages. The sample problem was a control system for three elevators. The Erlang person claimed that Erlang matched the problem naturally, because you just create three processes, one for each elevator, and make each respond to (callbutton Floor), (door_open), and (door_close) messages. The OO person pointed out that you could just as easily create three objects with the same methods and get the same result. From an interface point of view, there's no difference. But try to actually implement this, with actual elevators going up and down and motors starting and stopping. In Erlang, it's about as complex as you'd expect. In most OO languages it's a nightmare, because the real world has stuck it's asynchronous nose in and suddenly you've got to deal with either threads or a nasty control flow inversion.


Erlang has first class functions (e.g. "fun (X, Y) -> x + y end"). This is a newer feature than the book. Erlang now also has records (aka "structs"). These two features allow you to build a poor man's OOP system, like we used to do in Scheme. (But Erlang doesn't have the nice syntax macros that Scheme has.)

Unfortunately the current implementation of records is cumbersome because it is not built in to the interpreter. It is a pre-processor implementation, and so requires files to define the records and then inclusion of the files to use them in another module. Ugh.

Erlang has a lot of nice features, but this one is incomplete.

Erlang also has pattern matching to select appropriate clauses of a function. I was wondering how this meshed with the CommonLispObjectSystem's GenericFunction's which discriminate on type as well as eq'ness of an argument. Erlang discriminates on equality of the structure of an argument. But Erlang is not dynamic, in the sense that you cannot add new clauses to a function dynamically. All the clauses of a function have to be defined in one location.

--PatrickLogan

The Erlang FAQ has this to say on the topic of OO:

  • People coming to Erlang from object-oriented languages sometimes spend a while trying to write programs in an object-oriented style in Erlang before "seeing the light" and giving up. Several papers have been published about how to "do OO in Erlang", including a chapter in the Erlang book.
  • A common conservative position is to say that processes, asynchronous messages, functions and modules provide the same ability to structure systems as do threads, classes, methods, inheritance and aggregation.

When looking at an Erlang process from the "outside", it reminds a little about an object in an OO language. It encapsulates its state, which is changed by sending messages to it. With this view it also has something like polymorphism, since you could replace the process with another process that responds to the same messages. -- AndersBengtsson

What you are describing is type substitution, not inheritance. If you wanted a process to inherit from another you would need to use delegation to pass messages up and would need some other mechanism for calling the _most-derived_ implementation of a method (something like a callback). Would some Erlang expert please clarify if necessary. -- PeterSumskas.

(Note that I wrote "polymorphism", not "inheritance". Inheritance is just one of several ways to achieve polymorphism. -- AndersBengtsson)

Interestingly, in practice I find that there is extremely little use of polymorphism in Erlang programs, even though it is easy to do in the way AndersBengtsson says. In my experience of Erlang programs, when you send a message to a process you almost always know exactly which module implements that process, and therefore which file to look in to see what it does. I've found this an interesting difference, coming from Java experience where many, if not most, method calls go through a level of indirection and may lead to one of several specialised implementations in different source files. -- LukeGorrie

Retrieved from "http://www.possibility.com/wiki/index.php?title=Erlang"
Personal tools