Message-Passing

[Manu]

On 23 January 2012 02:00, Timon Gehr <timon.gehr at 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 at gmx.com> wrote:

> On Sunday, January 22, 2012 23:18:46 Manu wrote:
> > On 22 January 2012 18:42, Sean Kelly <sean at 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120125/e1ad779b/attachment-0001.html>