www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Message-Passing

reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
I want to applaud Sean Kelly and everyone who worked on std.concurrency 
for a great API, and wish that I could easily write Cocoa applications 
with it.

I'm writing a screen recording program in Objective-C, and to make sure 
each frame has an equal length, I have two threads: one that takes the 
screenshot at certain intervals, the other that assembles it into a 
quicktime movie. After writing an implementation of a thread-safe queue, 
where the picture-taking thread adds and the assembling thread removes, 
I realized the huge similarity between what I'd done and std.concurrency.

The std.concurrency module would have made hours of effort in ObjC take 
five minutes in D. Well done!
Jan 19 2012
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Thanks :-)  If you have ideas on how it could be improved, please let me =
know.

On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:

 I want to applaud Sean Kelly and everyone who worked on =

Cocoa applications with it.
=20
 I'm writing a screen recording program in Objective-C, and to make =

the screenshot at certain intervals, the other that assembles it into a = quicktime movie. After writing an implementation of a thread-safe queue, = where the picture-taking thread adds and the assembling thread removes, = I realized the huge similarity between what I'd done and = std.concurrency.
=20
 The std.concurrency module would have made hours of effort in ObjC =

Jan 19 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-19 21:58, Nathan M. Swan wrote:
 I want to applaud Sean Kelly and everyone who worked on std.concurrency
 for a great API, and wish that I could easily write Cocoa applications
 with it.

 I'm writing a screen recording program in Objective-C, and to make sure
 each frame has an equal length, I have two threads: one that takes the
 screenshot at certain intervals, the other that assembles it into a
 quicktime movie. After writing an implementation of a thread-safe queue,
 where the picture-taking thread adds and the assembling thread removes,
 I realized the huge similarity between what I'd done and std.concurrency.

 The std.concurrency module would have made hours of effort in ObjC take
 five minutes in D. Well done!

I don't know if it's the same but doesn't Objective-C makes that quite simple as well since Mac OS X 10.6 using grand central dispatch: http://en.wikipedia.org/wiki/Grand_Central_Dispatch -- /Jacob Carlborg
Jan 19 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235429d6d8897ebe04b6f56763
Content-Type: text/plain; charset=UTF-8

On 20 January 2012 00:36, Sean Kelly <sean invisibleduck.org> wrote:

 Thanks :-)  If you have ideas on how it could be improved, please let me
 know.

 On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:

 I want to applaud Sean Kelly and everyone who worked on std.concurrency

it.
 I'm writing a screen recording program in Objective-C, and to make sure

screenshot at certain intervals, the other that assembles it into a quicktime movie. After writing an implementation of a thread-safe queue, where the picture-taking thread adds and the assembling thread removes, I realized the huge similarity between what I'd done and std.concurrency.
 The std.concurrency module would have made hours of effort in ObjC take


I had some troubles with std.concurrency which I thought it might be nice to address. Perhaps the most major problem I had was related to the concept of thread ownership. If a spawned threads parent thread dies, it also receives a signal to kill its self, but it seems impossible to reassign ownership. In my case I had threads A, B and C... Thread A is the main thread, which may spawn many temporary worker threads B, which may last 1-2 seconds. During the life of B, it may spawn C, which may persist for hours. B promptly dies, and any C's that were spawned receive the kill signal, which I ignore. Thread A, the main thread may exit, and I would really like all C's to receive that notification, but they were are all orphaned when their B died. The problem is, when I spawn a C, it should be created as a child of A somehow, rather than a child of the transient B... Some mechanism to solve this sort of problem would be useful. Another usability problem I had was that, intuitively, the simpler function with intuitive usage pattern receiveOnly() should be named receive(). And receive() with the complex var-arg list of delegates should be named something more complex. receiveTimeout() has no receiveTimeoutOnly(), which is the function I almost always want to use... and receiveTimeout() didn't actually work for me anyway (it wouldn't receive a duration as per the documentation, I had to pass an int) I wonder if there is a solution to the 'shared' problem. Basically every single line of code that uses the std.concurrenty api is riddled with casts to/from shared... really ugly. I think the problem here is that I'm not SHARING values between threads, I'm actually passing ownership of something to another thread. So I wonder if some improvement can be made in this area. I was going to complain about the documentation, but I just checked, and it seems to have had work since I was reading it. Looks much better now! :) --00235429d6d8897ebe04b6f56763 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 20 January 2012 00:36, Sean Kelly <span dir= =3D"ltr">&lt;<a href=3D"mailto:sean invisibleduck.org">sean invisibleduck.o= rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Thanks :-) =C2=A0If you have ideas on how it could be improved, please let = me know.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:<br> <br> &gt; I want to applaud Sean Kelly and everyone who worked on std.concurrenc= y for a great API, and wish that I could easily write Cocoa applications wi= th it.<br> &gt;<br> &gt; I&#39;m writing a screen recording program in Objective-C, and to make= sure each frame has an equal length, I have two threads: one that takes th= e screenshot at certain intervals, the other that assembles it into a quick= time movie. After writing an implementation of a thread-safe queue, where t= he picture-taking thread adds and the assembling thread removes, I realized= the huge similarity between what I&#39;d done and std.concurrency.<br> &gt;<br> &gt; The std.concurrency module would have made hours of effort in ObjC tak= e five minutes in D. Well done!<br></div></div></blockquote><div><br></div>= <div>I had some troubles with std.concurrency which I thought it might be n= ice to address.</div> <div><br></div><div>Perhaps the most major problem I had was related to the= concept of thread ownership. If a spawned threads parent thread dies, it a= lso receives a signal to kill its self, but it seems impossible to reassign= ownership.</div> <div>In my case I had threads A, B and C...</div><div>=C2=A0 Thread A is th= e main thread, which may spawn many temporary worker threads B, which may l= ast 1-2 seconds.</div><div>=C2=A0 During the life of B, it may spawn C, whi= ch may persist for hours.</div> <div>=C2=A0 B promptly dies, and any C&#39;s that were spawned receive the = kill signal, which I ignore.</div><div>=C2=A0 Thread A, the main thread may= exit, and I would really like all C&#39;s to receive that notification, bu= t they were are all orphaned when their B died.</div> <div>The problem is, when I spawn a C, it should be created as a child of A= somehow, rather than a child of the transient B... Some mechanism to solve= this sort of problem would be useful.</div><div><br></div><div>Another usa= bility problem I had was that, intuitively, the simpler function with intui= tive usage pattern receiveOnly() should be named receive().</div> <div>And receive() with the complex var-arg list of delegates should be nam= ed something more complex.</div><div>receiveTimeout() has no receiveTimeout= Only(), which is the function I almost always want to use... and receiveTim= eout() didn&#39;t actually work for me anyway (it wouldn&#39;t receive a du= ration as per the documentation, I had to pass an int)</div> <div><br></div><div>I wonder if there is a solution to the &#39;shared&#39;= problem.=C2=A0Basically every single line of code that uses the std.concur= renty api is riddled with casts to/from shared... really ugly.</div><div>I = think the problem here is that I&#39;m not SHARING values between threads, = I&#39;m actually passing ownership of something to another thread. So I won= der if some improvement can be made in this area.</div> <div><br></div><div>I was going to complain about the documentation, but I = just checked, and it seems to have had work since I was reading it. Looks m= uch better now! :)</div></div> --00235429d6d8897ebe04b6f56763--
Jan 20 2012
prev sibling next sibling parent "jdrewsen" <jdrewsen nospam.com> writes:
On Friday, 20 January 2012 at 13:10:37 UTC, Manu wrote:
 On 20 January 2012 00:36, Sean Kelly <sean invisibleduck.org> 
 wrote:

 Thanks :-)  If you have ideas on how it could be improved, 
 please let me
 know.

 On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:

 I want to applaud Sean Kelly and everyone who worked on 
 std.concurrency

applications with it.
 I'm writing a screen recording program in Objective-C, and 
 to make sure

takes the screenshot at certain intervals, the other that assembles it into a quicktime movie. After writing an implementation of a thread-safe queue, where the picture-taking thread adds and the assembling thread removes, I realized the huge similarity between what I'd done and std.concurrency.
 The std.concurrency module would have made hours of effort 
 in ObjC take


I had some troubles with std.concurrency which I thought it might be nice to address. Perhaps the most major problem I had was related to the concept of thread ownership. If a spawned threads parent thread dies, it also receives a signal to kill its self, but it seems impossible to reassign ownership. In my case I had threads A, B and C... Thread A is the main thread, which may spawn many temporary worker threads B, which may last 1-2 seconds. During the life of B, it may spawn C, which may persist for hours. B promptly dies, and any C's that were spawned receive the kill signal, which I ignore. Thread A, the main thread may exit, and I would really like all C's to receive that notification, but they were are all orphaned when their B died. The problem is, when I spawn a C, it should be created as a child of A somehow, rather than a child of the transient B... Some mechanism to solve this sort of problem would be useful. Another usability problem I had was that, intuitively, the simpler function with intuitive usage pattern receiveOnly() should be named receive(). And receive() with the complex var-arg list of delegates should be named something more complex. receiveTimeout() has no receiveTimeoutOnly(), which is the function I almost always want to use... and receiveTimeout() didn't actually work for me anyway (it wouldn't receive a duration as per the documentation, I had to pass an int) I wonder if there is a solution to the 'shared' problem. Basically every single line of code that uses the std.concurrenty api is riddled with casts to/from shared... really ugly. I think the problem here is that I'm not SHARING values between threads, I'm actually passing ownership of something to another thread. So I wonder if some improvement can be made in this area. I was going to complain about the documentation, but I just checked, and it seems to have had work since I was reading it. Looks much better now! :)

It still needs to document that the ops in "void receive(T...)(T ops)" can return false if they did not handle the message. This is useful when you want to receive a message from a specific spawned subthread (tid). /Jonas
Jan 20 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jan 20, 2012, at 5:10 AM, Manu wrote:
=20
 I had some troubles with std.concurrency which I thought it might be =

=20
 Perhaps the most major problem I had was related to the concept of =

receives a signal to kill its self, but it seems impossible to reassign = ownership.
 In my case I had threads A, B and C...
   Thread A is the main thread, which may spawn many temporary worker =

   During the life of B, it may spawn C, which may persist for hours.
   B promptly dies, and any C's that were spawned receive the kill =

   Thread A, the main thread may exit, and I would really like all C's =

B died.
 The problem is, when I spawn a C, it should be created as a child of A =

solve this sort of problem would be useful. Erlang has functions to link and unlink threads from one another, and = I've already implemented a bit of it in std.concurrency. A fuller = implementation would probably be sufficient for your needs.
 Another usability problem I had was that, intuitively, the simpler =

receive().
 And receive() with the complex var-arg list of delegates should be =

Matter of opinion. I think receiveOnly indicates what the function = does, and I think it's important to indicate that receiving anything = else is unexpected and will trigger an error.
 receiveTimeout() has no receiveTimeoutOnly(), which is the function I =

for me anyway (it wouldn't receive a duration as per the documentation, = I had to pass an int) I think this is an artifact of the syntax. There's no way to have a = return value that indicates a timeout occurred. If receiving a duration = (ie. a non-reference type) doesn't work then I'd consider that a bug.
 I wonder if there is a solution to the 'shared' problem. Basically =

with casts to/from shared... really ugly. I think Unique!T should work for the sending side, and then the receive = side wouldn't have to receive shared(T). It's something that's been on = the radar, but I haven't done anything about it yet.=
Jan 20 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--20cf30363f355f52b204b70ab391
Content-Type: text/plain; charset=UTF-8

On 20 January 2012 20:06, Sean Kelly <sean invisibleduck.org> wrote:

 On Jan 20, 2012, at 5:10 AM, Manu wrote:
 I had some troubles with std.concurrency which I thought it might be

 Perhaps the most major problem I had was related to the concept of

a signal to kill its self, but it seems impossible to reassign ownership.
 In my case I had threads A, B and C...
   Thread A is the main thread, which may spawn many temporary worker

   During the life of B, it may spawn C, which may persist for hours.
   B promptly dies, and any C's that were spawned receive the kill

   Thread A, the main thread may exit, and I would really like all C's to

 The problem is, when I spawn a C, it should be created as a child of A

this sort of problem would be useful. Erlang has functions to link and unlink threads from one another, and I've already implemented a bit of it in std.concurrency. A fuller implementation would probably be sufficient for your needs.
 Another usability problem I had was that, intuitively, the simpler

receive().
 And receive() with the complex var-arg list of delegates should be named

Matter of opinion. I think receiveOnly indicates what the function does, and I think it's important to indicate that receiving anything else is unexpected and will trigger an error.

Well I'm just saying as a new comer what I consider to be intuitive or not with respect to what I've used in other languages (in my case, C/C++, C#, java, php, ecma, etc)... I've never seen an api like receive() in any language before. It definitely is a D-ish API, and wouldn't be expected by most users. I also think most instances of passing messages between 2 threads will have a tight well-defined expectation of send/receive types. receiveOnly() seems far more intuitive to me, and simpler to achieve 90(100?)% of my jobs. Eg, I press '.' and the list of methods appears, and I skim through the list and choose the one that looks appropriate, I'll choose receive, and then I'll be puzzled by the argument list and why it doesn't work like I expect, after a little wasted time, I may begrudgingly read the manual... I personally feel this is an API failure, and the single most important thing that C# gets right. You can literally code C# effectively with absolutely no prior knowledge of the language just using the '.' key with code-complete in your IDE. The API's are really exceptionally intuitive.
 receiveTimeout() has no receiveTimeoutOnly(), which is the function I

me anyway (it wouldn't receive a duration as per the documentation, I had to pass an int) I think this is an artifact of the syntax. There's no way to have a return value that indicates a timeout occurred. If receiving a duration (ie. a non-reference type) doesn't work then I'd consider that a bug.

Syntax or otherwise, it's kinda broken. receiveOnlyTimeout() is a very important function for my money. I think many usages will not want to block indefinitely. Actually, on that note, I really wanted a poll() function. I never want to block for messages, just grab one if there is one waiting in the queue. receiveTimeout(0) seems to be the only way to do it... Again, not particularly nice or intuitive. Consider the Win32 message loop: PeekMessage/GetMessage/WaitMessage.. I think they're all good to have.
 I wonder if there is a solution to the 'shared' problem. Basically every
 single line of code that uses the std.concurrenty api is riddled with casts
 to/from shared... really ugly.

 I think Unique!T should work for the sending side, and then the receive
 side wouldn't have to receive shared(T).  It's something that's been on the
 radar, but I haven't done anything about it yet.

Cool, I'll be interested to see what nice solutions for this could exist. --20cf30363f355f52b204b70ab391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 20 January 2012 20:06, Sean Kelly <span dir= =3D"ltr">&lt;<a href=3D"mailto:sean invisibleduck.org">sean invisibleduck.o= rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Jan 20, 2012, at 5:10 AM, Manu wrote:<br> &gt;<br> &gt; I had some troubles with std.concurrency which I thought it might be n= ice to address.<br> &gt;<br> &gt; Perhaps the most major problem I had was related to the concept of thr= ead ownership. If a spawned threads parent thread dies, it also receives a = signal to kill its self, but it seems impossible to reassign ownership.<br> &gt; In my case I had threads A, B and C...<br> &gt; =C2=A0 Thread A is the main thread, which may spawn many temporary wor= ker threads B, which may last 1-2 seconds.<br> &gt; =C2=A0 During the life of B, it may spawn C, which may persist for hou= rs.<br> &gt; =C2=A0 B promptly dies, and any C&#39;s that were spawned receive the = kill signal, which I ignore.<br> &gt; =C2=A0 Thread A, the main thread may exit, and I would really like all= C&#39;s to receive that notification, but they were are all orphaned when = their B died.<br> &gt; The problem is, when I spawn a C, it should be created as a child of A= somehow, rather than a child of the transient B... Some mechanism to solve= this sort of problem would be useful.<br> <br> </div>Erlang has functions to link and unlink threads from one another, and= I&#39;ve already implemented a bit of it in std.concurrency. =C2=A0A fulle= r implementation would probably be sufficient for your needs.<br> <div class=3D"im"><br> <br> &gt; Another usability problem I had was that, intuitively, the simpler fun= ction with intuitive usage pattern receiveOnly() should be named receive().= <br> &gt; And receive() with the complex var-arg list of delegates should be nam= ed something more complex.<br> <br> </div>Matter of opinion. =C2=A0I think receiveOnly indicates what the funct= ion does, and I think it&#39;s important to indicate that receiving anythin= g else is unexpected and will trigger an error.<br></blockquote><div><br></= div> <div>Well I&#39;m just saying as a new comer what I consider to be intuitiv= e or not with respect to what I&#39;ve used in other languages (in my case,= C/C++, C#, java, php, ecma, etc)... I&#39;ve never seen an api like receiv= e() in any language before. It definitely is a D-ish API, and wouldn&#39;t = be expected by most users.</div> <div>I also think most instances of passing messages between 2 threads will= have a tight well-defined expectation of send/receive types. receiveOnly()= seems far more intuitive to me, and simpler to achieve 90(100?)% of my job= s.</div> <div>Eg, I press &#39;.&#39; and the list of methods appears, and I skim th= rough the list and choose the one that looks appropriate, I&#39;ll choose r= eceive, and then I&#39;ll be puzzled by the argument list and why it doesn&= #39;t work like I expect, after a little wasted time, I may begrudgingly re= ad the manual... I personally feel this is an API failure, and the single m= ost important thing that C# gets right. You can literally code C# effective= ly with absolutely no prior knowledge of the language just using the &#39;.= &#39; key with code-complete in your IDE. The API&#39;s are really exceptio= nally intuitive.</div> <div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">&gt; receiveTimeout() has no receiveTimeoutOnly(), which = is the function I almost always want to use... and receiveTimeout() didn&#3= 9;t actually work for me anyway (it wouldn&#39;t receive a duration as per = the documentation, I had to pass an int)<br> <br> </div>I think this is an artifact of the syntax. =C2=A0There&#39;s no way t= o have a return value that indicates a timeout occurred. =C2=A0If receiving= a duration (ie. a non-reference type) doesn&#39;t work then I&#39;d consid= er that a bug.<br> </blockquote><div><br></div><div>Syntax or otherwise, it&#39;s kinda broken= . receiveOnlyTimeout() is a very important function for my money. I think m= any usages will not want to block indefinitely.</div><div><br></div><div> Actually, on that note, I really wanted a poll() function. I never want to = block for messages, just grab one if there is one waiting in the queue. rec= eiveTimeout(0) seems to be the only way to do it... Again, not particularly= nice or intuitive.</div> <div>Consider the Win32 message loop: PeekMessage/GetMessage/WaitMessage.. = I think they&#39;re all good to have.</div><div><br></div><div><br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"> <div class=3D"im">&gt; I wonder if there is a solution to the &#39;shared&#= 39; problem. Basically every single line of code that uses the std.concurre= nty api is riddled with casts to/from shared... really ugly.<br> <br> </div>I think Unique!T should work for the sending side, and then the recei= ve side wouldn&#39;t have to receive shared(T). =C2=A0It&#39;s something th= at&#39;s been on the radar, but I haven&#39;t done anything about it yet.</= blockquote> <div><br></div><div>Cool, I&#39;ll be interested to see what nice solutions= for this could exist.</div></div> --20cf30363f355f52b204b70ab391--
Jan 21 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-21 19:35, Manu wrote:
 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org
 <mailto:sean invisibleduck.org>> wrote:

     I suggest checking out Erlang messaging, as it's the basis for this
     design. Maybe then things will be a bit clearer.


 Are you suggesting that erlang is a common language that all programmers
 worth their paycheques are familiar with... and would also find intuitive?
 I don't know if it's the most sensible API decision to model a design
 off something so obscure, unless you suspect that D should appeal
 primary to ex-erlang users?

 Just to re-iterate, I'm not arguing against the API or it's merits, it's
 really cool, just that it shouldn't be the trivial one named receive().
 That name should be reserved for the most conventional API.

Scala also uses a similar API as Erlang. -- /Jacob Carlborg
Jan 22 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 22 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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?
Jan 22 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 25 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 26 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 26 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
Manu wrote:
 Eg, I press '.' and the list of methods appears, and I skim 
 through the
 list and choose the one that looks appropriate, I'll choose 
 receive, and
 then I'll be puzzled by the argument list and why it doesn't 
 work like I
 expect, after a little wasted time, I may begrudgingly read the 
 manual... I
 personally feel this is an API failure, and the single most 
 important thing
 that C# gets right. You can literally code C# effectively with 
 absolutely
 no prior knowledge of the language just using the '.' key with
 code-complete in your IDE. The API's are really exceptionally 
 intuitive.

This is a big restraint to D's popularity. It's certainly a complaint I've heard from others. An IDE with intelligence might have been a luxury in the past, but it's quickly becoming essential to large project development. Things like hunting through poorly cross-referenced documentation just to find out how to convert a string to an int, then doing it all over again when you realize the same function doesn't go both ways is just a pain in the ass.
Jan 21 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300fb41d17c6d204b70b8241
Content-Type: text/plain; charset=UTF-8

On 21 January 2012 17:23, F i L <witte2008 gmail.com> wrote:

 Manu wrote:

 Eg, I press '.' and the list of methods appears, and I skim through the
 list and choose the one that looks appropriate, I'll choose receive, and
 then I'll be puzzled by the argument list and why it doesn't work like I
 expect, after a little wasted time, I may begrudgingly read the manual...
 I
 personally feel this is an API failure, and the single most important
 thing
 that C# gets right. You can literally code C# effectively with absolutely
 no prior knowledge of the language just using the '.' key with
 code-complete in your IDE. The API's are really exceptionally intuitive.

This is a big restraint to D's popularity. It's certainly a complaint I've heard from others. An IDE with intelligence might have been a luxury in the past, but it's quickly becoming essential to large project development. Things like hunting through poorly cross-referenced documentation just to find out how to convert a string to an int, then doing it all over again when you realize the same function doesn't go both ways is just a pain in the ass.

'quickly becoming' :) .. I think that happened 5 years ago. It's long been a basic requirement, and does really need some attention. --20cf300fb41d17c6d204b70b8241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 21 January 2012 17:23, F i L <span dir=3D"ltr= ">&lt;<a href=3D"mailto:witte2008 gmail.com">witte2008 gmail.com</a>&gt;</s= pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Eg, I press &#39;.&#39; and the list of methods appears, and I skim through= the<br> list and choose the one that looks appropriate, I&#39;ll choose receive, an= d<br> then I&#39;ll be puzzled by the argument list and why it doesn&#39;t work l= ike I<br> expect, after a little wasted time, I may begrudgingly read the manual... I= <br> personally feel this is an API failure, and the single most important thing= <br> that C# gets right. You can literally code C# effectively with absolutely<b= r> no prior knowledge of the language just using the &#39;.&#39; key with<br> code-complete in your IDE. The API&#39;s are really exceptionally intuitive= .<br> </blockquote> <br></div> This is a big restraint to D&#39;s popularity. It&#39;s certainly a complai= nt I&#39;ve heard from others. An IDE with intelligence might have been a l= uxury in the past, but it&#39;s quickly becoming essential to large project= development. Things like hunting through poorly cross-referenced documenta= tion just to find out how to convert a string to an int, then doing it all = over again when you realize the same function doesn&#39;t go both ways is j= ust a pain in the ass.<br> </blockquote><div><br></div></div><div>&#39;quickly becoming&#39; :) .. I t= hink that happened 5 years ago. It&#39;s long been a basic requirement, and= does really need some attention.</div> --20cf300fb41d17c6d204b70b8241--
Jan 21 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
--Apple-Mail-47FA9480-9B6C-4E10-A68B-8D383D9BB00D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I suggest checking out Erlang messaging, as it's the basis for this design. M=
aybe then things will be a bit clearer.=20

Sent from my iPhone

On Jan 21, 2012, at 6:34 AM, Manu <turkeyman gmail.com> wrote:

 On 20 January 2012 20:06, Sean Kelly <sean invisibleduck.org> wrote:
 On Jan 20, 2012, at 5:10 AM, Manu wrote:
 I had some troubles with std.concurrency which I thought it might be nic=


 Perhaps the most major problem I had was related to the concept of threa=


nal to kill its self, but it seems impossible to reassign ownership.
 In my case I had threads A, B and C...
   Thread A is the main thread, which may spawn many temporary worker thr=


   During the life of B, it may spawn C, which may persist for hours.
   B promptly dies, and any C's that were spawned receive the kill signal=


   Thread A, the main thread may exit, and I would really like all C's to=


.
 The problem is, when I spawn a C, it should be created as a child of A s=


is sort of problem would be useful.
=20
 Erlang has functions to link and unlink threads from one another, and I've=

n would probably be sufficient for your needs.
=20
=20
 Another usability problem I had was that, intuitively, the simpler funct=


 And receive() with the complex var-arg list of delegates should be named=


=20
 Matter of opinion.  I think receiveOnly indicates what the function does, a=

cted and will trigger an error.
=20
 Well I'm just saying as a new comer what I consider to be intuitive or not=

ava, php, ecma, etc)... I've never seen an api like receive() in any languag= e before. It definitely is a D-ish API, and wouldn't be expected by most use= rs.
 I also think most instances of passing messages between 2 threads will hav=

s far more intuitive to me, and simpler to achieve 90(100?)% of my jobs.
 Eg, I press '.' and the list of methods appears, and I skim through the li=

'll be puzzled by the argument list and why it doesn't work like I expect, a= fter a little wasted time, I may begrudgingly read the manual... I personall= y feel this is an API failure, and the single most important thing that C# g= ets right. You can literally code C# effectively with absolutely no prior kn= owledge of the language just using the '.' key with code-complete in your ID= E. The API's are really exceptionally intuitive.
=20
 =20
 receiveTimeout() has no receiveTimeoutOnly(), which is the function I al=


nyway (it wouldn't receive a duration as per the documentation, I had to pas= s an int)
=20
 I think this is an artifact of the syntax.  There's no way to have a retur=

on-reference type) doesn't work then I'd consider that a bug.
=20
 Syntax or otherwise, it's kinda broken. receiveOnlyTimeout() is a very imp=

efinitely.
=20
 Actually, on that note, I really wanted a poll() function. I never want to=

eiveTimeout(0) seems to be the only way to do it... Again, not particularly n= ice or intuitive.
 Consider the Win32 message loop: PeekMessage/GetMessage/WaitMessage.. I th=

=20
=20
 I wonder if there is a solution to the 'shared' problem. Basically every=


to/from shared... really ugly.
=20
 I think Unique!T should work for the sending side, and then the receive si=

dar, but I haven't done anything about it yet.
=20
 Cool, I'll be interested to see what nice solutions for this could exist.

--Apple-Mail-47FA9480-9B6C-4E10-A68B-8D383D9BB00D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 <html><head></head><body bgcolor="#FFFFFF"><div>I suggest checking out Erlang messaging, as it's the basis for this design. Maybe then things will be a bit clearer.&nbsp;<br><br>Sent from my iPhone</div><div><br>On Jan 21, 2012, at 6:34 AM, Manu &lt;<a href="mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div><div class="gmail_quote">On 20 January 2012 20:06, Sean Kelly <span dir="ltr">&lt;<a href="mailto:sean invisibleduck.org">sean invisibleduck.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Jan 20, 2012, at 5:10 AM, Manu wrote:<br> &gt;<br> &gt; I had some troubles with std.concurrency which I thought it might be nice to address.<br> &gt;<br> &gt; Perhaps the most major problem I had was related to the concept of thread ownership. If a spawned threads parent thread dies, it also receives a signal to kill its self, but it seems impossible to reassign ownership.<br> &gt; In my case I had threads A, B and C...<br> &gt; &nbsp; Thread A is the main thread, which may spawn many temporary worker threads B, which may last 1-2 seconds.<br> &gt; &nbsp; During the life of B, it may spawn C, which may persist for hours.<br> &gt; &nbsp; B promptly dies, and any C's that were spawned receive the kill signal, which I ignore.<br> &gt; &nbsp; Thread A, the main thread may exit, and I would really like all C's to receive that notification, but they were are all orphaned when their B died.<br> &gt; The problem is, when I spawn a C, it should be created as a child of A somehow, rather than a child of the transient B... Some mechanism to solve this sort of problem would be useful.<br> <br> </div>Erlang has functions to link and unlink threads from one another, and I've already implemented a bit of it in std.concurrency. &nbsp;A fuller implementation would probably be sufficient for your needs.<br> <div class="im"><br> <br> &gt; Another usability problem I had was that, intuitively, the simpler function with intuitive usage pattern receiveOnly() should be named receive().<br> &gt; And receive() with the complex var-arg list of delegates should be named something more complex.<br> <br> </div>Matter of opinion. &nbsp;I think receiveOnly indicates what the function does, and I think it's important to indicate that receiving anything else is unexpected and will trigger an error.<br></blockquote><div><br></div> <div>Well I'm just saying as a new comer what I consider to be intuitive or not with respect to what I've used in other languages (in my case, C/C++, C#, java, php, ecma, etc)... I've never seen an api like receive() in any language before. It definitely is a D-ish API, and wouldn't be expected by most users.</div> <div>I also think most instances of passing messages between 2 threads will have a tight well-defined expectation of send/receive types. receiveOnly() seems far more intuitive to me, and simpler to achieve 90(100?)% of my jobs.</div> <div>Eg, I press '.' and the list of methods appears, and I skim through the list and choose the one that looks appropriate, I'll choose receive, and then I'll be puzzled by the argument list and why it doesn't work like I expect, after a little wasted time, I may begrudgingly read the manual... I personally feel this is an API failure, and the single most important thing that C# gets right. You can literally code C# effectively with absolutely no prior knowledge of the language just using the '.' key with code-complete in your IDE. The API's are really exceptionally intuitive.</div> <div><br></div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">&gt; receiveTimeout() has no receiveTimeoutOnly(), which is the function I almost always want to use... and receiveTimeout() didn't actually work for me anyway (it wouldn't receive a duration as per the documentation, I had to pass an int)<br> <br> </div>I think this is an artifact of the syntax. &nbsp;There's no way to have a return value that indicates a timeout occurred. &nbsp;If receiving a duration (ie. a non-reference type) doesn't work then I'd consider that a bug.<br> </blockquote><div><br></div><div>Syntax or otherwise, it's kinda broken. receiveOnlyTimeout() is a very important function for my money. I think many usages will not want to block indefinitely.</div><div><br></div><div> Actually, on that note, I really wanted a poll() function. I never want to block for messages, just grab one if there is one waiting in the queue. receiveTimeout(0) seems to be the only way to do it... Again, not particularly nice or intuitive.</div> <div>Consider the Win32 message loop: PeekMessage/GetMessage/WaitMessage.. I think they're all good to have.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">&gt; I wonder if there is a solution to the 'shared' problem. Basically every single line of code that uses the std.concurrenty api is riddled with casts to/from shared... really ugly.<br> <br> </div>I think Unique!T should work for the sending side, and then the receive side wouldn't have to receive shared(T). &nbsp;It's something that's been on the radar, but I haven't done anything about it yet.</blockquote> <div><br></div><div>Cool, I'll be interested to see what nice solutions for this could exist.</div></div> </div></blockquote></body></html> --Apple-Mail-47FA9480-9B6C-4E10-A68B-8D383D9BB00D--
Jan 21 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Seriously?  I usually turn that feature off if I use an IDE that has it. Lar=
ge projects aren't an issue. I've worked on some counted in millions of line=
s of code.=20

Sent from my iPhone

On Jan 21, 2012, at 7:23 AM, "F i L" <witte2008 gmail.com> wrote:

 Manu wrote:
 Eg, I press '.' and the list of methods appears, and I skim through the
 list and choose the one that looks appropriate, I'll choose receive, and
 then I'll be puzzled by the argument list and why it doesn't work like I
 expect, after a little wasted time, I may begrudgingly read the manual...=


 personally feel this is an API failure, and the single most important thi=


 that C# gets right. You can literally code C# effectively with absolutely=


 no prior knowledge of the language just using the '.' key with
 code-complete in your IDE. The API's are really exceptionally intuitive.

This is a big restraint to D's popularity. It's certainly a complaint I've=

past, but it's quickly becoming essential to large project development. Thi= ngs like hunting through poorly cross-referenced documentation just to find o= ut how to convert a string to an int, then doing it all over again when you r= ealize the same function doesn't go both ways is just a pain in the ass.
Jan 21 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074b440e2041504b70e0f90
Content-Type: text/plain; charset=UTF-8

On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org> wrote:

 I suggest checking out Erlang messaging, as it's the basis for this
 design. Maybe then things will be a bit clearer.

Are you suggesting that erlang is a common language that all programmers worth their paycheques are familiar with... and would also find intuitive? I don't know if it's the most sensible API decision to model a design off something so obscure, unless you suspect that D should appeal primary to ex-erlang users? Just to re-iterate, I'm not arguing against the API or it's merits, it's really cool, just that it shouldn't be the trivial one named receive(). That name should be reserved for the most conventional API. Seriously? I usually turn that feature off if I use an IDE that has it.
 Large projects aren't an issue. I've worked on some counted in millions of
 lines of code.

Why even argue this? What's the point in intentionally making D unappealing to anyone who works in a non-linux professional environment? Do you aim to alienate those users from the community; keep the community nice and small... I honestly don't understand how so many people around here can blindly consider windows users, and 'IDE users' in general, a niche or minority user base, and also, what the value of presenting this argument might actually be? Who are the majority of professional devs here? What industry do they work in? Do they, or do they intend to use D in their professional work? What language are they coming from/using normally in their work? Do they *really*use vi in the office? Is there a poll, or some statistics of this sort? I'd be very curious... because this argument comes up every other day. --20cf3074b440e2041504b70e0f90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 21 January 2012 18:09, Sean Kelly=C2=A0<span dir=3D"ltr">&lt;<a href=3D"= mailto:sean invisibleduck.org">sean invisibleduck.org</a>&gt;</span>=C2=A0w= rote:<br><blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-r= ight:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-l= eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <span style>I suggest checking out Erlang messaging, as it&#39;s the basis = for this design. Maybe then things will be a bit clearer.</span> </blockquote><div><br></div>Are you suggesting that erlang is a common lang= uage that all programmers worth their paycheques are familiar with... and w= ould also find intuitive?<div>I don&#39;t know if it&#39;s the most sensibl= e API decision to model a design off something so obscure, unless you suspe= ct that D should appeal primary to ex-erlang users?</div> <div><br></div><div>Just to re-iterate, I&#39;m not arguing against the API= or it&#39;s merits, it&#39;s really cool, just that it shouldn&#39;t be th= e trivial one named receive(). That name should be reserved for the most co= nventional API.</div> <div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex">Seriously? =C2=A0I usually turn that feature off i= f I use an IDE that has it. Large projects aren&#39;t an issue. I&#39;ve wo= rked on some counted in millions of lines of code.<br> </blockquote><div><br></div><div>Why even argue this? What&#39;s the point = in intentionally making D unappealing to anyone who works in a non-linux pr= ofessional environment? Do you aim to alienate those users from the communi= ty; keep the community nice and small...</div> <div>I honestly don&#39;t understand how so many people around here can bli= ndly consider windows users, and &#39;IDE users&#39; in general, a niche or= minority user base, and also, what the value of presenting this argument m= ight actually be?</div> <div><br></div><div>Who are the majority of professional devs here? What in= dustry do they work in? Do they, or do they intend to use D in their profes= sional work?=C2=A0What language are they coming from/using normally in thei= r work? Do they <i>really</i> use vi in the office?</div> <div>Is there a poll, or some statistics of this sort? I&#39;d be very curi= ous... because this argument comes up every other day.</div></div></div> --20cf3074b440e2041504b70e0f90--
Jan 21 2012
prev sibling next sibling parent "Kiith-Sa" <42 theanswer.com> writes:
Erlang being uncommon doesn't mean it doesn't have awesome 
features.
Java (or COBOL :p) are common, that doesn't mean we should copy 
them
just to make it easier for Java users to move to D.


OT, but this always pisses me off:

I use Vim. On Linux. Vim not being an IDE doesn't mean it doesn't
have autocompletion, or pretty much any common IDE feature (or... 
many that no IDE in existence has, for that matter). You just have
to build your own environment with plugins. I understand most 
people
might not want to spend time to do that, but there are quite
a few that do - and I wouldn't use anything else now, hobby or 
job.

(BTW, I originally used NetBeans, Eclipse, Code::Blocks on 
Windows - I know VS is significantly better, but nothing can tear 
me off
the pure productivity of my buttonless screen displaying 10 files
at once)

Oh, and don't use Vi for development (I don't know anyone who 
does,
anyway - for basic text editing when there's nothing else, yes, 
but for development?).

That said, there's no intelligent autocompletion for D in Vim 
(there is for C/C++, Java, Python...).
I for one would like to have it. But this is not responsibility of
DMD devs - DMD will never turn into Clang.

I hope if anyone works on a project like this, they do it as a 
library
so not only VisualD or DDT or whatever will benefit.


On Saturday, 21 January 2012 at 18:35:40 UTC, Manu wrote:
 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org> 
 wrote:

 I suggest checking out Erlang messaging, as it's the basis for 
 this
 design. Maybe then things will be a bit clearer.

Are you suggesting that erlang is a common language that all programmers worth their paycheques are familiar with... and would also find intuitive? I don't know if it's the most sensible API decision to model a design off something so obscure, unless you suspect that D should appeal primary to ex-erlang users? Just to re-iterate, I'm not arguing against the API or it's merits, it's really cool, just that it shouldn't be the trivial one named receive(). That name should be reserved for the most conventional API. Seriously? I usually turn that feature off if I use an IDE that has it.
 Large projects aren't an issue. I've worked on some counted in 
 millions of
 lines of code.

Why even argue this? What's the point in intentionally making D unappealing to anyone who works in a non-linux professional environment? Do you aim to alienate those users from the community; keep the community nice and small... I honestly don't understand how so many people around here can blindly consider windows users, and 'IDE users' in general, a niche or minority user base, and also, what the value of presenting this argument might actually be? Who are the majority of professional devs here? What industry do they work in? Do they, or do they intend to use D in their professional work? What language are they coming from/using normally in their work? Do they *really*use vi in the office? Is there a poll, or some statistics of this sort? I'd be very curious... because this argument comes up every other day.

Jan 21 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
--Apple-Mail-C5695F3E-2FB0-46A5-986D-870DEB32F416
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Jan 21, 2012, at 10:35 AM, Manu <turkeyman gmail.com> wrote:

 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org>=20
=20
 Seriously?  I usually turn that feature off if I use an IDE that has it. L=

nes of code.
=20
 Why even argue this? What's the point in intentionally making D unappealin=

alienate those users from the community; keep the community nice and small.= ..
 I honestly don't understand how so many people around here can blindly con=

se, and also, what the value of presenting this argument might actually be? I wasn't making any sort of argument, I was merely surprised at this stateme= nt. Even most of the Java devs I know aren't this reliant on an IDE.=20= --Apple-Mail-C5695F3E-2FB0-46A5-986D-870DEB32F416 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 <html><head></head><body bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">On Jan 21, 2012, at 10:35 AM, Manu &lt;<a href="mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt; wrote:</span><br></div><div><br></div><div></div><blockquote type="cite"><div>On 21 January 2012 18:09, Sean Kelly&nbsp;<span dir="ltr">&lt;<a href="mailto:sean invisibleduck.org">sean invisibleduck.org</a>&gt;</span>&nbsp;<br> <div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Seriously? &nbsp;I usually turn that feature off if I use an IDE that has it. Large projects aren't an issue. I've worked on some counted in millions of lines of code.<br> </blockquote><div><br></div><div>Why even argue this? What's the point in intentionally making D unappealing to anyone who works in a non-linux professional environment? Do you aim to alienate those users from the community; keep the community nice and small...</div> <div>I honestly don't understand how so many people around here can blindly consider windows users, and 'IDE users' in general, a niche or minority user base, and also, what the value of presenting this argument might actually be?</div></div></div> </div></blockquote><br><div>I wasn't making any sort of argument, I was merely surprised at this statement. &nbsp;Even most of the Java devs I know aren't this reliant on an IDE.&nbsp;</div></body></html> --Apple-Mail-C5695F3E-2FB0-46A5-986D-870DEB32F416--
Jan 21 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235433297e1f7f3604b7147bda
Content-Type: text/plain; charset=UTF-8

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

 On Jan 21, 2012, at 10:35 AM, Manu <turkeyman gmail.com> wrote:

 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org>

 Seriously?  I usually turn that feature off if I use an IDE that has it.
 Large projects aren't an issue. I've worked on some counted in millions of
 lines of code.

Why even argue this? What's the point in intentionally making D unappealing to anyone who works in a non-linux professional environment? Do you aim to alienate those users from the community; keep the community nice and small... I honestly don't understand how so many people around here can blindly consider windows users, and 'IDE users' in general, a niche or minority user base, and also, what the value of presenting this argument might actually be? I wasn't making any sort of argument, I was merely surprised at this statement. Even most of the Java devs I know aren't this reliant on an IDE.

Most of the Java devs I know use Eclipse, and quite like the auto-compile stuff, code completion, and the reasonable quality integrated debugger. That said, most of the Java devs I know work for Google, who seem to promote use of Eclipse internally. Regardless, I'm fairly surprised that you're surprised that there are many devs that wouldn't bother with a toolchain if it doesn't integrate with their company's workflow. For most businesses, integration with their company workflow is basic pre-requisite to consideration for adoption. --00235433297e1f7f3604b7147bda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 22 January 2012 02:42, Sean Kelly <span dir= =3D"ltr">&lt;<a href=3D"mailto:sean invisibleduck.org">sean invisibleduck.o= rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor=3D"#FFFFFF"><div class=3D"im"><div><span>On Jan 21, 2012, at 1= 0:35 AM, Manu &lt;<a href=3D"mailto:turkeyman gmail.com" target=3D"_blank">= turkeyman gmail.com</a>&gt; wrote:</span><br></div><div><br></div><div></di= v></div> <blockquote type=3D"cite"><div><div class=3D"im">On 21 January 2012 18:09, = Sean Kelly=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:sean invisibleduck.= org" target=3D"_blank">sean invisibleduck.org</a>&gt;</span>=C2=A0<br> </div><div><div class=3D"gmail_quote"><br></div><div class=3D"im"><div clas= s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">Seriously? =C2=A0I usually= turn that feature off if I use an IDE that has it. Large projects aren&#39= ;t an issue. I&#39;ve worked on some counted in millions of lines of code.<= br> </blockquote><div><br></div><div>Why even argue this? What&#39;s the point = in intentionally making D unappealing to anyone who works in a non-linux pr= ofessional environment? Do you aim to alienate those users from the communi= ty; keep the community nice and small...</div> <div>I honestly don&#39;t understand how so many people around here can bli= ndly consider windows users, and &#39;IDE users&#39; in general, a niche or= minority user base, and also, what the value of presenting this argument m= ight actually be?</div> </div></div></div> </div></blockquote><br><div>I wasn&#39;t making any sort of argument, I was= merely surprised at this statement. =C2=A0Even most of the Java devs I kno= w aren&#39;t this reliant on an IDE.=C2=A0</div></div></blockquote></div><b= r><div> Most of the Java devs I know use Eclipse, and quite like the auto-compile s= tuff, code completion, and the reasonable quality integrated debugger.</div=
<div>That said, most of the Java devs I know work for Google, who seem to =

<div><br></div><div>Regardless, I&#39;m fairly surprised that you&#39;re su= rprised that there are many devs that wouldn&#39;t bother with a toolchain = if it doesn&#39;t integrate with their company&#39;s workflow. For most bus= inesses, integration with their company workflow is basic pre-requisite to = consideration for adoption.</div> --00235433297e1f7f3604b7147bda--
Jan 21 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Thu, 19 Jan 2012 23:36:12 +0100, Sean Kelly <sean invisibleduck.org>  
wrote:

 Thanks :-)  If you have ideas on how it could be improved, please let me  
 know.

user defined transport layers. Of course we're lacking a marshalling solution for this. ZeroMQ is probably a too heavy dependency, but it offers interesting connection schemes.
Jan 21 2012
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 22.01.2012, 01:42 Uhr, schrieb Sean Kelly <sean invisibleduck.org>:

 On Jan 21, 2012, at 10:35 AM, Manu <turkeyman gmail.com> wrote:

 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org>

 Seriously?  I usually turn that feature off if I use an IDE that has  
 it. Large projects aren't an issue. I've worked on some counted in  
 millions of lines of code.

 Why even argue this? What's the point in intentionally making D  
 unappealing to anyone who works in a non-linux professional  
 environment? Do you aim to alienate those users from the community;  
 keep the community nice and small...
 I honestly don't understand how so many people around here can blindly  
 consider windows users, and 'IDE users' in general, a niche or minority  
 user base, and also, what the value of presenting this argument might  
 actually be?

I wasn't making any sort of argument, I was merely surprised at this statement. Even most of the Java devs I know aren't this reliant on an IDE.

I was as a Java developer reliant on an IDE. It integrates such features as SVN, refactoring, Maven2, remote debugging, powerful code completion including turning the letters "MSO" into "MySpecialObject" using camel-case matching, an embedded compiler capable of quick recompiling when you save a file, warnings while you are editing, powerful search for things like "write access to field 'x'", ... the list goes on.
Jan 22 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3005dee2f0fa3204b71e3e8c
Content-Type: text/plain; charset=UTF-8

On 22 January 2012 15:18, Jacob Carlborg <doob me.com> wrote:

 On 2012-01-21 19:35, Manu wrote:

 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org
 <mailto:sean invisibleduck.org**>> wrote:

    I suggest checking out Erlang messaging, as it's the basis for this
    design. Maybe then things will be a bit clearer.


 Are you suggesting that erlang is a common language that all programmers
 worth their paycheques are familiar with... and would also find intuitive?
 I don't know if it's the most sensible API decision to model a design
 off something so obscure, unless you suspect that D should appeal
 primary to ex-erlang users?

 Just to re-iterate, I'm not arguing against the API or it's merits, it's
 really cool, just that it shouldn't be the trivial one named receive().
 That name should be reserved for the most conventional API.

Scala also uses a similar API as Erlang.

Another super-mainstream language that everyone's familiar with :) --20cf3005dee2f0fa3204b71e3e8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 22 January 2012 15:18, Jacob Carlborg <span d= ir=3D"ltr">&lt;<a href=3D"mailto:doob me.com">doob me.com</a>&gt;</span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-01-21 19:35, Manu wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 21 January 2012 18:09, Sean Kelly &lt;<a href=3D"mailto:sean invisibledu= ck.org" target=3D"_blank">sean invisibleduck.org</a><br></div><div class=3D= "im"> &lt;mailto:<a href=3D"mailto:sean invisibleduck.org" target=3D"_blank">sean= invisibleduck.org</a><u></u>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0I suggest checking out Erlang messaging, as it&#39;s the basi= s for this<br> =C2=A0 =C2=A0design. Maybe then things will be a bit clearer.<br> <br> <br> Are you suggesting that erlang is a common language that all programmers<br=

br> I don&#39;t know if it&#39;s the most sensible API decision to model a desi= gn<br> off something so obscure, unless you suspect that D should appeal<br> primary to ex-erlang users?<br> <br> Just to re-iterate, I&#39;m not arguing against the API or it&#39;s merits,= it&#39;s<br> really cool, just that it shouldn&#39;t be the trivial one named receive().= <br> That name should be reserved for the most conventional API.<br> </div></blockquote> <br> Scala also uses a similar API as Erlang.</blockquote><div><br></div><div>An= other super-mainstream language that everyone&#39;s familiar with :)</div><= /div> --20cf3005dee2f0fa3204b71e3e8c--
Jan 22 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
--Apple-Mail-15E2D594-2158-4A4C-9F6A-501B45FF7CA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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

Sent from my iPhone

On Jan 22, 2012, at 5:53 AM, Manu <turkeyman gmail.com> wrote:

 On 22 January 2012 15:18, Jacob Carlborg <doob me.com> wrote:
 On 2012-01-21 19:35, Manu wrote:
 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org
 <mailto:sean invisibleduck.org>> wrote:
=20
    I suggest checking out Erlang messaging, as it's the basis for this
    design. Maybe then things will be a bit clearer.
=20
=20
 Are you suggesting that erlang is a common language that all programmers
 worth their paycheques are familiar with... and would also find intuitive?=

 I don't know if it's the most sensible API decision to model a design
 off something so obscure, unless you suspect that D should appeal
 primary to ex-erlang users?
=20
 Just to re-iterate, I'm not arguing against the API or it's merits, it's
 really cool, just that it shouldn't be the trivial one named receive().
 That name should be reserved for the most conventional API.
=20
 Scala also uses a similar API as Erlang.
=20
 Another super-mainstream language that everyone's familiar with :)

--Apple-Mail-15E2D594-2158-4A4C-9F6A-501B45FF7CA4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 <html><head></head><body bgcolor="#FFFFFF"><div>The popularity of a language has no bearing on the quality of one of its features. Are there other message passing schemes you prefer?<br><br>Sent from my iPhone</div><div><br>On Jan 22, 2012, at 5:53 AM, Manu &lt;<a href="mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div><div class="gmail_quote">On 22 January 2012 15:18, Jacob Carlborg <span dir="ltr">&lt;<a href="mailto:doob me.com">doob me.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On 2012-01-21 19:35, Manu wrote:<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> On 21 January 2012 18:09, Sean Kelly &lt;<a href="mailto:sean invisibleduck.org" target="_blank">sean invisibleduck.org</a><br></div><div class="im"> &lt;mailto:<a href="mailto:sean invisibleduck.org" target="_blank">sean invisibleduck.org</a><u></u>&gt;&gt; wrote:<br> <br> &nbsp; &nbsp;I suggest checking out Erlang messaging, as it's the basis for this<br> &nbsp; &nbsp;design. Maybe then things will be a bit clearer.<br> <br> <br> Are you suggesting that erlang is a common language that all programmers<br> worth their paycheques are familiar with... and would also find intuitive?<br> I don't know if it's the most sensible API decision to model a design<br> off something so obscure, unless you suspect that D should appeal<br> primary to ex-erlang users?<br> <br> Just to re-iterate, I'm not arguing against the API or it's merits, it's<br> really cool, just that it shouldn't be the trivial one named receive().<br> That name should be reserved for the most conventional API.<br> </div></blockquote> <br> Scala also uses a similar API as Erlang.</blockquote><div><br></div><div>Another super-mainstream language that everyone's familiar with :)</div></div> </div></blockquote></body></html> --Apple-Mail-15E2D594-2158-4A4C-9F6A-501B45FF7CA4--
Jan 22 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235433297e97b89a04b724751c
Content-Type: text/plain; charset=UTF-8

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. --00235433297e97b89a04b724751c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 22 January 2012 18:42, Sean Kelly <span dir= =3D"ltr">&lt;<a href=3D"mailto:sean invisibleduck.org">sean invisibleduck.o= rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor=3D"#FFFFFF"><div>The popularity of a language has no bearing o= n the quality of one of its features. Are there other message passing schem= es you prefer?<br></div></div></blockquote><div><br></div><div>As said in t= he original post, I think receiveOnly() is the most intuitive API. I just t= hink that one should be named receive(), and perhaps receive() may be renam= ed receiveMulti(). Surely that would be more intuitive to more people?</div=

I would love to see a poll()/pollMulti() function.</div></div> --00235433297e97b89a04b724751c--
Jan 22 2012
prev sibling next sibling parent "Mariusz Gliwiński" <alienballance gmail.com> writes:
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.
Jan 22 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074b440ec41fe04b725f4b3
Content-Type: text/plain; charset=UTF-8

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. --20cf3074b440ec41fe04b725f4b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 22 January 2012 23:34, Andrei Alexandrescu <s= pan dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org">SeeWeb= siteForEmail erdani.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> On 1/22/12 3:18 PM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 22 January 2012 18:42, Sean Kelly &lt;<a href=3D"mailto:sean invisibledu= ck.org" target=3D"_blank">sean invisibleduck.org</a><div class=3D"im"><br> &lt;mailto:<a href=3D"mailto:sean invisibleduck.org" target=3D"_blank">sean= invisibleduck.org</a><u></u>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0The popularity of a language has no bearing on the quality of= one of<br> =C2=A0 =C2=A0its features. Are there other message passing schemes you pre= fer?<br> <br> <br></div><div class=3D"im"> As said in the original post, I think receiveOnly() is the most<br> intuitive API. I just think that one should be named receive(), and<br> perhaps receive() may be renamed receiveMulti(). Surely that would be<br> more intuitive to more people?<br> </div></blockquote> <br> Names will not change.</blockquote><div><br></div><div>Why? Surely API&#39;= s being as intuitive as possible should be a key goal for a standard librar= y?</div><div>The thing isn&#39;t supposed to be stable yet is it? If you ta= ke the attitude that no name should ever be changed, then I think there is = a problem with the phobos contribution process.</div> <div>Phobos contributions have basically no incubation time/process. I&#39;= ve seen others suggest new stuff should go in exp.xxx to incubate, and it s= hould only be promoted to std after some time, or some successful usage in = multiple large-ish projects?</div> <div>It&#39;s a shame that basic usability things like that couldn&#39;t be= caught earlier.</div><div><br></div><div>Do you disagree that receive() an= d 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 app= roach?</div> <div>C# is awesome because it gets this right. I think that&#39;s its singl= e greatest achievement, and can not be understated.</div><div><br></div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">Also both Only and Multi v= arieties should have a Timeout version, and I<br> would love to see a poll()/pollMulti() function.<br> </blockquote> <br></div> This is sensible. You may want to add functions through pull requests, or m= ake enhancement requests on bugzilla.<br></blockquote><div><br></div><div>S= hall do one or the other.</div></div> --20cf3074b440ec41fe04b725f4b3--
Jan 22 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
--Apple-Mail-0101A029-7FF6-450A-91EF-D3499B639A4F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The names as they exist match what's in TDPL, so they're somewhat set in sto=
ne.=20

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

 On 1/22/12 3:18 PM, Manu wrote:
 On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org
=20
 <mailto:sean invisibleduck.org>> wrote:
=20
    The popularity of a language has no bearing on the quality of one of
    its features. Are there other message passing schemes you prefer?
=20
=20
 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?
=20
 Names will not change.
=20
 Why? Surely API's being as intuitive as possible should be a key goal for a=

 The thing isn't supposed to be stable yet is it? If you take the attitude t=

phobos contribution process.
 Phobos contributions have basically no incubation time/process. I've seen o=

be promoted to std after some time, or some successful usage in multiple la= rge-ish projects?
 It's a shame that basic usability things like that couldn't be caught earl=

=20
 Do you disagree that receive() and receiveMulti() (with the crazy var-arg-=

fore) is a far more intuitive approach?
 C# is awesome because it gets this right. I think that's its single greate=

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

=20
 Shall do one or the other.

--Apple-Mail-0101A029-7FF6-450A-91EF-D3499B639A4F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 <html><head></head><body bgcolor="#FFFFFF"><div>The names as they exist match what's in TDPL, so they're somewhat set in stone.&nbsp;<br><br>Sent from my iPhone</div><div><br>On Jan 22, 2012, at 3:05 PM, Manu &lt;<a href="mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt; wrote:<br><br></div><div></div><blockquote type="cite"><div><div class="gmail_quote">On 22 January 2012 23:34, Andrei Alexandrescu <span dir="ltr">&lt;<a href="mailto:SeeWebsiteForEmail erdani.org">SeeWebsiteForEmail erdan .org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 1/22/12 3:18 PM, Manu wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 22 January 2012 18:42, Sean Kelly &lt;<a href="mailto:sean invisibleduck.org" target="_blank">sean invisibleduck.org</a><div class="im"><br> &lt;mailto:<a href="mailto:sean invisibleduck.org" target="_blank">sean invisibleduck.org</a><u></u>&gt;&gt; wrote:<br> <br> &nbsp; &nbsp;The popularity of a language has no bearing on the quality of one of<br> &nbsp; &nbsp;its features. Are there other message passing schemes you prefer?<br> <br> <br></div><div class="im"> As said in the original post, I think receiveOnly() is the most<br> intuitive API. I just think that one should be named receive(), and<br> perhaps receive() may be renamed receiveMulti(). Surely that would be<br> more intuitive to more people?<br> </div></blockquote> <br> Names will not change.</blockquote><div><br></div><div>Why? Surely API's being as intuitive as possible should be a key goal for a standard library?</div><div>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.</div> <div>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?</div> <div>It's a shame that basic usability things like that couldn't be caught earlier.</div><div><br></div><div>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?</div> <div>C# is awesome because it gets this right. I think that's its single greatest achievement, and can not be understated.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also both Only and Multi varieties should have a Timeout version, and I<br> would love to see a poll()/pollMulti() function.<br> </blockquote> <br></div> This is sensible. You may want to add functions through pull requests, or make enhancement requests on bugzilla.<br></blockquote><div><br></div><div>Shall do one or the other.</div></div> </div></blockquote></body></html> --Apple-Mail-0101A029-7FF6-450A-91EF-D3499B639A4F--
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 22 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074b44070366304b72e278e
Content-Type: text/plain; charset=UTF-8

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 :) --20cf3074b44070366304b72e278e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 23 January 2012 01:49, Sean Kelly <span dir= =3D"ltr">&lt;<a href=3D"mailto:sean invisibleduck.org">sean invisibleduck.o= rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor=3D"#FFFFFF"><div>The names as they exist match what&#39;s in T= DPL, so they&#39;re somewhat set in stone.=C2=A0<br></div></div></blockquot= e><div><br></div><div>Ah, I see. That makes it considerably harder to go ba= ck on then :)</div> </div> --20cf3074b44070366304b72e278e--
Jan 23 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235429d6d8fbe8d004b75805dd
Content-Type: text/plain; charset=UTF-8

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.

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


 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

 may be renamed receiveMulti(). Surely that would be more intuitive to

 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 :) --00235429d6d8fbe8d004b75805dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 23 January 2012 02:00, Timon Gehr <span dir= =3D"ltr">&lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">timon.g= ehr gmx.ch</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;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=3D"http://programmers.stackexchange.com/questions/112417/real-world= -applications-of-erlang" target=3D"_blank">http://programmers.<u></u>stacke= xchange.com/questions/<u></u>112417/real-world-<u></u>applications-of-erlan= g</a></blockquote> <div><br></div><div>Oh come on.. It&#39;s niche, unfamiliar to most people,= and we&#39;re talking about name and argument list clarity with respect to= what would be instinctive to the most users, not &#39;model&#39; or API de= sign, that&#39;s obviously fine.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"><div><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"> C# is awesome because it gets this right. I think that&#39;s its single<br> greatest achievement, and can not be understated.<br> <br> </blockquote> <br></div> I couldn&#39;t find any information about a C# API for the same functionali= ty. Can you help me out?<br></blockquote><div><br></div><div>I&#39;m not re= ferring to this API in particular, I&#39;m referring to the fairly universa= l application of the principle within the C# libraries. Most people I&#39;v= e ever talked to agree that one of it&#39;s biggest selling points, and pos= sibly even the key reason they use it; because it was so accessible and pro= ductive from the instant they tried it out.</div> <div>You shouldn&#39;t need to read anything. Pressing &#39;.&#39; in the I= DE shows lists of classes/methods/etc, and common sense writes your code. T= his requires that the function names make perfect sense, and the argument l= ists are as you intuitively expect.</div> <div><br></div><div>If I: send(tid, myThing);<br>I expect to: myThing =3D r= eceive!SomeThing();</div><div><br></div><div>How can you argue that it&#39;= s not intuitive to receive what you sent?</div><div>There&#39;s nothing in:= send(tid, something); that suggests the expected compliment API should tak= e a var-arg list of undefined things. It&#39;s not clear from receive()&#39= ;s signature that it should receive delegates, it looks like it could recei= ve anything.=C2=A0The delegate signature is un-knowable from the functions = own signature, nor what the delegates are even supposed to do.</div> <div>Also, the name &#39;receiveOnly&#39; doesn&#39;t actually make sense u= nless you *already know* that receive() is effectively receiveMulti. If I w= as scrolling through the pop-up list of methods, I would not confidently pr= edict 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.=C2=A0You don&#39;t need to read the docs to u= nderstand receiveOnly(), it&#39;s perfectly obvious what it does and how it= works on sight, and matches what you expect as the natural complement to s= end().</div> <div><br></div><div>On 23 January 2012 02:55, Jonathan M Davis=C2=A0<span d= ir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jmd= avisProg gmx.com</a>&gt;</span>=C2=A0wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-lef= t:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"> <div>On Sunday, January 22, 2012 23:18:46 Manu wrote:<br>&gt; On 22 January= 2012 18:42, Sean Kelly &lt;<a href=3D"mailto:sean invisibleduck.org" targe= t=3D"_blank">sean invisibleduck.org</a>&gt; wrote:<br>&gt; &gt; The popular= ity of a language has no bearing on the quality of one of its<br> &gt; &gt; features. Are there other message passing schemes you prefer?<br>= &gt;<br>&gt; As said in the original post, I think receiveOnly() is the mos= t intuitive<br>&gt; API. I just think that one should be named receive(), a= nd perhaps receive()<br> &gt; may be renamed receiveMulti(). Surely that would be more intuitive to = more<br>&gt; people?<br><br></div>I&#39;m not sure that that&#39;s true. Bu= t since you have to read the docs before<br>using _any_ of it, I don&#39;t = see it as an issue.</blockquote> <div><br></div><div>My argument is that you shouldn&#39;t have to read the = docs AT ALL to access basic functionality. I say &quot;how do I create a wo= rker thread?&quot;, and someone in the office answers &quot;use std.concurr= ency&quot;, I type std.concurrency and press &#39;.&#39;, everything I care= about appears, and if it&#39;s designed correctly, a momentary glance will= have me headed in the right path. It also reflects on why I really hate se= eing &#39;auto&#39; used in sample code.</div> <div><br></div></div><div><br></div><div>Anyway, it&#39;s irrelevant, Andre= i has spoken :)</div><div><br></div><div>I&#39;m really not just trying to = be a picky bastard for the sake of it... it&#39;s a genuine red flag for me= . And I&#39;m not just raising the point for this single example, I think t= his should be a basic principle applied universally. Every API, before bein= g accepted, should be scrutinised; does the name make perfect sense given c= onventional presumptions of the system? do the args/template args appear ob= vious? At very least just for the key/fundamental parts of the API. Advance= d 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&#39;m not a hobbyist looking to play with a new = toy, I&#39;m trying to be genuinely realistic about what I expect with resp= ect to what else is out there. And it&#39;s not hard. For the most part, la= nguage-wise, D delivers the goods. The library needs polish, but I think ev= eryone 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 yo= u like :)</div></div> --00235429d6d8fbe8d004b75805dd--
Jan 25 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
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 =

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

ons-of-erlang
=20
 Oh come on.. It's niche, unfamiliar to most people, and we're talking =

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.
=20
=20
 I couldn't find any information about a C# API for the same =

=20
 I'm not referring to this API in particular, I'm referring to the =

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 =

requires that the function names make perfect sense, and the argument = lists are as you intuitively expect.
=20
 If I: send(tid, myThing);
 I expect to: myThing =3D receive!SomeThing();
=20
 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 =

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 =

scrolling through the pop-up list of methods, I would not confidently = predict what that does. Matter of opinion I suppose. See above.=
Jan 26 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363f3514993404b774f118
Content-Type: text/plain; charset=UTF-8

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

is successful in its niche. Copying its message passing API is reasonable and safe: Its concurrency model is the main selling point of erlang.

 Oh come on.. It's niche, unfamiliar to most people, and we're talking

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

 I'm not referring to this API in particular, I'm referring to the fairly

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

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. --20cf30363f3514993404b774f118 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 26 January 2012 22:07, Sean Kelly <span dir= =3D"ltr">&lt;<a href=3D"mailto:sean invisibleduck.org">sean invisibleduck.o= rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg= in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Jan 25, 2012, at 2:49 AM, Manu wrote:<br> <br> &gt; On 23 January 2012 02:00, Timon Gehr &lt;<a href=3D"mailto:timon.gehr = gmx.ch">timon.gehr gmx.ch</a>&gt; wrote:<br> &gt; Erlang *has* been used in multiple large projects and it is likely tha= t 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 reasonabl= e and safe: Its concurrency model is the main selling point of erlang.<br> &gt;<br> &gt; <a href=3D"http://programmers.stackexchange.com/questions/112417/real-= world-applications-of-erlang" target=3D"_blank">http://programmers.stackexc= hange.com/questions/112417/real-world-applications-of-erlang</a><br> &gt;<br> &gt; Oh come on.. It&#39;s niche, unfamiliar to most people, and we&#39;re = talking about name and argument list clarity with respect to what would be = instinctive to the most users, not &#39;model&#39; or API design, that&#39;= s obviously fine.<br> <br> </div>Personally, I expected receiveOnly to see infrequent use compared to = receive. =C2=A0At least in my own code, it&#39;s rare that I&#39;d want a r= eceive call to throw if there&#39;s any message in the queue other than the= one I&#39;m looking for. =C2=A0So the naming scheme was a mistaken assumpt= ion of popular use.<br> </blockquote><div><br></div><div>Well perhaps my usage is biased, but I thi= nk many/most threads are spawned with the intent of receiving one particula= r workload from one source. I think a thread that receives a variable/dynam= ic workload is probably less common, although certainly does exist, but reg= ardless of that, from the point of view of API design, I don&#39;t think th= e API clearly communicates that intent. It certainly had me scratching my h= ead until I _read the docs_, which is the basis of my argument.</div> <div>If I&#39;m wrong on that point, then there&#39;s nothing to argue :)</= div><div><br></div><div>(bear in mind, this isn&#39;t the only thing I ment= ioned in my OP. As with prior posts where I&#39;ve made the mistake of list= ing things, the the single most trivial detail in my list is the one that s= pawns the longest conversation ;)</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">&gt; C# is awesome because it gets this right. I think th= at&#39;s its single<br> &gt; greatest achievement, and can not be understated.<br> &gt;<br> &gt;<br> &gt; I couldn&#39;t find any information about a C# API for the same functi= onality. Can you help me out?<br> &gt;<br> &gt; I&#39;m not referring to this API in particular, I&#39;m referring to = the fairly universal application of the principle within the C# libraries. = Most people I&#39;ve ever talked to agree that one of it&#39;s biggest sell= ing points, and possibly even the key reason they use it; because it was so= accessible and productive from the instant they tried it out.<br> &gt; You shouldn&#39;t need to read anything. Pressing &#39;.&#39; in the I= DE shows lists of classes/methods/etc, and common sense writes your code. T= his requires that the function names make perfect sense, and the argument l= ists are as you intuitively expect.<br> &gt;<br> &gt; If I: send(tid, myThing);<br> &gt; I expect to: myThing =3D receive!SomeThing();<br> &gt;<br> &gt; How can you argue that it&#39;s not intuitive to receive what you sent= ?<br> <br> </div>We could overload receive even more so that if it has only one argume= nt and that argument is not a callable type, it does receiveOnly. =C2=A0Tha= t might be deceptive however.</blockquote><div><br></div><div><div><div>I a= gree that&#39;s a pretty ugly approach. I can see your point, but it only m= akes sense to me with advanced knowledge of the API. If I approach it witho= ut that insight, as I did, it&#39;s not so clear, or even misleading.</div> </div></div><div>Consider the position you&#39;re likely to be when you rea= ch for the API, trying to use it for the first time, and you&#39;ve just ty= ped: send(tid, myThing) not 10 seconds prior... what do you expect to type = next?</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex">What I like about &quot;rec= eiveOnly&quot; is that the name itself suggests that anything other than th= e specified type is not expected, and so some measure will probably be take= n.</blockquote> <div><br></div><div>Again, this only makes sense to me if you already expec= t that the act of receiving (as a compliment to the send API, which you&#39= ;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...</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> =C2=A0receive!T says to me &= quot;look for a message of this type and block if it&#39;s not present.&quo= t;<br> </blockquote><div><br></div><div>Perfect. It says that to me too. I&#39;m l= ost now though, this is the behaviour of receiveOnly... are you agreeing no= w? :)</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">&gt; There&#39;s nothing in: send(tid, something); that s= uggests the expected compliment API should take a var-arg list of undefined= things. It&#39;s not clear from receive()&#39;s signature that it should r= eceive delegates, it looks like it could receive anything. The delegate sig= nature is un-knowable from the functions own signature, nor what the delega= tes are even supposed to do.<br> <br> </div>This is an artifact of templates. =C2=A0I doubt C# has this issue bec= ause C# doesn&#39;t have templates.<br></blockquote><div><br></div><div>C# = has generics. Not quite like D templates, more like C++, but still...</div> <div>But in a case like this, such an apparently arguably ambiguous API wou= ldn&#39;t be permitted. It would be restructured, or the competing API&#39;= s both renamed to something more clear.</div><div><br></div><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"> <div class=3D"im">&gt; Also, the name &#39;receiveOnly&#39; doesn&#39;t act= ually make sense unless you *already know* that receive() is effectively re= ceiveMulti. If I was scrolling through the pop-up list of methods, I would = not confidently predict what that does.<br> <br> </div>Matter of opinion I suppose. =C2=A0See above.</blockquote></div><div>= <br></div>Perhaps so. I suppose my mental flow was by drawing a direct cont= rast to the send() API, which I called not 10 seconds prior, before trying = to type my receive code.<div> <br></div><div><br></div><div>Anyway, I think it&#39;s a void topic in this= instance, it&#39;s been stated that it will not change, I&#39;m good with = that.</div><div>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, no= t just in this case) should be=C2=A0indisputably=C2=A0intuitive, and with p= articular consideration to auto-complete listings, which should be self evi= dent enough to do most basic functionality a system offers.</div> --20cf30363f3514993404b774f118--
Jan 26 2012
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jan 26, 2012, at 1:19 PM, Manu wrote:

 On 26 January 2012 22:07, Sean Kelly <sean invisibleduck.org> wrote:
 =20
 What I like about "receiveOnly" is that the name itself suggests that =

measure will probably be taken.
=20
 Again, this only makes sense to me if you already expect that the act =

invoked and have a presumption about), was capable of receiving = any/multiple things, rather than receiving what you just sent a few = lines back...
=20
  receive!T says to me "look for a message of this type and block if =

=20
 Perfect. It says that to me too. I'm lost now though, this is the =

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.
Jan 26 2012