<div class="gmail_quote">On 23 January 2012 02:00, Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch" target="_blank">timon.gehr@gmx.ch</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
<a href="http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang" target="_blank">http://programmers.<u></u>stackexchange.com/questions/<u></u>112417/real-world-<u></u>applications-of-erlang</a></blockquote>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
C# is awesome because it gets this right. I think that's its single<br>
greatest achievement, and can not be understated.<br>
<br>
</blockquote>
<br></div>
I couldn't find any information about a C# API for the same functionality. Can you help me out?<br></blockquote><div><br></div><div>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.</div>
<div>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.</div>
<div><br></div><div>If I: send(tid, myThing);<br>I expect to: myThing = receive!SomeThing();</div><div><br></div><div>How can you argue that it's not intuitive to receive what you sent?</div><div>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.</div>
<div>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.</div>
<div>
<br></div><div>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().</div>
<div><br></div><div>On 23 January 2012 02:55, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On Sunday, January 22, 2012 23:18:46 Manu wrote:<br>> On 22 January 2012 18:42, Sean Kelly <<a href="mailto:sean@invisibleduck.org" target="_blank">sean@invisibleduck.org</a>> wrote:<br>> > The popularity of a language has no bearing on the quality of one of its<br>
> > features. Are there other message passing schemes you prefer?<br>><br>> As said in the original post, I think receiveOnly() is the most intuitive<br>> API. I just think that one should be named receive(), and perhaps receive()<br>
> may be renamed receiveMulti(). Surely that would be more intuitive to more<br>> people?<br><br></div>I'm not sure that that's true. But since you have to read the docs before<br>using _any_ of it, I don't see it as an issue.</blockquote>
<div><br></div><div>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.</div>
<div><br></div></div><div><br></div><div>Anyway, it's irrelevant, Andrei has spoken :)</div><div><br></div><div>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.</div>
<div><div><br></div><div>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.</div>
<div>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.</div>
<div><br></div>I simply expect more these days. You can call me whatever you like :)</div></div>