> (I have exactly the same objection to the actor model as a foundational unit of computing. Theoretically, it's fine, but in practice it doesn't really work if it's all you can do. Similar to "pure" lambda calculus.)

With these models, it's all about making compilers ever better at their specialized job of translating "abstract machinery" into the current physical-machinery paradigm of the day.

No idea about "actors" but "pure lambda calculus" works terrifically well thanks to 25 years of top-notch efforts invested in the Glasgow Haskell Compiler.

OO is really in the same boat in that it's not exactly ASM either, just has even more "compiler investment" behind it broadly speaking.

GHC isn't even close to "pure lambda calculus", sorry. For one thing, there's a lot of fuzziness around e.g. "seq", strict pattern matching vs. lazy pattern matching, etc. which leads far afield from LC. For another, there's "IO" which doesn't have any kind of formal semantics in Haskell, nevermind LC, so...

EDIT: I'm not saying it's not useful as a model, I'm just questioning whether it's practical. I think both LC and the Actor model are both interesting and valuable, I just don't think they should be the foundational model for ABSOLUTELY EVERYTHING as e.g. Alan Kay seems to be advocating.

EDIT#2: I should say... I realize that LC actually is Turing-Complete, as I believe Hewitt has also demonstrated that the Actor model is. However, I believe Hewitt assumes infinite queues. As always, infinity gives quite a bit of leeway.

> GHC isn't even close to "pure lambda calculus"

Well I reckon you're using a "strict" definition of pure and I'm using a "lazy" one.. ;) Let's say Haskell-the-language is on the purer side of things and GHC-the-compiler by necessity closer to the messy not-so-pure real-world-er side of programs that run acceptably speedily reliably and sturdily most-of-the-time..

(IO monad "while used by the coder" seems plenty pure to me other than the background knowledge that eventually with a `main` entry point it will become hooked up with actual I/O.. but that's "semantics" hehe)

Alright, then -- I think we agree for all practical purposes :).

Still, I think it is important to realize that while "IO" is 'sort-of-a-monad'... the truth isn't quite that simple :). There's a lot of nastiness hidden behind it, especially FFI and exception-related things... ugh.

EDIT: My original point was mostly that maybe he hadn't thought this whole "async every method call!" thing through. That... leads to a mess, especially if every single "thing" you do is a "method call".

It looks like what you're trying to say is that the difference between theory and practice is that in theory there isn't any but in practice there is.

(Someone else said this, not me)

Well as people using Erlang can say, this is not a big problem. The real question is, how much of your code really need to be simple procedure call. The answer is, not that much. Interestingly.

>AFAIUI from a recent talk by Alan Kay his original intention was that communication would be async ..

This talk maybe ?

https://www.youtube.com/watch?v=fhOHn9TClXY

> but it's definitely not good for simple procedure calls

From TFA:

"With each object having around 96KB of private memory to itself, we would probably be looking at coarser-grained objects, with pure data being passed between the objects (Objective-C or Erlang style) and possibly APL-like array extensions (see OOPAL)."

So coarser-grained objects/actors. And yes, Alan Kay very definitely intended OO at a higher level than "method calls".

Alan Kay:

"Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS." "I invented the term Object-Oriented and I can tell you I did not have C++ in mind."

In fact, he would probably object to the terminology "method calls", because it is just thinly wrapped procedural programming.

"Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word -- ma -- for "that which is in between" -- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas.

If you focus on just messaging -- and realize that a good metasystem can late bind the various 2nd level architectures used in objects -- then much of the language-, UI-, and OS based discussions on this thread are really quite moot. This was why I complained at the last OOPSLA that -- whereas at PARC we changed Smalltalk constantly, treating it always as a work in progress -- when ST hit the larger world, it was pretty much taken as "something just to be learned", as though it were Pascal or Algol. Smalltalk-80 never really was mutated into the next better versions of OOP. Given the current low state of programming in general, I think this is a real mistake.

I think I recall also pointing out that it is vitally important not just to have a complete metasystem, but to have fences that help guard the crossing of metaboundaries. One of the simplest of these was one of the motivations for my original excursions in the late sixties: the realization that assignments are a metalevel change from functions, and therefore should not be dealt with at the same level -- this was one of the motivations to encapsulate these kinds of state changes, and not let them be done willy nilly. I would say that a system that allowed other metathings to be done in the ordinary course of programming (like changing what inheritance means, or what is an instance) is a bad design. (I believe that systems should allow these things, but the design should be such that there are clear fences that have to be crossed when serious extensions are made.)

I would suggest that more progress could be made if the smart and talented Squeak list would think more about what the next step in metaprogramming should be -- how can we get great power, parsimony, AND security of meaning?"

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

> With each object having around 96KB of private memory to itself

For reference/comparison, by default with SMP and HiPE enabled an Erlang process is initialised at 338 words, including 233 words of heap memory (which contains the stack and will increase as needed) and the rest being process meta-information.

96KB private memory means you'd probably want to have "nursery" cores and process migration.

{_, mem} = :erlang.process_info(spawn(fn -> 1 + 1 end), :memory)

mem -> 2720 bytes (~2.7kb)

Which is pretty close to 338 words on a 64bit system (338*8). Looks like it's taking 2 extra words there though. Curious.

    Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
    Eshell V8.1  (abort with ^G)
    > {memory, Mem} = erlang:process_info(spawn(fun () -> 1 + 1 end), memory).
    {memory,2704}
    > Mem div erlang:system_info(wordsize).
    338

338 words is what the "Advanced: Memory" guide lists: http://erlang.org/doc/efficiency_guide/advanced.html

> Erlang process 338 words when spawned, including a heap of 233 words.

However note that this is with HiPE and SMP enabled (which afaik are now the default) as the "processes" guide notes[0] without both of these a process should be 309 words. Without SMP, I get 320 words (HiPE is a compilation flag and I don't feel like recompiling Erlang right now).

[0] http://erlang.org/doc/efficiency_guide/processes.html