Why has the actor model not succeeded? (1997) | Hacker News Reader

Why has the actor model not succeeded? (1997)

doc.ic.ac.uk

26 pointsb-man18 comments

Perhaps this is simplistic, but I believe it has succeeded in the form of web APIs/REST/etc.

NB: This was from 1997.

"""The actor model has no direct notion of inheritance or hierarchy, which means it is time consuming and confusing to program actors with trends of common behaviour."""

Mozart/oz allows you to easily implement actors which also have OO inheritance.

Generally, many superior programming paradigms (logic, constraint, functional, concurrent) have been ignored by the computing industry which has probably cost it billions of dollars in lost productivity.

The Io language has both actors and prototype based OO inheritance. Asynchronous messages are implemented using futures.

Furthermore: ""When an actor requires a reply message from another actor, it is known as an insensitive actor, and will not process any further messages in its mail queue until it receives that reply.""

Why must this be so? In Io, the same objects/actors can run other coroutines while waiting on a message.

Just because no language happened to implement all of these in the 1970s and does not mean no language could have implemented them. In the concluding paragraph the author does go on to say that it is now possible to do all these, but I disagree with his implication that it is advancements in technology that made it happen. A more likely explanation is simply that programming languages are notation, advancements in notation do not follow the exponential curve of Moore's law, and it simply took this long for people to think of combining all these concepts in one notation.

Billions? I think you're underestimating by several orders of magnitude.

Seems reasonable. Null pointers are rumored to have cost billions in waste and failures. And they're trivial to fix with a little bit of static typing.

Not sure I would call it "trivial." You just trade your segfault (or NullPointerException) for a pattern match error.

Although that little bit of static typing would probably have dealt with the vast majority of expensive null-pointer bugs.

Well, trivial in relation to a company rebuilding its product on a new programming language or paradigm.

The pattern match error can be detected at compile time. The NPE is not.

Not if you enable compiler errors for inexhaustive matches. Are there any compilers for mainstream languages that can flag all possible segfault/NPE locations as errors?

That's probably an intractable problem.

Regarding billions of dollars in lost productivity, and having done ten years in an enterprise, I don't think the large expenditures (called spend in the jargon) can be attributed to language choice. I think you need to look a lot deeper than that, particularly to the culture of the organization. One factor that prevents programming language choice having a deep impact is the pervasive cultural allergy to programming. This results in not really seeking out or nurturing high-productivity programmers and programming efforts.

An additional example of that symptom was an article posted here in the last couple of weeks that said effectively "To improve your IT career, learn to negotiate with vendors." This is to me is a problem orthogonal to the choice of language or development practice.

For another take on this, consider all the interviews in Coders at Work. These are at the top of list of productive programmers of today. Some of them wrote in C, some despised C++ and C, none were methodologists.

I am one of the people who has not bothered to learn about the "actor model" and thus perhaps lost billions... Why? Because it smells of needless complexity, just like XML, Java, Haskell, and everything Microsoft touches.

I think for a technology (or at least a language) to go viral it needs either (1) lots and lots of money (Java for PR, VBA because of the $$$ MS ecology) or (2) a fairly genius level combination of power and simplicity (C, and why Tcl/Tk won't quite die...).

The actor model, functional programming, blah blah blah, have neither enough money behind them to make them happen, nor the magic balance of simplicity and expressiveness such that that a smart 17 year old can spend a weekend learning them and then begin writing apps that had been impossible before said language (lua, for example).

So ... keep trying ;)

As someone who has learned a bit about the actor model, I think it actually simplifies one's life a great deal, in terms of writing concurrent programs.

Well done sir troll, well done...

Might I suggest that you look into a language with Actors before saying that Actors are difficult to figure out? Personally, I'm a huge fan of Io[1], which uses Actors extensively.

Io has an incredibly minimal syntax that you (or any smart 17 year old) should be able to pick up in under a weekend - less time, if you/they have experience with a language that uses prototypical inheritance (such as JavaScript). This is pretty big, since the language doesn't impose itself or get in the way of any of the concepts that you're working with, to potentially confuse you.

With Io, if you've cloned an object, you have an actor that can perform asynchronous actions for you. Its as simple as:

  foo := self @bar // asynchronous actor that returns a Future.

[1] http://iolanguage.com/

See http://iolanguage.com/ for a magical balance of simplicity and expressiveness

The most famous actor-model language, Erlang, was designed primarily for phone networks. How would you create a system of millions of nodes with fault-tolerant, hot-swappable, gradually-updatable code without actors? (Keeping in mind that REST is an example of the actor model.)

Reply on news.ycombinator.com