Lambda the Ultimate

we all see what we want to see...

Quite.

I agree. The author's attempt to see 'inheritance' in function abstraction ignores the 'is-a' quality of inheritance.

I wonder if what they have in mind is the duck-typing aspects that result from the dynamic-typing aspect of the language, not simply functional abstraction.

Well, it's hard to say -- the 'record' system in Erlang wouldn't be much used for architecture in the way that OO people use inheritance; but 'behaviour' would. The system is a little like Ruby mixins -- implement the callbacks and you get the interface functions for free -- but static, since it's a module attribute. Static mixins make me think of Haskell type classes...

I think behaviours should be discussed in this context, but I am not sure me that this is what Ralph Johnson had in mind.

Of course, it really doesn't make too much sense to use "OOP" and "inheritance" as generic terms referring to any kind of abstraction mechanism, modularity, or polymorphism...

is really profound.

Very insightul!
Truly, taking advantage of multi-proc/multi-core in an efficient manner is no small thing.
From my layman's perspective of implementing various internet oriented applications in a scalable environment - the simpler the application, the better it scales.

A fine example would be 'postifx' MTA. It has a process running for each significant bit in e-mail delivery lifecycle - incoming connection, outgoing connection, header rewrite, actualy delivery to mailbox and so on. The end result is that, the application code is simple and OS takes all the trouble to schedule processes.
It seems that the granularity is on the 'just-right' side of things.

I think that a lot of programmers don't give credit to OS to efficiently schedule tasks, when actually from a bird's eye view which only the OS kernel has, it is possible to correctly predict when to execute this or that

To be fair, some problem such as: [[Cache management becomes more involved]] are true for many parallel programming model, not just Erlang..

I tend to summarize your points as: it's usually easy to decompose an application into several tasks, but it's hard to ensure that this decomposition use efficiently the hardware.

Also (if memory serves!), this is also true for Erlang which use a VM which is not that efficient: sure you get a lot of scalability but the mono-CPU performance figures are quite lower than if the application was programmed in C.

:-)

Its not that Erlang-style message passing doesn't exist in other mainstream languages. There is a "oneway" qualifier that you can use when specifying messages that are part of a "formal protocol" in Objective-C. (see Apple's doc on this.) That's nearly the same as Erlang's message passing and, though I haven't done it myself, implementing distributed objects and similar reliability features in Objective-C is probably not all that more difficult compared to Erlang.

The difference lies in the cost of a thread/process. That Erlang has a functional core seems almost irrelevant to the message passing discussion, but it should not be forgotten that it is the very reason process creation can be made so cheap in Erlang.

That Erlang has a functional core seems almost irrelevant to the message passing discussion, but it should not be forgotten that it is the very reason process creation can be made so cheap in Erlang.

The surprising thing is that they don't take full advantage of it. Despite the fact that variables are immutable, the VM copies them when they are sent from one process to another, even on the same machine. I believe they do it that way to ensure that they can garbage collect each process' heap space with out regard for other processes.

"A Case for the Unified Heap Approach to Erlang Memory Management" (http://citeseer.ist.psu.edu/452894.html) raises that question and provides some hard, empirical numbers on the cost of strict per-process heaps.

Erlang does have some experimental support for zero-copy message passing, using the "shared" or "hybrid" heap models. However they are not default because of the GC impact - it's much easier to GC independent processes.

I wonder if its merely a question of whether to copy an object at GC-time or do it during the message passing. It may be that a shared heap can give time-local performance benefits, but does it outweigh the cost of message copy in the long run? Also there is a question of reliability. Process-local memory is very robust and you can crash a process without affecting others (as we all know from OS history). Even Symbian OS has adopted it - each thread has its own heap.

The issue is moot as Erlang is purely functional, so no updates can occur to shared objects. This is why it can just swap in a shared heap GC without affecting application. Crashing a process is identical: the memory unique to that process simply gets reclaimed.

PLT Scheme provides memory quotas in a shared heap. See Memory Accounting without Partitions. The security of the scheme has been discussed on the cap-talk list. (having a server spawn a subtask per client seems to solve their worries about non-determinisitic accounting). Kill-Safe Synchronization Abstractions describes how PLT Scheme ensures that killing processes won't cause deadlocks around shared data structures like message queues, and that's all you need beyond simple memory safety to make crashing processes safe in a pure message-passing language.

"Kill" according to that paper doesn't seem to cover the case of a "crash". OS kernels may not always have the luxury of waiting for a process to leave some kernel object in a consistent state before terminating it. Java by nature doesn't permit access to illegal memory locations at the machine level, but a C program does allow that and an OS kernel must still live with it. It must take down the errant program from an interrupt handler, releasing all resources it acquired.

That sounds like a bit more than "kill-safe" to me. Is it?

See Memory Accounting without Partitions. The security of the scheme has been discussed on the cap-talk list. (having a server spawn a subtask per client seems to solve their worries about non-determinisitic accounting)

That was my post that kicked off the discussion. I'm not clear on your proposal to spawn a subtask per client. IIRC, there were two main problems under discussion:

1. random ownership assignments could result in a shared service S being charged for resources used by its one of clients M; this is a DoS vulnerability which M could exploit to crash S.

2. a malicious client M could release handles to a resource B is co-operatively using which B is then charged for, and which places B over its quota.

Are you suggesting that for each shared resource that could be revoked maliciously, a subtask is spawned? I think this would probably be quite unmanageable, and a more principled accounting strategy would be simpler for developers to reason about.

The ultimate problem is that imprecise resource accounting and control leads to exploitable vulnerabilities, and it's not at all clear how to recover from the above situations. This is exacerbated by the fact that they are not even repeatable (non-deterministic), so you can't even test for them. In principled secure operating systems, like EROS and Coyotos, both 1 and 2 are not present because M must explicitly allocate the resources (and be charged for them), where in PLT scheme, allocation and ownership are implicit and separate. In EROS, S must still protect itself from the resources being revoked by M, but this recovery is understood, and quite doable.

I think the PLT scheme technique might be salvageable, which is why I pursued that discussion. Jonathan Shapiro proposed an interesting resolution: charge *all* parties sharing a reference for the storage; now its clear how the developer can reason about the resources his program will use, and the above situations are repeatable and testable, which is a marked improvement.

Where does the special efficiency of object-oriented design come from? This is a good question given that it can be viewed as a slightly different way to apply procedures to data-structures. Part of the effect comes from a much clearer way to represent a complex system. Here, the constraints are as useful as the generalities. Four techniques used together--persistent state, polymorphism, instantiation, and methods-as-goals for the object--account for much of the power. None of these require an "object-oriented language" to be employed--ALGOL 68 can almost be turned to this style--and OOPL merely focuses the designer's mind in a particular fruitful direction. However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.

                                                                                — Alan Kay, "The Early History of Smalltalk"

You should hear the howls I get from colleagues when I point out that last sentence...

Having spent a lot of time with Oaklisp and other, more traditional, dialects of Lisp, if there's one thing I get, it's that first-class lexical closures and objects can macro-represent each other, so the discussion about which is "better," in and of itself, isn't any more interesting than the discussion as to whether Pascal or C was better. What's interesting is the extent to which people who write software take the care implied in Dr. Kay's comment, and the extent to which a language does or does not require them to take that care.

Actually it's a very deep observation, and it requires a lot of experience to really grasp what it means.

Suggested exercise: Does the sentence still hold true if "information hiding" is substituted for "encapsulation"?

I think the bottom line is that exposing mutation is a form of tight coupling inasmuch as it might not be possible to extend the system without changing the exposed state transitions in a non-backward-compatible way. Encapsulation, whether through the mechanism of "classes," "modules," "records," "closures," or what have you, is one approach to limiting the exposure of state transition dependencies; another such mechanism might be "monads," for example.

The point that I try to emphasize in discussions like this is that when you dig a little into the foundational literature, you learn that the functional language fans aren't the only ones who think that focusing on state in programming is a bad idea that makes it difficult to create robust systems, and that object-orientation is yet another approach to removing state from the domain of discourse. The push-back to this point of view (IMHO) helps to demonstrate the corrosive effect of state-orientation on otherwise perfectly functional (no pun intended) minds.