Comments on Unlimited Novelty: Why I don't like Scala

> The WTF Operator > response = receiver !? reques...

2009-04-17T23:26:33.338-07:00

> The WTF Operator
> response = receiver !? request

Don't forget that !? is a method call, not an operator because Scala has no operators (only methods). It's just that the dot and parens are optional. If the implementers of the actors library would have chosen a name other than !? for the method, it would look something like so:

response = receiver.sendSynchronous(request)
or equivalently
response = receiver sendSynchronous request

I guess they just opted for brevity.

To your point "One type of actor is based on nat...

2009-04-16T19:37:53.879-07:00

To your point

"One type of actor is based on native threads. However, native threads are substantially heavier than a lightweight Erlang process, limiting the number of thread-based actors you can create in Scala as compared to Erlang."

Why do you conclude every Java/Scala thread maps to Native thread? To my knowledge native threads are heavy weights in case of Linux and not for Windows (read Fibers) or other Flavours of Unix (Solaris maps Green user-space threads to native threads). Whenever I hear argument which results in "Let's Implement our own", I start to suspect suboptimality in approach, operating systems are best at what they do. Technically speaking, Your Erlang runtime will never execute in Kernel mode and it can't beat process scheduler performance. In such cases synchronous invocation is your best bet. However, I have to agree that a nonsense parameter to imply synchronous invocation doesn't sound like a rocket science feature in supporting distributed computing, it should be transparent to developer. Distributed programming semantics existed forever that did not introduce silly operators to indicate type of invocation(COM, RMI and whatnot). This is 21st century we want to free developers from thinking about distribution much less the programming language constructs to specify synchronous execution.

You seem to be complaining about Scala actors, and...

2009-04-16T06:52:50.259-07:00

You seem to be complaining about Scala actors, and the JVM's object model. Scala actors are just a library, and probably most Scala programmers don't use them. For Scala not to use the JVM's object model, it would have to sacrifice performance and reasonable Java compatibility.

Hmm my link didn't seem to work properly. It's htt...

2009-04-15T17:43:23.387-07:00

Hmm my link didn't seem to work properly. It's http://www.ne-fat-s.org/objactor/index.html

Some time ago I adapted the actor system in Scala ...

2009-04-15T17:38:10.098-07:00

Some time ago I adapted the actor system in Scala to be OO, it seems relevant to your post.

objactorsNot that I think that this (or actors in general) are a particularly good approach.

In my solution returning method calls are synchronous - if you want to respond asynchronously you have to call the caller.

20 years ago I used to work on ActTalk, an Actor e...

2009-04-15T06:25:50.298-07:00

20 years ago I used to work on ActTalk, an Actor extension to Smalltalk. It had a nice and simple design. That was due to the highly dynamic capabilities of the Smalltalk language.

I wonder if we could do the same with Groovy today...

> Scala hybrid functional/imperative object/actor ...

2009-04-10T06:21:23.922-07:00

> Scala hybrid functional/imperative object/actor language

This is Scala's amazing strength - it fooled you! Scala is not an actor language any more than Java is. But it has a library that looks like a part of the language.

Otherwise, your comments are pretty much spot on. If you need to do hardcore concurrency and the Erlang ecosystem fits your needs, it's hard to do better than using the Erlang platform.

However, one quibble. Scala is hybrid "functional/imperative" exactly the same way Erlang, Scheme, Common Lisp, Clojure, SML, OCaml, and many others are. All of these are imperative in the way they deal with IO and other side effects like mutation.

Pichi,I just submitted a writeup of what I believe...

2009-04-08T20:03:37.950-07:00

Pichi,

I just submitted a writeup of what I believe your proposal to be to the Reia Google Group:

http://groups.google.com/group/reia/browse_thread/thread/808524369028e6b3

That might be a better place to continue this rather than my blog.

It is the most interesting proposal so far, and one I'm considering. I'm worried about how it muddies hidden state and allows for outside processes to cause side effects in the middle of method dispatch.

That said deadlocks are much worse.

For what I can infer about your comments, the acto...

2009-04-08T08:11:36.209-07:00

For what I can infer about your comments, the actor model is embedded in the core of your language. Actors in Scala, on the other hand, are just a library implemented in Scala. The fact that they can be integrated seamlessly shows the power of Scala language. On the other hand, I think Scala is a general purpose language, I'll never try to do in Scala the things Erlang is desinged for.

I found above approach little bit confusing. In pr...

2009-04-08T06:47:10.494-07:00

I found above approach little bit confusing. In programmers point of view this can happen (Excuse I'm not familiar with Reia syntax)

class A:
...
  def MA1 (B):
    a=self.p1;
    b=B.MB1();
    c=self.p1;
    if a!=c then
      print "This can happen because any other method of A can be performed during B.MB1()!"

Funny, isn't it?

I don't like "two process" solution too.About stat...

2009-04-08T01:27:00.980-07:00

I don't like "two process" solution too.

About state:

All starts from main process. Object A is made in some state SA1. Object B is made in some state SB1. Main process calls method MA1 of object A and waits (receive) for response. In method handler of object A is state changed to SA2 and called method MB1 of object B (PID passed as argument of method) and waits (receive) for response. This receive is also able to handle another calls. In method MB1 of object B is changed state SB1 to SB2 and called method MA2 or MA1 but with another parameters which will not cause call to B again. Receive clause in object A will accept this call but fun goes here. Process of object A must store "continuation" (push on stack) where information about method MA1. Object A handles MA2 and changes to state SA3 and responses to object B and returns to "continuation" state but with state SA3. (I think it is way how object behaves in OOP. There is variant with state SA2 but I think it is wrong.) Object B changes state to SB3 and responses to object A. Object A receives response, continues in method MA1, changes state to SA4 and returns response to main process.

There is possible infinite loop but in same case as in classical OOP.

P.S.: I'm embarrassed when helping implement concept which I think is wrong ;-)

Also, I don't like "two process" solutions to hand...

2009-04-07T15:36:05.920-07:00

Also, I don't like "two process" solutions to handling "reentrant" calls to an object which is calling out elsewhere.

What do you do with the state? The caller has one copy... if you try to call it again the call will be handled by another process...

What if that process changes the state while the caller is still calling out? The caller is then working off a different copy of the state. You have two states, one from when it answered the first request, and one from the second. Which one should be the "new" state?

It just doesn't work that way, unfortunately.

Reia has the equivalent of gen_server cast as well...

2009-04-07T10:02:20.837-07:00

Reia has the equivalent of gen_server cast as well. The syntax is:

receiver<-method(arg1, arg2, ...)

It's still left as an exercise to the programmer to decide when to use calls and when to use casts. If you decide wrong, you risk deadlocking.

When I think about call graph problem I have thoug...

2009-04-07T08:55:18.997-07:00

When I think about call graph problem I have though about one way of solution. When object process (actor) waits for result of call (request) it can accept another's object calls. When call comes it stores current state as some kind of "continuation", serve call and returns to "continuation" which hangs in receive clause again. It introduce some kind of process "stack" of "continuations". Hard thing comes how handle object "state" trough multiple "continuations" on "stack". It's big challenge

Same problem you can found with normal Erlang programing using gen_server or gen_fsm when your handler involves call to another gen_* process but Erlang system are usually designed to avoid this problem (for example using cast instead call).

Anyway I think OOP is broken by design ;-)