www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Component Programming in D

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

Andrei
Oct 02 2012
next sibling parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei

John D. Cook mentions Walter's talk in his blog post at http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100 I've posted a link to this article in the comments, but it's awaiting moderation.
Oct 02 2012
parent Walter Bright <newshound1 digitalmars.com> writes:
On 10/2/2012 2:51 PM, Rene Zwanenburg wrote:
 John D. Cook mentions Walter's talk in his blog post at
 http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100


 I've posted a link to this article in the comments, but it's awaiting
 moderation.

I had dinner with John last night, we had a great time. His talk on the R programming language was right after mine.
Oct 02 2012
prev sibling next sibling parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Tuesday, 2 October 2012 at 21:51:45 UTC, Rene Zwanenburg wrote:
 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
 wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei

John D. Cook mentions Walter's talk in his blog post at http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100 I've posted a link to this article in the comments, but it's awaiting moderation.

Oops, link should of course be http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/
Oct 02 2012
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei

Nice article!
Oct 02 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/2/12 6:14 PM, Paulo Pinto wrote:
 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/


 Andrei

Nice article!

I liked it the most of all I've read from Walter. Andrei
Oct 02 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 03/10/2012 00:45, Andrei Alexandrescu a écrit :
 On 10/2/12 6:14 PM, Paulo Pinto wrote:
 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/



 Andrei

Nice article!

I liked it the most of all I've read from Walter. Andrei

Same here, this article is shared and loved as it must be !
Oct 02 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/2/12, Rene Zwanenburg <renezwanenburg gmail.com> wrote:
 John D. Cook mentions Walter's talk in his blog post at
 http://www.johndcook.com/blog/2012/10/02/pipelines-and-whirlpools/comment-page-1/#comment-249100

He also mentions there might be a video coming up of the event. If that's true, yay! Nice article, too!
Oct 02 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Tue, 02 Oct 2012 17:27:55 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/
 

Excellent article!
Oct 02 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, October 02, 2012 17:27:55 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in
 _d/

It's definitely the sort of article that we've needed to show what we're trying to do with ranges. - Jonathan M Davis
Oct 02 2012
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei

The article contains a bug due to the pernicious behaviour of seedless reduce. This section: Just to show how flexible algorithms can be, reduce can also compute multiple values with one pass through the data (which is pretty useful for streaming data and would be expensive to save for a second pass through it). Multiple lambdas produce a tuple result, here the sum and sum of squares is computed: int[] arr = [1,2,3,4,5]; auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b); writefln("sum = %s, sum of squares = %s", r[0], r[1]); Which prints: sum = 15, sum of squares = 55 That is the correct answer for the squares but only because 1*1 is 1. The first element of a seedless reduce does not have any operation carried out on it. If we change the array to [2,2,2,2,2] we would expect the squares sum to be 20. It's 18 because the seed element at arr[0] has no operation carried out on it.
Oct 02 2012
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei

The article contains a bug due to the pernicious behaviour of seedless reduce. This section: "Just to show how flexible algorithms can be, reduce can also compute multiple values with one pass through the data (which is pretty useful for streaming data and would be expensive to save for a second pass through it). Multiple lambdas produce a tuple result, here the sum and sum of squares is computed: int[] arr = [1,2,3,4,5]; auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b); writefln("sum = %s, sum of squares = %s", r[0], r[1]); Which prints: sum = 15, sum of squares = 55" That is the correct answer for the squares sum but only because 1*1 is 1, what it's really doing here is 1 + (2 * 2) + (3 * 3) + (4 * 4) + (5 * 5) which happens to work in this case and for "a + b" and "a - b" but is otherwise broken. The first element of a seedless reduce does not have any operation carried out on it. If we change the array to [2,2,2,2,2] we would expect the squares sum to be 20. It's 18 because the seed element at arr[0] has no operation carried out on it other than the addition of the other elements to it.
Oct 02 2012
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 03 Oct 2012 03:05:08 +0200
"Jonathan M Davis" <jmdavisProg gmx.com> wrote:

 On Tuesday, October 02, 2012 17:27:55 Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in
 _d/

It's definitely the sort of article that we've needed to show what we're trying to do with ranges.

Yes, and also why a lot of D's features, esp its metaprogramming features, are so significant. And why most other languages, including dynamic languages, don't even come close. I think I'm starting to get a sense of the next big step, though. There are other misc improvements I'd like to see, but I think the biggest weakness our range approach faces now (even as far ahead as we are) is the effort and, arguably, boilerplate to actually create the ranges. Especially input/forward ranges: It's pretty well known and accepted (esp. to those who have created input/forward ranges) that the easiest way to make a generator is with a straight imperative function. But ranges turn the whole logic inside-out. Walking a tree can get particularly convoluted. So I think the next *big* step from here, in D3 or some other D-derived language, would be easing the creation of ranges. For example, a special low-boilerplate syntax for creating bidirectional and random-access ranges. Or for input (or maybe even forward) ranges, a C#-style compile-time transformation of a generator function into a range (With input ranges, you can technically get around needing source transformation right now in D2 using fibers, but that has too much runtime overhead to be used as a general solution).
Oct 02 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
 So I think the next *big* step from here, in D3 or some other 
 D-derived
 language, would be easing the creation of ranges. For example, a
 special low-boilerplate syntax for creating bidirectional and
 random-access ranges. Or for input (or maybe even forward) 
 ranges, a
 C#-style compile-time transformation of a generator function 
 into a
 range (With input ranges, you can technically get around 
 needing source
 transformation right now in D2 using fibers, but that has too
 much runtime overhead to be used as a general solution).

I don't think we need language support in order to have an easy way to create random access ranges. We could have a function that would be used like this: auto squares = randomAccessRange(len, (size_t i) => i * i); This probably wouldn't have optimal performance, but wouldn't be horribly slow either. Another option would be to have a mixin that would generate all other range methods from a method that would provide random access to the initial (that is, before the first call to popFront or popBack) range and a property that would return the length of the initial range.
Oct 02 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
On Wednesday, 3 October 2012 at 06:15:32 UTC, jerro wrote:
 So I think the next *big* step from here, in D3 or some other 
 D-derived
 language, would be easing the creation of ranges. For example, 
 a
 special low-boilerplate syntax for creating bidirectional and
 random-access ranges. Or for input (or maybe even forward) 
 ranges, a
 C#-style compile-time transformation of a generator function 
 into a
 range (With input ranges, you can technically get around 
 needing source
 transformation right now in D2 using fibers, but that has too
 much runtime overhead to be used as a general solution).

I don't think we need language support in order to have an easy way to create random access ranges. We could have a function that would be used like this: auto squares = randomAccessRange(len, (size_t i) => i * i); This probably wouldn't have optimal performance, but wouldn't be horribly slow either. Another option would be to have a mixin that would generate all other range methods from a method that would provide random access to the initial (that is, before the first call to popFront or popBack) range and a property that would return the length of the initial range.

Never mind, I just realized that is what std.range.sequence already does.
Oct 02 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
ixid:

 The article contains a bug due to the pernicious behaviour of 
 seedless reduce.

Hopefully Walter will be able to fix the article. Bye, bearophile
Oct 03 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Andrei Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

Nice article! There, I found an interesting way of writing ranges that are not explicitly initialized: private import core.stdc.stdio; struct StdinByChar { property bool empty() { if (hasChar) return false; auto c = fgetc(stdin); if (c == EOF) return true; ch = cast(char)c; hasChar = true; return false; } property char front() { return ch; } void popFront() { hasChar = false; } private: char ch; bool hasChar; } This is unusual to me that popFront() code is shifted to empty(), but I guess that's necessary because structs doesn't have () ctors.
Oct 03 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Piotr Szturmaj wrote:
 guess that's necessary because structs doesn't have () ctors.

should be "don't"
Oct 03 2012
prev sibling next sibling parent reply "renoX" <renozyx gmail.com> writes:
I have some mixed feeling about component programming: add in all 
the examples the requirement to give the context (line number for 
example) where something happened (either a match or an error) 
and suddendly component programming becomes much more "tricky"!!

So for me component programming looks good on paper, but not so 
much in the real world..

renoX
Oct 03 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10/03/2012 05:59 PM, renoX wrote:
 I have some mixed feeling about component programming: add in all the
 examples the requirement to give the context (line number for example)
 where something happened (either a match or an error) and suddendly
 component programming becomes much more "tricky"!!

Just zip the range with a range of context information, just as would be done with an explicit loop.
 So for me component programming looks good on paper, but not so much in
 the real world..

 renoX

Oct 03 2012
prev sibling next sibling parent "Martin Friesen" <mhfriesen shaw.ca> writes:
On Wednesday, 3 October 2012 at 01:40:05 UTC, ixid wrote:
 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei Alexandrescu 
 wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei

The article contains a bug due to the pernicious behaviour of seedless reduce. This section: "Just to show how flexible algorithms can be, reduce can also compute multiple values with one pass through the data (which is pretty useful for streaming data and would be expensive to save for a second pass through it). Multiple lambdas produce a tuple result, here the sum and sum of squares is computed: int[] arr = [1,2,3,4,5]; auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b); writefln("sum = %s, sum of squares = %s", r[0], r[1]); Which prints: sum = 15, sum of squares = 55" That is the correct answer for the squares sum but only because 1*1 is 1, what it's really doing here is 1 + (2 * 2) + (3 * 3) + (4 * 4) + (5 * 5) which happens to work in this case and for "a + b" and "a - b" but is otherwise broken. The first element of a seedless reduce does not have any operation carried out on it. If we change the array to [2,2,2,2,2] we would expect the squares sum to be 20. It's 18 because the seed element at arr[0] has no operation carried out on it other than the addition of the other elements to it.

Pernicious? Bug? I've never used D, but it looks obvious that arr.reduce does what it's compile time parameter promises with 'a' as the "seed". It seems that using [0,1,2,3,4,5] or [0]~[1,2,3,4,5] or ([0]~arr).reduce! would have reflected a more general "sum of squares" idea simply enough.
Oct 03 2012
prev sibling next sibling parent "rmr" <rmr mailinator.com> writes:
On Wednesday, 3 October 2012 at 19:11:55 UTC, Martin Friesen 
wrote:
 On Wednesday, 3 October 2012 at 01:40:05 UTC, ixid wrote:
 On Tuesday, 2 October 2012 at 21:27:42 UTC, Andrei 
 Alexandrescu wrote:
 http://www.reddit.com/r/programming/comments/10u6sk/component_programming_in_d/

 Andrei

The article contains a bug due to the pernicious behaviour of seedless reduce. This section: "Just to show how flexible algorithms can be, reduce can also compute multiple values with one pass through the data (which is pretty useful for streaming data and would be expensive to save for a second pass through it). Multiple lambdas produce a tuple result, here the sum and sum of squares is computed: int[] arr = [1,2,3,4,5]; auto r = arr.reduce!((a,b) => a + b, (a,b) => a + b * b); writefln("sum = %s, sum of squares = %s", r[0], r[1]); Which prints: sum = 15, sum of squares = 55" That is the correct answer for the squares sum but only because 1*1 is 1, what it's really doing here is 1 + (2 * 2) + (3 * 3) + (4 * 4) + (5 * 5) which happens to work in this case and for "a + b" and "a - b" but is otherwise broken. The first element of a seedless reduce does not have any operation carried out on it. If we change the array to [2,2,2,2,2] we would expect the squares sum to be 20. It's 18 because the seed element at arr[0] has no operation carried out on it other than the addition of the other elements to it.

Pernicious? Bug? I've never used D, but it looks obvious that arr.reduce does what it's compile time parameter promises with 'a' as the "seed". It seems that using [0,1,2,3,4,5] or [0]~[1,2,3,4,5] or ([0]~arr).reduce! would have reflected a more general "sum of squares" idea simply enough.

Alternatively: auto r = reduce!((a,b) => a + b, (a,b) => a + b * b) (0, arr); Regards, rmr
Oct 03 2012
prev sibling parent "renoX" <renozyx gmail.com> writes:
On Wednesday, 3 October 2012 at 21:40:06 UTC, Timon Gehr wrote:
 On 10/03/2012 05:59 PM, renoX wrote:
 I have some mixed feeling about component programming: add in 
 all the
 examples the requirement to give the context (line number for 
 example)
 where something happened (either a match or an error) and 
 suddendly
 component programming becomes much more "tricky"!!

Just zip the range with a range of context information, just as would be done with an explicit loop.

Yes, of course it's possible, but when you add filename, line numbers, column numbers (etc) the beautiful pipeline looks much less pretty.. Worse: each time you want to add some context, you have to modify the pipeline in a non-local way: take a -> b -> c -> d: you want to have more information in d from a's context, b and c must be modified to propagate the context.. When you have objects which encapsulate contexts, this becomes less an issue.. renoX
 So for me component programming looks good on paper, but not 
 so much in
 the real world..

 renoX


Oct 04 2012