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 reply 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 =

std.concurrency for a great API, and wish that I could easily write = Cocoa applications with it.
=20
 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.
=20
 The std.concurrency module would have made hours of effort in ObjC =

take five minutes in D. Well done!
Jan 19 2012
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 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 reply Manu <turkeyman gmail.com> writes:
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

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 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! :)
Jan 20 2012
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

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

nice to address.
=20
 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. 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 =

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

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

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.=
Jan 20 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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

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

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

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 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.
Jan 21 2012
parent reply "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
next sibling parent Manu <turkeyman gmail.com> writes:
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.
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...=


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


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

=20 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. 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 reply Manu <turkeyman gmail.com> writes:
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
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 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
next sibling parent Manu <turkeyman gmail.com> writes:
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 :)
Jan 22 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
	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 :)

Jan 22 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
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.
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
next sibling parent reply Manu <turkeyman gmail.com> writes:
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.
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 reply Manu <turkeyman gmail.com> writes:
On 23 January 2012 02:00, Timon Gehr <timon.gehr gmx.ch> wrote:

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

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

Oh come on.. It's niche, unfamiliar to most people, and we're talking about name and argument list clarity with respect to what would be instinctive to the most users, not 'model' or API design, that's obviously fine. C# is awesome because it gets this right. I think that's its single
 greatest achievement, and can not be understated.

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

I'm not referring to this API in particular, I'm referring to the fairly universal application of the principle within the C# libraries. Most people I've ever talked to agree that one of it's biggest selling points, and possibly even the key reason they use it; because it was so accessible and productive from the instant they tried it out. You shouldn't need to read anything. Pressing '.' in the IDE shows lists of classes/methods/etc, and common sense writes your code. This requires that the function names make perfect sense, and the argument lists are as you intuitively expect. If I: send(tid, myThing); I expect to: myThing = receive!SomeThing(); How can you argue that it's not intuitive to receive what you sent? There's nothing in: send(tid, something); that suggests the expected compliment API should take a var-arg list of undefined things. It's not clear from receive()'s signature that it should receive delegates, it looks like it could receive anything. The delegate signature is un-knowable from the functions own signature, nor what the delegates are even supposed to do. Also, the name 'receiveOnly' doesn't actually make sense unless you *already know* that receive() is effectively receiveMulti. If I was scrolling through the pop-up list of methods, I would not confidently predict what that does. You MUST read the docs to understand receive(), and that is an instant fail for my money. You don't need to read the docs to understand receiveOnly(), it's perfectly obvious what it does and how it works on sight, and matches what you expect as the natural complement to send(). On 23 January 2012 02:55, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 On Sunday, January 22, 2012 23:18:46 Manu wrote:
 On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org> wrote:
 The popularity of a language has no bearing on the quality of one of


its
 features. Are there other message passing schemes you prefer?

As said in the original post, I think receiveOnly() is the most intuitive API. I just think that one should be named receive(), and perhaps

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

more
 people?

I'm not sure that that's true. But since you have to read the docs before using _any_ of it, I don't see it as an issue.

My argument is that you shouldn't have to read the docs AT ALL to access basic functionality. I say "how do I create a worker thread?", and someone in the office answers "use std.concurrency", I type std.concurrency and press '.', everything I care about appears, and if it's designed correctly, a momentary glance will have me headed in the right path. It also reflects on why I really hate seeing 'auto' used in sample code. Anyway, it's irrelevant, Andrei has spoken :) I'm really not just trying to be a picky bastard for the sake of it... it's a genuine red flag for me. And I'm not just raising the point for this single example, I think this should be a basic principle applied universally. Every API, before being accepted, should be scrutinised; does the name make perfect sense given conventional presumptions of the system? do the args/template args appear obvious? At very least just for the key/fundamental parts of the API. Advanced functionality is sure to exist, can/should have more specific names, and will probably require looking up the docs, sure. I'm not a hobbyist looking to play with a new toy, I'm trying to be genuinely realistic about what I expect with respect to what else is out there. And it's not hard. For the most part, language-wise, D delivers the goods. The library needs polish, but I think everyone knows that. C# has raised the bar, this issue, so trivial as the name/args of the function, lost D a significant number of points at face value with me after it wasted my time and forced me to read the fairly sub-standard docs. I simply expect more these days. You can call me whatever you like :)
Jan 25 2012
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 reply 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 =

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

http://programmers.stackexchange.com/questions/112417/real-world-applicati= ons-of-erlang
=20
 Oh come on.. It's niche, unfamiliar to most people, and we're talking =

about name and argument list clarity with respect to what would be = instinctive to the most users, not 'model' or API design, that's = obviously fine. Personally, I expected receiveOnly to see infrequent use compared to = receive. At least in my own code, it's rare that I'd want a receive = call to throw if there's any message in the queue other than the one I'm = looking for. So the naming scheme was a mistaken assumption of popular = use.
 C# is awesome because it gets this right. I think that's its single
 greatest achievement, and can not be understated.
=20
=20
 I couldn't find any information about a C# API for the same =

functionality. Can you help me out?
=20
 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.
=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 =

compliment API should take a var-arg list of undefined things. It's not = clear from receive()'s signature that it should receive delegates, it = looks like it could receive anything. The delegate signature is = un-knowable from the functions own signature, nor what the delegates are = even supposed to do. This is an artifact of templates. I doubt C# has this issue because C# = doesn't have templates.
 Also, the name 'receiveOnly' doesn't actually make sense unless you =

*already know* that receive() is effectively receiveMulti. If I was = scrolling through the pop-up list of methods, I would not confidently = predict what that does. Matter of opinion I suppose. See above.=
Jan 26 2012
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 next sibling parent reply Manu <turkeyman gmail.com> writes:
On 26 January 2012 22:07, Sean Kelly <sean invisibleduck.org> wrote:

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

 On 23 January 2012 02:00, Timon Gehr <timon.gehr gmx.ch> wrote:
 Erlang *has* been used in multiple large projects and it is likely that

you make use of some service that is powered by erlang on a daily basis. It is successful in its niche. Copying its message passing API is reasonable and safe: Its concurrency model is the main selling point of erlang.

http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang
 Oh come on.. It's niche, unfamiliar to most people, and we're talking

about name and argument list clarity with respect to what would be instinctive to the most users, not 'model' or API design, that's obviously fine. Personally, I expected receiveOnly to see infrequent use compared to receive. At least in my own code, it's rare that I'd want a receive call to throw if there's any message in the queue other than the one I'm looking for. So the naming scheme was a mistaken assumption of popular use.

Well perhaps my usage is biased, but I think many/most threads are spawned with the intent of receiving one particular workload from one source. I think a thread that receives a variable/dynamic workload is probably less common, although certainly does exist, but regardless of that, from the point of view of API design, I don't think the API clearly communicates that intent. It certainly had me scratching my head until I _read the docs_, which is the basis of my argument. If I'm wrong on that point, then there's nothing to argue :) (bear in mind, this isn't the only thing I mentioned in my OP. As with prior posts where I've made the mistake of listing things, the the single most trivial detail in my list is the one that spawns the longest conversation ;)
 C# is awesome because it gets this right. I think that's its single
 greatest achievement, and can not be understated.


 I couldn't find any information about a C# API for the same

functionality. Can you help me out?
 I'm not referring to this API in particular, I'm referring to the fairly

universal application of the principle within the C# libraries. Most people I've ever talked to agree that one of it's biggest selling points, and possibly even the key reason they use it; because it was so accessible and productive from the instant they tried it out.
 You shouldn't need to read anything. Pressing '.' in the IDE shows lists

of classes/methods/etc, and common sense writes your code. This requires that the function names make perfect sense, and the argument lists are as you intuitively expect.
 If I: send(tid, myThing);
 I expect to: myThing = receive!SomeThing();

 How can you argue that it's not intuitive to receive what you sent?

We could overload receive even more so that if it has only one argument and that argument is not a callable type, it does receiveOnly. That might be deceptive however.

I agree that's a pretty ugly approach. I can see your point, but it only makes sense to me with advanced knowledge of the API. If I approach it without that insight, as I did, it's not so clear, or even misleading. Consider the position you're likely to be when you reach for the API, trying to use it for the first time, and you've just typed: send(tid, myThing) not 10 seconds prior... what do you expect to type next?
 What I like about "receiveOnly" is that the name itself suggests that
 anything other than the specified type is not expected, and so some measure
 will probably be taken.

Again, this only makes sense to me if you already expect that the act of receiving (as a compliment to the send API, which you've already invoked and have a presumption about), was capable of receiving any/multiple things, rather than receiving what you just sent a few lines back... receive!T says to me "look for a message of this type and block if it's
 not present."

Perfect. It says that to me too. I'm lost now though, this is the behaviour of receiveOnly... are you agreeing now? :)
 There's nothing in: send(tid, something); that suggests the expected
 compliment API should take a var-arg list of undefined things. It's not
 clear from receive()'s signature that it should receive delegates, it looks
 like it could receive anything. The delegate signature is un-knowable from
 the functions own signature, nor what the delegates are even supposed to do.

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

C# has generics. Not quite like D templates, more like C++, but still... But in a case like this, such an apparently arguably ambiguous API wouldn't be permitted. It would be restructured, or the competing API's both renamed to something more clear.
 Also, the name 'receiveOnly' doesn't actually make sense unless you
 *already know* that receive() is effectively receiveMulti. If I was
 scrolling through the pop-up list of methods, I would not confidently
 predict what that does.

 Matter of opinion I suppose.  See above.

Perhaps so. I suppose my mental flow was by drawing a direct contrast to the send() API, which I called not 10 seconds prior, before trying to type my receive code. Anyway, I think it's a void topic in this instance, it's been stated that it will not change, I'm good with that. I was just trying to raise the point that I think more care should be taken to the end that the standard library (across the board, not just in this case) should be indisputably intuitive, and with particular consideration to auto-complete listings, which should be self evident enough to do most basic functionality a system offers.
Jan 26 2012
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 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 =

anything other than the specified type is not expected, and so some = measure will probably be taken.
=20
 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...
=20
  receive!T says to me "look for a message of this type and block if =

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

behaviour of receiveOnly... are you agreeing now? :) It's only the behavior of receiveOnly if the queue is completely empty. = If it contains any other message, receiveOnly will throw. But from what = you've said I think this is simply a difference in how we design apps. = For me, it's common to send multiple message types. For you, it sounds = like it is not.
Jan 26 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
	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=

rg> wrote:
 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=

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

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

thers 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 la= rge-ish projects?
 It's a shame that basic usability things like that couldn't be caught earl=

ier.
=20
 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 be= fore) is a far more intuitive approach?
 C# is awesome because it gets this right. I think that's its single greate=

st achievement, and can not be understated.
=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=

ake enhancement requests on bugzilla.
=20
 Shall do one or the other.

Jan 22 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
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 :)
Jan 23 2012
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
	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=

arge projects aren't an issue. I've worked on some counted in millions of li= nes of code.
=20
 Why even argue this? What's the point in intentionally making D unappealin=

g 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 con=

sider windows users, and 'IDE users' in general, a niche or minority user ba= 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=
Jan 21 2012
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 parent Manu <turkeyman gmail.com> writes:
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.
Jan 21 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
	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=


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


d ownership. If a spawned threads parent thread dies, it also receives a sig= 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=


eads 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 s=


omehow, rather than a child of the transient B... Some mechanism to solve th= is sort of problem would be useful.
=20
 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 implementatio= n would probably be sufficient for your needs.
=20
=20
 Another usability problem I had was that, intuitively, the simpler funct=


ion 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.
=20
 Matter of opinion.  I think receiveOnly indicates what the function does, a=

nd I think it's important to indicate that receiving anything else is unexpe= cted and will trigger an error.
=20
 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#, j= 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=

e a tight well-defined expectation of send/receive types. receiveOnly() seem= 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=

st 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, 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=


most always want to use... and receiveTimeout() didn't actually work for me a= 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=

n value that indicates a timeout occurred. If receiving a duration (ie. a n= 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=

ortant function for my money. I think many usages will not want to block ind= efinitely.
=20
 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 n= ice or intuitive.
 Consider the Win32 message loop: PeekMessage/GetMessage/WaitMessage.. I th=

ink they're all good to have.
=20
=20
 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.
=20
 I think Unique!T should work for the sending side, and then the receive si=

de wouldn't have to receive shared(T). It's something that's been on the ra= 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.

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.

Well you know the obvious extension, extending this to IPC, networking and 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 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