On Thursday, 1 August 2013 at 00:47:43 UTC, H. S. Teoh wrote:
> On Wed, Jul 31, 2013 at 11:52:35PM +0000, Justin Whear wrote:
>> On Thu, 01 Aug 2013 00:23:52 +0200, bearophile wrote:
>> > 
>> > The situation should be improved for D/dmd/Phobos, otherwise such D
>> > component programming remains partially a dream, or a toy.
>> > 
>> > Bye,
>> > bearophile
>> 
>> I disagree with your "toy" assessment.  I've been using this chaining,
>> component style for a while now and have really enjoyed the clarity
>> it's brought to my code.  I hadn't realized how bug-prone non-trivial
>> loops tend to be until I started writing this way and avoided them
>> entirely.
> [...]
>
> One of the more influential courses I took in college was on Jackson
> Structured Programming. It identified two sources of programming
> complexity (i.e., where bugs are most likely to occur): (1) mismatches
> between the structure of the program and the structure of the data
> (e.g., you're reading an input file that has a preamble, body, and
> epilogue, but your code has a single loop over lines in the file); (2)
> writing loop invariants (or equivalently, loop conditions).
>
> Most non-trivial loops in imperative code have both, which makes them
> doubly prone to bugs. In the example I gave above, the mismatch between
> the code structure (a single loop) and the file structure (three
> sequential sections) often prompts people to add boolean flags, state
> variables, and the like, in order to resolve the conflict between the
> two structures. Such ad hoc structure resolutions are a breeding ground
> for bugs, and often lead to complicated loop conditions, which invite
> even more bugs.
>
> In contrast, if you structure your code according to the structure of
> the input (i.e., one loop for processing the preamble, one loop for
> processing the body, one loop for processing the epilogue), it becomes
> considerably less complex, easier to read (and write!), and far less bug
> prone. Your loop conditions become simpler, and thus easier to reason
> about and leave less room for bugs to hide.
>
> But to be able to process the input in this way requires that you
> encapsulate your input so that it can be processed by 3 different loops.
> Once you go down that road, you start to arrive at the concept of input
> ranges... then you abstract away the three loops into three components,
> and behold, component style programming!
>
> In fact, with component style programming, you can also address another
> aspect of (1): when you need to simultaneously process two data
> structures whose structures don't match. For example, if you want to lay
> out a yearly calendar using writeln, the month/day cells must be output
> in a radically different order than the logical foreach(m;1..12) {
> foreach(day;1..31) } structure). Writing this code in the traditional
> imperative style produces a mass of spaghettii code: either you have
> bizarre loops with convoluted loop conditions for generating the dates
> in the order you want to print them, or you have to fill out some kind
> of grid structure in a complicated order so that you can generate the
> dates in order.
>
> Using ranges, though, this becomes considerably more tractable: you can
> have an input range of dates in chronological order, two output ranges
> corresponding to chunking by week / month, which feed into a third
> output range that buffers the generated cells and prints them once
> enough has been generated to fill a row of output. By separating out
> these non-corresponding structures into separate components, you greatly
> simplify the code within each component and thus reduce the number of
> bugs (e.g. it's far easier to ensure you never put more than 7 days in a
> week, since the weekly output range is all in one place, as opposed to
> sprinkled everywhere across multiple nested loops in the imperative
> style calendar code). The code that glues these components together is
> also separated out and becomes easier to understand and debug: you
> simply read from the input range of dates, write to the two output
> ranges, and check if they are full (this isn't part of the range API but
> added so for this particular example); if the weekly range is full,
> start a new week; if the monthly range is full, start a new month. Then
> the final output range takes care of when to actually produce output --
> you just write stuff to it and don't worry about it in the glue code.
>
> OK, this isn't really a good example of the linear pipeline style code
> we're talking about, but it does show how using ranges as components can
> untangle very complicated code into simple, tractable parts that are
> readable and easy to debug.
>
>
> T

This post deserves to become an article somewhere. D Wiki, some blog, whatever. All to the point. Respect.

On Thursday, 1 August 2013 at 16:13:55 UTC, Andrei Alexandrescu
wrote:
> On 7/31/13 6:40 PM, bearophile wrote:
>> According to this article it seems better, but I have no direct
>> experience of it:
>>
>> http://www.leafpetersen.com/leaf/publications/hs2013/haskell-gap.pdf
>
> ERROR 404 - PAGE NOT FOUND
>
> Andrei

This one, perhaps?

http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf

Bye

On 8/1/2013 2:23 AM, John Colvin wrote:
> On Thursday, 1 August 2013 at 00:47:43 UTC, H. S. Teoh wrote:
> Add in some code examples and that could make a nice article.

Yes, please!

anonymous observer:

>> ERROR 404 - PAGE NOT FOUND
>>
>> Andrei
>
> This one, perhaps?
>
> http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf

Yes, it's the same, thank you.

Another comparison (I have not yet read this):
http://www.leafpetersen.com/leaf/publications/hs2013/hrc-paper.pdf

Bye,
bearophile

On Wednesday, 31 July 2013 at 22:23:54 UTC, bearophile wrote:
> <snip>
> Currently this code inlines nothing (the allocations, the difference and the product):
>
> <snip>
>
> If you write it in component-style (using doubles here):
>
> <snip>

Resident compiler guys,

How difficult would it be to make sure stuff like this gets inlined and optimized more thoroughly?  I'm very ignorant of compiler internals but it's kind of disheartening that LDC can't inline them well despite being a fairly good optimizing compiler.  Is this a frontend issue or a backend issue?

On Thursday, 1 August 2013 at 07:23:42 UTC, Meta wrote:
> The one thing that confused me at first when I read Walter's article was that I thought he was talking about the *other* component programming, a method commonly used by game developers to avoid deep class hierarchies.
>
> http://gameprogrammingpatterns.com/component.html

"Component programing" is kind of a crowded term in programming which means a lot of different things to different people.  Digital Mars should trademark a new term for it like Ultra Stream Processing™.

Steven Schveighoffer may object to the use of the word "stream" without a read/write interface though :P.

On 8/1/2013 2:35 PM, Brad Anderson wrote:
> How difficult would it be to make sure stuff like this gets inlined and
> optimized more thoroughly?  I'm very ignorant of compiler internals but it's
> kind of disheartening that LDC can't inline them well despite being a fairly
> good optimizing compiler.  Is this a frontend issue or a backend issue?

I don't know.

But consider that optimizers are built to optimize typical code patterns. Component programming is fairly non-existent in C and C++, and is new in D. Hence, optimizers are not set up to deal with those patterns (yet).

On Thu, Aug 01, 2013 at 11:40:21PM +0200, Brad Anderson wrote:
> On Thursday, 1 August 2013 at 07:23:42 UTC, Meta wrote:
> >The one thing that confused me at first when I read Walter's article was that I thought he was talking about the *other* component programming, a method commonly used by game developers to avoid deep class hierarchies.
> >
> >http://gameprogrammingpatterns.com/component.html
> 
> "Component programing" is kind of a crowded term in programming which means a lot of different things to different people.  Digital Mars should trademark a new term for it like Ultra Stream Processing™.
> 
> Steven Schveighoffer may object to the use of the word "stream" without a read/write interface though :P.

What about "Ultra Range Processing"? :)


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its flaws.

On Thursday, 1 August 2013 at 21:55:56 UTC, H. S. Teoh wrote:
> On Thu, Aug 01, 2013 at 11:40:21PM +0200, Brad Anderson wrote:
>> On Thursday, 1 August 2013 at 07:23:42 UTC, Meta wrote:
>> >The one thing that confused me at first when I read Walter's
>> >article was that I thought he was talking about the *other*
>> >component programming, a method commonly used by game developers
>> >to avoid deep class hierarchies.
>> >
>> >http://gameprogrammingpatterns.com/component.html
>> 
>> "Component programing" is kind of a crowded term in programming
>> which means a lot of different things to different people.  Digital
>> Mars should trademark a new term for it like Ultra Stream
>> Processing™.
>> 
>> Steven Schveighoffer may object to the use of the word "stream"
>> without a read/write interface though :P.
>
> What about "Ultra Range Processing"? :)
>
>
> T

Range-Flow Processing.

Flow referring to the L->R data flow of ranges + std.algorithm + UFCS

Even just Data Flow Processing would be ok, then you could say Range-based Data Flow Processing and sound uber-cool :p

On Thursday, 1 August 2013 at 22:01:08 UTC, John Colvin wrote:
> On Thursday, 1 August 2013 at 21:55:56 UTC, H. S. Teoh wrote:
>> On Thu, Aug 01, 2013 at 11:40:21PM +0200, Brad Anderson wrote:
>>> On Thursday, 1 August 2013 at 07:23:42 UTC, Meta wrote:
>>> >The one thing that confused me at first when I read Walter's
>>> >article was that I thought he was talking about the *other*
>>> >component programming, a method commonly used by game developers
>>> >to avoid deep class hierarchies.
>>> >
>>> >http://gameprogrammingpatterns.com/component.html
>>> 
>>> "Component programing" is kind of a crowded term in programming
>>> which means a lot of different things to different people.  Digital
>>> Mars should trademark a new term for it like Ultra Stream
>>> Processing™.
>>> 
>>> Steven Schveighoffer may object to the use of the word "stream"
>>> without a read/write interface though :P.
>>
>> What about "Ultra Range Processing"? :)
>>
>>
>> T
>
> Range-Flow Processing.
>
> Flow referring to the L->R data flow of ranges + std.algorithm + UFCS
>
> Even just Data Flow Processing would be ok, then you could say Range-based Data Flow Processing and sound uber-cool :p

Alternatively, substitute Procesing with Programming.