On 22 January 2012 18:42, Sean Kelly <sean@invisibleduck.org> wrote:

> The popularity of a language has no bearing on the quality of one of its features. Are there other message passing schemes you prefer?
>

As said in the original post, I think receiveOnly() is the most intuitive
API. I just think that one should be named receive(), and perhaps receive()
may be renamed receiveMulti(). Surely that would be more intuitive to more
people?
Also both Only and Multi varieties should have a Timeout version, and I
would love to see a poll()/pollMulti() function.

On 1/22/12 3:18 PM, Manu wrote:
> On 22 January 2012 18:42, Sean Kelly <sean@invisibleduck.org
> <mailto:sean@invisibleduck.org>> wrote:
>
>     The popularity of a language has no bearing on the quality of one of
>     its features. Are there other message passing schemes you prefer?
>
>
> As said in the original post, I think receiveOnly() is the most
> intuitive API. I just think that one should be named receive(), and
> perhaps receive() may be renamed receiveMulti(). Surely that would be
> more intuitive to more people?

Names will not change.

> Also both Only and Multi varieties should have a Timeout version, and I
> would love to see a poll()/pollMulti() function.

This is sensible. You may want to add functions through pull requests, or make enhancement requests on bugzilla.


Thanks,

Andrei

On Thursday, 19 January 2012 at 22:36:17 UTC, Sean Kelly wrote:
> Thanks :-)  If you have ideas on how it could be improved, please let me know.

I don't know whether it's good or not, but in my system based on std.concurrency:
* i had to add in-thread messaging in case when there will be more actors than threads
* needed to have possibility of sending multiple types of messages, but ignoring these, not listened to (rather than throwing messageMismatch). IMHO there should be no message buffering, and throwing messages not listened on.
* had to define some possibility of thread discharging, based on constraints fired after each in-thread message handling
   void poll(bool delegate(Variant msg) condition);
   void poll(bool delegate() condition);
* needed to implement some form of message filters (like windows file system minifilters), which might sequentially act with blocking or passing message for multiple-listeners handling

i still need to add:
* because every message might have multiple listeners, it should be read only and shared between them
* there should be some kind of standard scheduler, which could be replaced later

Anyways, i think it's a great model of multithreading, and enjoyed working with std.concurrency.

On 22 January 2012 23:34, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org
> wrote:

> On 1/22/12 3:18 PM, Manu wrote:
>
>> On 22 January 2012 18:42, Sean Kelly <sean@invisibleduck.org
>>
>> <mailto:sean@invisibleduck.org**>> wrote:
>>
>>    The popularity of a language has no bearing on the quality of one of
>>    its features. Are there other message passing schemes you prefer?
>>
>>
>> As said in the original post, I think receiveOnly() is the most
>> intuitive API. I just think that one should be named receive(), and
>> perhaps receive() may be renamed receiveMulti(). Surely that would be
>> more intuitive to more people?
>>
>
> Names will not change.


Why? Surely API's being as intuitive as possible should be a key goal for a
standard library?
The thing isn't supposed to be stable yet is it? If you take the attitude
that no name should ever be changed, then I think there is a problem with
the phobos contribution process.
Phobos contributions have basically no incubation time/process. I've seen
others suggest new stuff should go in exp.xxx to incubate, and it should
only be promoted to std after some time, or some successful usage in
multiple large-ish projects?
It's a shame that basic usability things like that couldn't be caught
earlier.

Do you disagree that receive() and receiveMulti() (with the crazy
var-arg-of-delegates API that nobody would have ever seen in any popular
language before) is a far more intuitive approach?
C# is awesome because it gets this right. I think that's its single
greatest achievement, and can not be understated.

Also both Only and Multi varieties should have a Timeout version, and I
>> would love to see a poll()/pollMulti() function.
>>
>
> This is sensible. You may want to add functions through pull requests, or make enhancement requests on bugzilla.
>

Shall do one or the other.

The names as they exist match what's in TDPL, so they're somewhat set in stone.

Sent from my iPhone

On Jan 22, 2012, at 3:05 PM, Manu <turkeyman@gmail.com> wrote:

> On 22 January 2012 23:34, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 1/22/12 3:18 PM, Manu wrote:
> On 22 January 2012 18:42, Sean Kelly <sean@invisibleduck.org
> 
> <mailto:sean@invisibleduck.org>> wrote:
> 
>    The popularity of a language has no bearing on the quality of one of
>    its features. Are there other message passing schemes you prefer?
> 
> 
> As said in the original post, I think receiveOnly() is the most
> intuitive API. I just think that one should be named receive(), and
> perhaps receive() may be renamed receiveMulti(). Surely that would be
> more intuitive to more people?
> 
> Names will not change.
> 
> Why? Surely API's being as intuitive as possible should be a key goal for a standard library?
> The thing isn't supposed to be stable yet is it? If you take the attitude that no name should ever be changed, then I think there is a problem with the phobos contribution process.
> Phobos contributions have basically no incubation time/process. I've seen others suggest new stuff should go in exp.xxx to incubate, and it should only be promoted to std after some time, or some successful usage in multiple large-ish projects?
> It's a shame that basic usability things like that couldn't be caught earlier.
> 
> Do you disagree that receive() and receiveMulti() (with the crazy var-arg-of-delegates API that nobody would have ever seen in any popular language before) is a far more intuitive approach?
> C# is awesome because it gets this right. I think that's its single greatest achievement, and can not be understated.
> 
> Also both Only and Multi varieties should have a Timeout version, and I
> would love to see a poll()/pollMulti() function.
> 
> This is sensible. You may want to add functions through pull requests, or make enhancement requests on bugzilla.
> 
> Shall do one or the other.

On 01/23/2012 12:05 AM, Manu wrote:
> On 22 January 2012 23:34, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 1/22/12 3:18 PM, Manu wrote:
>
>         On 22 January 2012 18:42, Sean Kelly <sean@invisibleduck.org
>         <mailto:sean@invisibleduck.org>
>
>         <mailto:sean@invisibleduck.org
>         <mailto:sean@invisibleduck.org>__>> wrote:
>
>             The popularity of a language has no bearing on the quality
>         of one of
>             its features. Are there other message passing schemes you
>         prefer?
>
>
>         As said in the original post, I think receiveOnly() is the most
>         intuitive API. I just think that one should be named receive(), and
>         perhaps receive() may be renamed receiveMulti(). Surely that
>         would be
>         more intuitive to more people?
>
>
>     Names will not change.
>
>
> Why? Surely API's being as intuitive as possible should be a key goal
> for a standard library?

Another key goal is that an API should be as concise and powerful as possible. Furthermore, the API is very intuitive once you glimpsed over the documentation.

> The thing isn't supposed to be stable yet is it? If you take the
> attitude that no name should ever be changed, then I think there is a
> problem with the phobos contribution process.

He said 'Names will not change' not 'All names never change'.

> Phobos contributions have basically no incubation time/process. I've
> seen others suggest new stuff should go in exp.xxx to incubate, and it
> should only be promoted to std after some time, or some successful usage
> in multiple large-ish projects?
> It's a shame that basic usability things like that couldn't be caught
> earlier.

Erlang *has* been used in multiple large projects and it is likely that you make use of some service that is powered by erlang on a daily basis. It is successful in its niche. Copying its message passing API is reasonable and safe: Its concurrency model is the main selling point of erlang.

http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang

>
> Do you disagree that receive() and receiveMulti() (with the crazy
> var-arg-of-delegates API that nobody would have ever seen in any popular
> language before) is a far more intuitive approach?

Yes.

> C# is awesome because it gets this right. I think that's its single
> greatest achievement, and can not be understated.
>

I couldn't find any information about a C# API for the same functionality. Can you help me out?

On Sunday, January 22, 2012 23:18:46 Manu wrote:
> On 22 January 2012 18:42, Sean Kelly <sean@invisibleduck.org> wrote:
> > The popularity of a language has no bearing on the quality of one of its features. Are there other message passing schemes you prefer?
> 
> As said in the original post, I think receiveOnly() is the most intuitive
> API. I just think that one should be named receive(), and perhaps receive()
> may be renamed receiveMulti(). Surely that would be more intuitive to more
> people?

I'm not sure that that's true. But since you have to read the docs before using _any_ of it, I don't see it as an issue. You have to understand it before you can use it, and if you understand it, what's it matter if it's receiveOnly and receive instead of receiveOneOf and receive?

The problems with std.concurrency have not been its design but its lack of documentation (which Sean has apparently improved - though I haven't looked at it yet, so I can't comment), and the fact that it doesn't work correctly with shared. It would be valuable to be able to say that you're _moving_ a value across such that the current thread doesn't own it anymore, but that's really a language issue, not an issue with std.concurrency.

The naming strikes me as bikeshedding. The names work as they are.

- Jonathan M Davis

On 23 January 2012 01:49, Sean Kelly <sean@invisibleduck.org> wrote:

> The names as they exist match what's in TDPL, so they're somewhat set in stone.
>

Ah, I see. That makes it considerably harder to go back on then :)

On 23 January 2012 02:00, Timon Gehr <timon.gehr@gmx.ch> wrote:

> Erlang *has* been used in multiple large projects and it is likely that you make use of some service that is powered by erlang on a daily basis. It is successful in its niche. Copying its message passing API is reasonable and safe: Its concurrency model is the main selling point of erlang.
>
> http://programmers.**stackexchange.com/questions/**112417/real-world-** applications-of-erlang<http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang>


Oh come on.. It's niche, unfamiliar to most people, and we're talking about name and argument list clarity with respect to what would be instinctive to the most users, not 'model' or API design, that's obviously fine.

C# is awesome because it gets this right. I think that's its single
>> greatest achievement, and can not be understated.
>>
>>
> I couldn't find any information about a C# API for the same functionality. Can you help me out?
>

I'm not referring to this API in particular, I'm referring to the fairly
universal application of the principle within the C# libraries. Most people
I've ever talked to agree that one of it's biggest selling points, and
possibly even the key reason they use it; because it was so accessible and
productive from the instant they tried it out.
You shouldn't need to read anything. Pressing '.' in the IDE shows lists of
classes/methods/etc, and common sense writes your code. This requires that
the function names make perfect sense, and the argument lists are as you
intuitively expect.

If I: send(tid, myThing);
I expect to: myThing = receive!SomeThing();

How can you argue that it's not intuitive to receive what you sent?
There's nothing in: send(tid, something); that suggests the expected
compliment API should take a var-arg list of undefined things. It's not
clear from receive()'s signature that it should receive delegates, it looks
like it could receive anything. The delegate signature is un-knowable from
the functions own signature, nor what the delegates are even supposed to do.
Also, the name 'receiveOnly' doesn't actually make sense unless you
*already know* that receive() is effectively receiveMulti. If I was
scrolling through the pop-up list of methods, I would not confidently
predict what that does.

You MUST read the docs to understand receive(), and that is an instant fail
for my money. You don't need to read the docs to understand receiveOnly(),
it's perfectly obvious what it does and how it works on sight, and matches
what you expect as the natural complement to send().

On 23 January 2012 02:55, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, January 22, 2012 23:18:46 Manu wrote:
> > On 22 January 2012 18:42, Sean Kelly <sean@invisibleduck.org> wrote:
> > > The popularity of a language has no bearing on the quality of one of
> its
> > > features. Are there other message passing schemes you prefer?
> >
> > As said in the original post, I think receiveOnly() is the most intuitive
> > API. I just think that one should be named receive(), and perhaps
> receive()
> > may be renamed receiveMulti(). Surely that would be more intuitive to
> more
> > people?
>
> I'm not sure that that's true. But since you have to read the docs before using _any_ of it, I don't see it as an issue.


My argument is that you shouldn't have to read the docs AT ALL to access basic functionality. I say "how do I create a worker thread?", and someone in the office answers "use std.concurrency", I type std.concurrency and press '.', everything I care about appears, and if it's designed correctly, a momentary glance will have me headed in the right path. It also reflects on why I really hate seeing 'auto' used in sample code.


Anyway, it's irrelevant, Andrei has spoken :)

I'm really not just trying to be a picky bastard for the sake of it... it's a genuine red flag for me. And I'm not just raising the point for this single example, I think this should be a basic principle applied universally. Every API, before being accepted, should be scrutinised; does the name make perfect sense given conventional presumptions of the system? do the args/template args appear obvious? At very least just for the key/fundamental parts of the API. Advanced functionality is sure to exist, can/should have more specific names, and will probably require looking up the docs, sure.

I'm not a hobbyist looking to play with a new toy, I'm trying to be
genuinely realistic about what I expect with respect to what else is out
there. And it's not hard. For the most part, language-wise, D delivers the
goods. The library needs polish, but I think everyone knows that.
C# has raised the bar, this issue, so trivial as the name/args of the
function, lost D a significant number of points at face value with me after
it wasted my time and forced me to read the fairly sub-standard docs.

I simply expect more these days. You can call me whatever you like :)

On 01/25/2012 11:49 AM, Manu wrote:
...
>
> My argument is that you shouldn't have to read the docs AT ALL to access
> basic functionality. I say "how do I create a worker thread?", and
> someone in the office answers "use std.concurrency", I type
> std.concurrency and press '.', everything I care about appears, and if
> it's designed correctly, a momentary glance will have me headed in the
> right path. It also reflects on why I really hate seeing 'auto' used in
> sample code.

Except that for 'worker thread' the guy in the office will presumably answer "use std.parallelism". You were presumably not using the most appropriate tool for the job.