Lambda the Ultimate

"Something more powerful than object orientation?" It sounded too good to be true. ...Object Orientation is not necessarily the best way to design and structure a piece of code. It might appear easier to learn and use, but when applied to larger system, the theory does not work. Users are forced to add "technical" objects that often result in complicated hierarchies. This makes the system architecture complex and sometimes affects the performance of the application.

Since the article brought it up, I wish that they had given an example to illustrate what they meant by "'technical' objects," and why they feel Erlang's "behaviours" provide a better way of structuring code.

When I was looking at Erlang, they had the main chapters of the redbook online, but I had to stealthfully read the chapter on OO programming in the local bookstore (didn't want to shell out $60 for a single chapter).

IIRC, the red book shows how to mimic inheritance in the language by using cooperative modules. It was kind of silent though on the question of polymorphism, which is actually (in my opinion) the more important point to OOP. I did figure a way to get polymorphism via messaging based on some of the hints provided. Indeed, at the heart of Smalltalk's OO technique is the message dispatch, and Erlang excels at messaging (i.e. threading).

When I wrote the example the first time, I combined the technique of inheritance and message polymorphism, but I ended up with way too many messages being passed around. The subclass object has to manually pass messages up the inheritance hierarchy to the superclass - something which OO languages do for you automatically. Being a bit too cumbersome and obtuse, I jettisoned the inheritance in favor of simply demonstrating polymorphism and encapsulation.

Thinking back on it, I figure there has to be a better way to pass messages on to a superclass without having to intercept and interpret all the specific messages. Something like a doesNotUnderstand: where the subclass passes all messages it does not understand up to the next level of inheritance.

As for the article, I agree that OO techniques of inheritance and polymorphism are a tad cumbersome in Erlang, and that it would be difficult to scale. OO in Erlang is more akin to being a usage pattern rather than a language design issue. In limited instances, though, it can be useful for constructing solutions. As with the above article and the chapter in the redbook, OO is downplayed as a viable solution in Erlang. As such, it is mentioned but not thoroughly explained.

Well, I know we do...

I guess it's always the same when learning new languages. You try to write programs in a way that you're used to, and then at some point you get an "aha!" moment and go native. I got my "aha" in Erlang when I eventually wrote a genuinely concurrent program (SMTP server).

That's what I recommend - writing a program (or two) that's inherently concurrent, and suddenly it all makes sense :-). Especially programs where not every process is a server in an infinite request loop (basically an Object). It's more interesting when you have processes that are just spawned to do a single task and then terminate (or crash trying), and processes that are state machines, and all that good stuff.

P.S. I'm still baffled at how Erlang programs can be so nice while using almost no polymorphism. I've no idea where it disappeared to, but I don't miss it anymore!

I would say from personal experience (YMMV) that a GUI is naturally object-oriented but not naturally concurrent, and a webserver is naturally concurrent but not naturally object-oriented. So all other things being equal, you'll write a more natural and beautiful webserver in Erlang, and a more natural and beautiful GUI in an OO language.

(Of course, all other things are anything but equal :-)

A great example of "technical objects" is Doug Lea's util.concurrent [1] package for Java. He's invented a whole lot of rather complex objects for different sorts of synchronization in a concurrent system, which mostly just disappear if you're programming in Erlang. They're not modelling real world objects, they're just the extra work you do to write concurrent programs in a language that wasn't designed for concurrency.

Similarly, Chris's OO in Erlang [2] is a great example of "technical processes", which are not actually modelling real-world concurrent activities, instead they're just the closest thing that Erlang offers to objects and classes - which is not that close.

As they say, "use the right tool for the job."

NB: my favourite personal program is an Emacs clone I'm writing in Erlang. This is not really a naturally concurrent program, and I do have "technical processes" (for buffers) which don't really fit the problem very well. I keep trying to wrestle the structure into something natural and beautiful, but no luck yet!

(Of course, the Lisp guys with their adaptable programming language can laugh at us all - but then they don't seem to be doing anything fun anymore :-))

[1]: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html [2]: http://www.angelfire.com/tx4/cus/shapes/erlang.html

Does the Erlang design specifically address this issue, Erlang being a functional language?

I can't speak for the Erlang design, but maybe someone who can will pop in and say a few words.

Does the Erlang design specifically address this issue, Erlang being a functional language?

As for built in language support, I gathered that you can use tail recursive functions from a process dispatcher to get the control information to vary over time (i.e. to get around the write-once variable framework). Of course, you end up bypassing the advantage of referential integrity if you use this pattern, as the value provided by a process becomes time sensitive. Ideally, you want to minimize the dependency between threads in order to maximize concurrency - i.e. you don't want threads waiting on each other and you definitely don't want them stepping on each other.

Instead of using a local variable to hold state information, you can spin off a thread that can hold that information. The value can be set by attaching a value to a message to the thread (via it's pid). The stored value can then be retrieved later by passing another message to the thread and requesting the current value.

The thread message handler recursively calls the function that handles the message handling with the newly received value. If the function is tail recursive, the stack space is not eaten up, and the write-once variables suddenly act as if they can be set any number of times.

I'll try to clarify what I meant. I didn't mean that concurrent processes are in general equivalent to objects. I made the much weaker claim that they both have state information.

This may mean that when reasoning about concurrent processes you can't sue the "shortcuts" that make functional languages easier to reason about (i.e., referential transparency).

I never quite know what people mean by "reasoning about" programs, I guess it means understanding them. I think that Erlang processes make concurrency a lot easier to understand (reason about), especially when you consider the possibility of bugs and failures. Most of the rest of Erlang is purely functional, which I think makes it easier to understand and to test, too.