This is interesting stuff, but I'm having difficulty wrapping my head around some of it. Here are some thoughts.<p>(1) Prohibiting function return values sounds bizarre at first. It's like anti-functional programming -- <i>insisting</i> on side effects. But eventually I understood the reason: a returned object might have methods called on it. This is bad because such objects are "strangers" (in the LoD sense); we should not talk to them.<p>I guess the point is that traditional OO and functional style do not mix well. You can do state-modifying OO stuff, or you can work entirely with return values; you mix the two at your peril.<p>Or maybe the real problem is the everything-is-a-mutable-object idea. Applying these ideas to programming in C++, we could return an int without fear, since there are no methods to be called on it. We could also return a const object (I think ...). In Python, we could return anything immutable: integer, string, tuple, frozenset, etc.<p>(2) Concerning error handling, I see that prohibiting return values (which also forbids raising exceptions, I guess), makes it difficult for a function to signal errors to the caller. However, I do not agree that such signalling becomes <i>impossible</i>. A method is allowed to modify its arguments; it can signal an error that way.<p>But I'm a bit leery of the idea that requiring every function to handle its own errors, will result in more robust code. The argument seems to be that, since you have to write the error handling at the same time you're writing the code that produces the error, you're more likely to get it done. I'm not sure of that. I think the main trouble with error handling is that it requires work, and most of us don't really want to do that work. If a certain discipline helps motivate one person to write proper error handling, well, good, but it may not effectively motivate another person.<p>To put it another way: these ideas make some kinds of error handling more difficult. Does making something more difficult help it to get done?<p>But I haven't really thought this particular issue through. Prohibiting error signalling is going to have significant effects on software architecture at all levels. Some abstractions will simply be impossible, since they do not have all the information necessary for the handling of their own errors. I'm not at all sure what these effects might look like.<p>(3) Then there are the timing issues.<p>> There cannot be tight synchronization, as the sender cannot tell if the message is acted on or not within any "small" period of time ....<p>I don't get this at all.