On Jan 25, 2012, at 2:49 AM, Manu wrote:

> 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
> 
> 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.

Personally, I expected receiveOnly to see infrequent use compared to receive.  At least in my own code, it's rare that I'd want a receive call to throw if there's any message in the queue other than the one I'm looking for.  So the naming scheme was a mistaken assumption of popular use.


> 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?

We could overload receive even more so that if it has only one argument and that argument is not a callable type, it does receiveOnly.  That might be deceptive however.  What I like about "receiveOnly" is that the name itself suggests that anything other than the specified type is not expected, and so some measure will probably be taken.  receive!T says to me "look for a message of this type and block if it's not present."


> 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.

This is an artifact of templates.  I doubt C# has this issue because C# doesn't have templates.


> 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.

Matter of opinion I suppose.  See above.

On 01/26/2012 09:07 PM, Sean Kelly wrote:
> On Jan 25, 2012, at 2:49 AM, Manu wrote:
>
>> 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
>>
>> 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.
>
> Personally, I expected receiveOnly to see infrequent use compared to receive.  At least in my own code, it's rare that I'd want a receive call to throw if there's any message in the queue other than the one I'm looking for.  So the naming scheme was a mistaken assumption of popular use.
>

It is not necessarily a mistaken assumption. I still assume it.

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

> On Jan 25, 2012, at 2:49 AM, Manu wrote:
>
> > 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
> >
> > 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.
>
> Personally, I expected receiveOnly to see infrequent use compared to receive.  At least in my own code, it's rare that I'd want a receive call to throw if there's any message in the queue other than the one I'm looking for.  So the naming scheme was a mistaken assumption of popular use.
>

Well perhaps my usage is biased, but I think many/most threads are spawned
with the intent of receiving one particular workload from one source. I
think a thread that receives a variable/dynamic workload is probably less
common, although certainly does exist, but regardless of that, from the
point of view of API design, I don't think the API clearly communicates
that intent. It certainly had me scratching my head until I _read the
docs_, which is the basis of my argument.
If I'm wrong on that point, then there's nothing to argue :)

(bear in mind, this isn't the only thing I mentioned in my OP. As with prior posts where I've made the mistake of listing things, the the single most trivial detail in my list is the one that spawns the longest conversation ;)

> 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?
>
> We could overload receive even more so that if it has only one argument and that argument is not a callable type, it does receiveOnly.  That might be deceptive however.


I agree that's a pretty ugly approach. I can see your point, but it only makes sense to me with advanced knowledge of the API. If I approach it without that insight, as I did, it's not so clear, or even misleading. Consider the position you're likely to be when you reach for the API, trying to use it for the first time, and you've just typed: send(tid, myThing) not 10 seconds prior... what do you expect to type next?


> What I like about "receiveOnly" is that the name itself suggests that anything other than the specified type is not expected, and so some measure will probably be taken.


Again, this only makes sense to me if you already expect that the act of receiving (as a compliment to the send API, which you've already invoked and have a presumption about), was capable of receiving any/multiple things, rather than receiving what you just sent a few lines back...

 receive!T says to me "look for a message of this type and block if it's
> not present."
>

Perfect. It says that to me too. I'm lost now though, this is the behaviour of receiveOnly... are you agreeing now? :)

> 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.
>
> This is an artifact of templates.  I doubt C# has this issue because C# doesn't have templates.
>

C# has generics. Not quite like D templates, more like C++, but still... But in a case like this, such an apparently arguably ambiguous API wouldn't be permitted. It would be restructured, or the competing API's both renamed to something more clear.

> 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.
>
> Matter of opinion I suppose.  See above.


Perhaps so. I suppose my mental flow was by drawing a direct contrast to the send() API, which I called not 10 seconds prior, before trying to type my receive code.


Anyway, I think it's a void topic in this instance, it's been stated that
it will not change, I'm good with that.
I was just trying to raise the point that I think more care should be taken
to the end that the standard library (across the board, not just in this
case) should be indisputably intuitive, and with particular consideration
to auto-complete listings, which should be self evident enough to do most
basic functionality a system offers.

On 01/26/2012 10:19 PM, Manu wrote:
>
> C# has generics. Not quite like D templates, more like C++, but still...

C# generics and C++/D templates are *very* different things. C# generics make code type check (and duplicate static variables), templates duplicate the whole code. C# does not have anything like templates.

Templates have the benefit that they are a lot more powerful, generics have the benefit that they can be type checked modularly and generic functions can be virtual.

On Jan 26, 2012, at 1:19 PM, Manu wrote:

> On 26 January 2012 22:07, Sean Kelly <sean@invisibleduck.org> wrote:
> 
> What I like about "receiveOnly" is that the name itself suggests that anything other than the specified type is not expected, and so some measure will probably be taken.
> 
> Again, this only makes sense to me if you already expect that the act of receiving (as a compliment to the send API, which you've already invoked and have a presumption about), was capable of receiving any/multiple things, rather than receiving what you just sent a few lines back...
> 
>  receive!T says to me "look for a message of this type and block if it's not present."
> 
> Perfect. It says that to me too. I'm lost now though, this is the behaviour of receiveOnly... are you agreeing now? :)

It's only the behavior of receiveOnly if the queue is completely empty.  If it contains any other message, receiveOnly will throw.  But from what you've said I think this is simply a difference in how we design apps.  For me, it's common to send multiple message types.  For you, it sounds like it is not.