October 26, 2006
Walter Bright wrote:

> The saving grace about foreach_reverse is:
> 
> 1) Only a small (5% ?) of loops will be reverse, so you won't see it or need to type it that often.

A good reason why it doesn't deserve its own keyword.

> 2) It's very clear what it does.

And  'foreach(i; list.reversed)' is pretty clear as well.

> 3) It isn't likely to conflict with other names.

Because it's a 15 letter keyword with an underscore!  While we're at it, let's make a for_i_equals_one_to_ten keyword, too.  I loop from 1 to 10 a lot in my code (well, not that much really <5%, but at least it's a name that's not likely to conflict with other names).

> 4) It is analogous with C++'s reverse_iterator names.

But those aren't keywords.  And even more analogous is STL's std::for_each in the standard header 'algorithm'.
   http://www.sgi.com/tech/stl/for_each.html
Note that STL does not have a std::for_each_reverse.  You get that behavior, as you might expect, by using a reverse iterator instead of a forward iterator as the argument.


And in another message Walter Bright wrote:

> foreach_reverse was pretty trivial to implement. All the machinery was > already there.

That should be setting off warning bells in your head, too.  "The machinery is already there" is just another way of saying "this feature is mostly redundant". The foreach machinery already does the job. foreach_reverse is more or less just a copy-paste of that code with all references to "opApply" replaced with "opApplyReverse".  So of course it's trivial to implement.

I'll repeat a line from the "zen of python" one more time, at the risk of being told that 'D isn't Python', because I think it's true regardless of the language:

  "Special cases aren't special enough to break the rules."

As I understand it, the only real reason for foreach_reverse, when it comes down to it, is because of a strong desire to have a special case fast reverse iteration for arrays and strings.  But it really should be possible to hide that special case from the user and just detect some particular property e.g. "some_array.reversed" in a foreach statement. It may be a little more work (and maybe you just punt on the optimization till 2.0), but in the long run, the language and all it's users will benefit from removing that special case.

--bb
October 26, 2006
On Wed, 25 Oct 2006 18:45:25 -0700, Bill Baxter <dnewsgroup@billbaxter.com> wrote:

> Walter Bright wrote:
>
>> The saving grace about foreach_reverse is:
>>  1) Only a small (5% ?) of loops will be reverse, so you won't see it or need to type it that often.
>
> A good reason why it doesn't deserve its own keyword.
>

Agree.


>> 2) It's very clear what it does.
>
> And  'foreach(i; list.reversed)' is pretty clear as well.
>


Agree again... That looks much bettter!  For arrays, I'm sure such a property could be special-cased to remove any risk of creating a new reversed array in place.


>> 3) It isn't likely to conflict with other names.
>
> Because it's a 15 letter keyword with an underscore!  While we're at it, let's make a for_i_equals_one_to_ten keyword, too.  I loop from 1 to 10 a lot in my code (well, not that much really <5%, but at least it's a name that's not likely to conflict with other names).
>


Agree.


>> 4) It is analogous with C++'s reverse_iterator names.
>
> But those aren't keywords.  And even more analogous is STL's std::for_each in the standard header 'algorithm'.
>     http://www.sgi.com/tech/stl/for_each.html
> Note that STL does not have a std::for_each_reverse.  You get that behavior, as you might expect, by using a reverse iterator instead of a forward iterator as the argument.
>
>


Agree... I'm afraid I'm already biased against any train of thought that basically reduces to "so D can do it /like/ C++".  But, alas, Walter is biased oppositely (darn diodes).


> And in another message Walter Bright wrote:
>
>  > foreach_reverse was pretty trivial to implement. All the machinery was > already there.
>
> That should be setting off warning bells in your head, too.  "The machinery is already there" is just another way of saying "this feature is mostly redundant". The foreach machinery already does the job. foreach_reverse is more or less just a copy-paste of that code with all references to "opApply" replaced with "opApplyReverse".  So of course it's trivial to implement.
>
> I'll repeat a line from the "zen of python" one more time, at the risk of being told that 'D isn't Python', because I think it's true regardless of the language:
>
>    "Special cases aren't special enough to break the rules."
>
> As I understand it, the only real reason for foreach_reverse, when it comes down to it, is because of a strong desire to have a special case fast reverse iteration for arrays and strings.  But it really should be possible to hide that special case from the user and just detect some particular property e.g. "some_array.reversed" in a foreach statement. It may be a little more work (and maybe you just punt on the optimization till 2.0), but in the long run, the language and all it's users will benefit from removing that special case.
>


I've heard Walter's arguments, and I acknowledge some of his reasons aren't completely arbitrary (are they ever?).  Nonetheless, I still think foreach_reverse is a mistake and a cheap addition to D.  I really hope it doesn't last in its current form.  Other people may find it easy to accept foreach_reverse because (1) it fixes a problem they see in front of them here and now (in which case it's very hard to refuse the quick fix) or (2) they are getting tired of arguing with Walter every time a ugly feature gets added, and they figure it's not worth the effort to argue the matter out. :)  Either way, I think most of us are giving up.  Unfortunately, this is the way the D design continues to be done.

At the same time, I do feel sorry for Walter when I see all the language feature suggestions that go on in this newsgroup.  A whole lot of people seem to have there pet feature that they want in D.  It's scary to think of what would happen if everyone got their wish. :P

All I hope, in this situation, is that Walter starts agreeing with Bill's points.

-JJR
October 26, 2006
Bill Baxter wrote:
> Walter Bright wrote:
> 
>> The saving grace about foreach_reverse is:
>>
>> 1) Only a small (5% ?) of loops will be reverse, so you won't see it or need to type it that often.
> 
> 
> A good reason why it doesn't deserve its own keyword.
> 
>> 2) It's very clear what it does.
> 
> 
> And  'foreach(i; list.reversed)' is pretty clear as well.

Sure, and primitive arrays already have the .reverse property; however, that means extra temporaries that hit performance and memory usage.  Both these hits are canceled out by adding foreach_reverse.  The presence of opApplyReverse is primarily for completeness, and for generalization within templates.

>> 3) It isn't likely to conflict with other names.
> 
> 
> Because it's a 15 letter keyword with an underscore!  While we're at it, let's make a for_i_equals_one_to_ten keyword, too.  I loop from 1 to 10 a lot in my code (well, not that much really <5%, but at least it's a name that's not likely to conflict with other names).
> 
>> 4) It is analogous with C++'s reverse_iterator names.
> 
> 
> But those aren't keywords.  And even more analogous is STL's std::for_each in the standard header 'algorithm'.
>    http://www.sgi.com/tech/stl/for_each.html
> Note that STL does not have a std::for_each_reverse.  You get that behavior, as you might expect, by using a reverse iterator instead of a forward iterator as the argument.
> 
> 
> And in another message Walter Bright wrote:
> 
>  > foreach_reverse was pretty trivial to implement. All the machinery was > already there.
> 
> That should be setting off warning bells in your head, too.  "The machinery is already there" is just another way of saying "this feature is mostly redundant". The foreach machinery already does the job. foreach_reverse is more or less just a copy-paste of that code with all references to "opApply" replaced with "opApplyReverse".  So of course it's trivial to implement.
> 
> I'll repeat a line from the "zen of python" one more time, at the risk of being told that 'D isn't Python', because I think it's true regardless of the language:
> 
>   "Special cases aren't special enough to break the rules."
> 
> As I understand it, the only real reason for foreach_reverse, when it comes down to it, is because of a strong desire to have a special case fast reverse iteration for arrays and strings.  But it really should be possible to hide that special case from the user and just detect some particular property e.g. "some_array.reversed" in a foreach statement. It may be a little more work (and maybe you just punt on the optimization till 2.0), but in the long run, the language and all it's users will benefit from removing that special case.
> 
> --bb

Mostly agreeable.  However, neither does the language nor its users suffer from having the foreach_reverse statement.

-- Chris Nicholson-Sauls
October 26, 2006
On Wed, 25 Oct 2006 20:53:22 -0700, Chris Nicholson-Sauls <ibisbasenji@gmail.com> wrote:


> Mostly agreeable.  However, neither does the language nor its users suffer from having the foreach_reverse statement.
>
> -- Chris Nicholson-Sauls


I disagree. I believe that D's image suffers.  But I guess that's yet to be seen.

-JJR
October 26, 2006
Chris Nicholson-Sauls wrote:
> Bill Baxter wrote:

>> And  'foreach(i; list.reversed)' is pretty clear as well.
> 
> Sure, and primitive arrays already have the .reverse property; however, that means extra temporaries that hit performance and memory usage.  

That's why I said 'reversed' with a -d, which could be a property of arrays
that returns an opApply-style delegate (and could be implemented by classes and structs that care to as well).

> Both these hits are canceled out by adding foreach_reverse.  

Well, technically both of those hits are canceled out by a special case optimization in the compiler that checks if the argument of foreach_reverse is an array.  Having a foreach_reverse keyword just makes that optimization opportunity easier to spot.  The same optimization could be applied using 'foreach' by noticing that the argument of the foreach is a particular property of an array (.reversed .reverse_iter .opApplyReverse ... whatever).

> The presence of opApplyReverse is primarily for completeness,

If you want completeness then you'll need to add foreach_inorder, foreach_preorder, foreach_postorder, foreach_randomized, foreach_every_other_one ... etc.

> and for generalization within templates.

Yes that was something Walter said, but I still don't think I've seen a concrete example of how this makes generic templates easier.  If I'm going to write a generic template that processes some items, I would think the best way to make it general (with the delegate-style iterator paradigm) would be to have the user pass in whatever delegate they want for iterating in whatever order they want.

I guess if you want to iterate backwards over items in a template it's useful, but that's more of a specialization than a generalization.  And that case could be handled just as well by unilaterally declaring opApplyReverse to be the "official name" of the reverse iterator method, and adding a corresponding opApplyReverse property to arrays.  Similarly in C++, the names "iterator" and "reverse_iterator" are just conventions.  You don't have to name your class's iterator that, but you should, because it will make your class more compatible with other people's code, and will be more readable to others.


>>   "Special cases aren't special enough to break the rules."
>>
>> As I understand it, the only real reason for foreach_reverse, when it comes down to it, is because of a strong desire to have a special case fast reverse iteration for arrays and strings.  But it really should be possible to hide that special case from the user and just detect some particular property e.g. "some_array.reversed" in a foreach statement. It may be a little more work (and maybe you just punt on the optimization till 2.0), but in the long run, the language and all it's users will benefit from removing that special case.
>>
>> --bb
> 
> Mostly agreeable.  However, neither does the language nor its users suffer from having the foreach_reverse statement.

The price of a poorly thought-out feature in a language can have repercussions beyond how it affects one's day to day writing of code.

Already there have been a few people here who looked at foreach_reverse and said "if this is representative of D, then I'll find another alternative, thank you".  If the community shrinks, or fails to grow as it could, then that certainly impacts all D users.  It's all about the network effect.  I can say for myself when I saw the foreach_reverse addition it seriously made me consider whether there was any hope for D long term.  If this is the kind of design decision being made today, then what hope is there for the long term?  There's no Bell Labs or Sun Microsystems backing it, so it can't just power its way through bad design.  It's got to compete on quality.

As another example of the importance of intangibles in the network effect, folks here have repeatedly mentioned Nemerle's syntax extension / lisp-like macro system.  The fact that people spoke highly of it here got me curious enough to go take a look at it.  I gave up on it after I saw it was a .NET thing, but still it was the network effect trying to take hold of me, and it probably would have kept me if I were in the target audience for Nemerle.

And I can say that personally I haven't done much evangelizing of D precisely because of issues like this.  One of the main attractions of D is the promise of a C++ designed properly.  That's a compelling story. If I could genuinely tell people "check out D -- it's C++ designed properly" then I would.  But right now, although D fixes many design problems and inconsistencies in C++, it introduces many others. foreach_reverse is definitely one such case of taking a step backwards from C++ in terms of design.

A good yardstick for how foreach_reverse -- or any such design issue -- may impact the network effect could be to poll the top contributors to D.  I think we can agree that these people are good for D, and it would be good for D to attract more people like them.  What do these MVPs think of the feature?  If it by-in-large turns them off, then probably it's a bad idea.  If it's 50/50 or greater then, fine, maybe we should have more features like foreach_reverse.

The bottom line is there aren't that many markets that really need the speed/efficiency of C++ any more.  Games, 3D software, multimedia, numerical and scientific computing, operating systems, databases/datamining, embedded systems.  That's about all I can think of.  Python and Ruby are probably fast enough for 80% of all applications, and Java is fast enough for %50 of what's left.  So D needs some powerful network effect going for it in order to avoid just withering away.  It needs to soak up as much of that last 10% as possible.  How?  You need people to love the language.  You need people to want to gush about it and love it so much that they're driven to write crazy stuff like this about it:
    http://poignantguide.net/ruby/chapter-2.html#section3
People don't gush about Visual Basic.  It gets the job done, but it's ugly, inconsistent, and idiosyncratic.  They gush about Ruby.  Why? What I keep hearing is things like "it's beautiful" "it's elegant" "it's expressive".  All that says to me a good, clean, concise, and consistent design.

This iterator stuff has got to be done right if iterators are to become a truly core concept in D.  If they are perceived as clunky or limited or inelegant, it will hurt D.

--bb
October 26, 2006
Bill Baxter wrote:

> The price of a poorly thought-out feature in a language can have repercussions beyond how it affects one's day to day writing of code.

It's a keyword with an underscore. Big deal. No one has to use it. I really think this is being blown way out of proportion. I've read all of these arguments against foreach_reverse and they just don't make sense to me. How is it poorly thought out? It makes perfect sense to me.

> 
> Already there have been a few people here who looked at foreach_reverse and said "if this is representative of D, then I'll find another alternative, thank you".  If the community shrinks, or fails to grow as it could, then that certainly impacts all D users.  It's all about the network effect.  I can say for myself when I saw the foreach_reverse addition it seriously made me consider whether there was any hope for D long term.  If this is the kind of design decision being made today, then what hope is there for the long term?  There's no Bell Labs or Sun Microsystems backing it, so it can't just power its way through bad design.  It's got to compete on quality.

People who turn away from D because of one keyword they find unusual can stay away. I wouldn't want to work with such people. Programmers can be a fickle lot, but that's ridiculous in the extreme. It's like the C++ programmer who says, "If your code uses char*, you have a bug."

There are other issues in D that are more likely to, and have, turned people away, as I see it. A keyword with an underscore that no one even need use is nothing.
October 26, 2006
Completely agree with below !

vote++ to remove foreach_reverse

Marcin Kuszczak
Aarti_pl

------------------------

Bill Baxter wrote:

> Walter Bright wrote:
> 
>> The saving grace about foreach_reverse is:
>> 
>> 1) Only a small (5% ?) of loops will be reverse, so you won't see it or
>> need to type it that often.
> 
> A good reason why it doesn't deserve its own keyword.
> 
>> 2) It's very clear what it does.
> 
> And  'foreach(i; list.reversed)' is pretty clear as well.
> 
>> 3) It isn't likely to conflict with other names.
> 
> Because it's a 15 letter keyword with an underscore!  While we're at it, let's make a for_i_equals_one_to_ten keyword, too.  I loop from 1 to 10 a lot in my code (well, not that much really <5%, but at least it's a name that's not likely to conflict with other names).
> 
>> 4) It is analogous with C++'s reverse_iterator names.
> 
> But those aren't keywords.  And even more analogous is STL's
> std::for_each in the standard header 'algorithm'.
>     http://www.sgi.com/tech/stl/for_each.html
> Note that STL does not have a std::for_each_reverse.  You get that
> behavior, as you might expect, by using a reverse iterator instead of a
> forward iterator as the argument.
> 
> 
> And in another message Walter Bright wrote:
> 
>  > foreach_reverse was pretty trivial to implement. All the machinery
> was > already there.
> 
> That should be setting off warning bells in your head, too.  "The machinery is already there" is just another way of saying "this feature is mostly redundant". The foreach machinery already does the job. foreach_reverse is more or less just a copy-paste of that code with all references to "opApply" replaced with "opApplyReverse".  So of course it's trivial to implement.
> 
> I'll repeat a line from the "zen of python" one more time, at the risk of being told that 'D isn't Python', because I think it's true regardless of the language:
> 
>    "Special cases aren't special enough to break the rules."
> 
> As I understand it, the only real reason for foreach_reverse, when it comes down to it, is because of a strong desire to have a special case fast reverse iteration for arrays and strings.  But it really should be possible to hide that special case from the user and just detect some particular property e.g. "some_array.reversed" in a foreach statement. It may be a little more work (and maybe you just punt on the optimization till 2.0), but in the long run, the language and all it's users will benefit from removing that special case.
> 
> --bb

-- 
Regards
Marcin Kuszczak
(Aarti_pl)
October 26, 2006
John Reimer wrote:

> (2)
> they are getting tired of arguing with Walter every time a ugly feature
> gets added, and they figure it's not worth the effort to argue the matter
> out. :)  Either way, I think most of us are giving up.  Unfortunately,
> this is the way the D design continues to be done.

It can be so true...

I would never argue so long as a few 'hero fighters' - I just don't have so much time and motivation :-|

So Walter, please remember that they just wants to find out good, general solution :-)

-- 
Regards
Marcin Kuszczak
(Aarti_pl)
October 26, 2006
Marcin Kuszczak wrote:
> Completely agree with below !
> 
> vote++ to remove foreach_reverse
> 
> Marcin Kuszczak
> Aarti_pl
> 
> ------------------------
> 
> Bill Baxter wrote:
> 
>> Walter Bright wrote:
>>
>>> The saving grace about foreach_reverse is:
>>>
>>> 1) Only a small (5% ?) of loops will be reverse, so you won't see it or
>>> need to type it that often.
>> A good reason why it doesn't deserve its own keyword.
>>
>>> 2) It's very clear what it does.
>> And  'foreach(i; list.reversed)' is pretty clear as well.
>>
>>> 3) It isn't likely to conflict with other names.
>> Because it's a 15 letter keyword with an underscore!  While we're at it,
>> let's make a for_i_equals_one_to_ten keyword, too.  I loop from 1 to 10
>> a lot in my code (well, not that much really <5%, but at least it's a
>> name that's not likely to conflict with other names).
>>
>>> 4) It is analogous with C++'s reverse_iterator names.
>> But those aren't keywords.  And even more analogous is STL's
>> std::for_each in the standard header 'algorithm'.
>>     http://www.sgi.com/tech/stl/for_each.html
>> Note that STL does not have a std::for_each_reverse.  You get that
>> behavior, as you might expect, by using a reverse iterator instead of a
>> forward iterator as the argument.
>>
>>
>> And in another message Walter Bright wrote:
>>
>>  > foreach_reverse was pretty trivial to implement. All the machinery
>> was > already there.
>>
>> That should be setting off warning bells in your head, too.  "The
>> machinery is already there" is just another way of saying "this feature
>> is mostly redundant". The foreach machinery already does the job.
>> foreach_reverse is more or less just a copy-paste of that code with all
>> references to "opApply" replaced with "opApplyReverse".  So of course
>> it's trivial to implement.
>>
>> I'll repeat a line from the "zen of python" one more time, at the risk
>> of being told that 'D isn't Python', because I think it's true
>> regardless of the language:
>>
>>    "Special cases aren't special enough to break the rules."
>>
>> As I understand it, the only real reason for foreach_reverse, when it
>> comes down to it, is because of a strong desire to have a special case
>> fast reverse iteration for arrays and strings.  But it really should be
>> possible to hide that special case from the user and just detect some
>> particular property e.g. "some_array.reversed" in a foreach statement.
>> It may be a little more work (and maybe you just punt on the
>> optimization till 2.0), but in the long run, the language and all it's
>> users will benefit from removing that special case.
>>
>> --bb
> 
Seems this discussion will never end. I feel sad that Walter has to listen to this every day.

I for one really like foreach_reverse and IMHO the proposed alternatives seem much more hackish. It also creates a standardized syntax for reverse iteration.

D is not C++!
October 26, 2006
Mike Parker kirjoitti:
> Bill Baxter wrote:
> 
>> The price of a poorly thought-out feature in a language can have repercussions beyond how it affects one's day to day writing of code.
> 
> It's a keyword with an underscore. Big deal. No one has to use it. I really think this is being blown way out of proportion. I've read all of these arguments against foreach_reverse and they just don't make sense to me. How is it poorly thought out? It makes perfect sense to me.
> 
>>
>> Already there have been a few people here who looked at foreach_reverse and said "if this is representative of D, then I'll find another alternative, thank you".  If the community shrinks, or fails to grow as it could, then that certainly impacts all D users.  It's all about the network effect.  I can say for myself when I saw the foreach_reverse addition it seriously made me consider whether there was any hope for D long term.  If this is the kind of design decision being made today, then what hope is there for the long term?  There's no Bell Labs or Sun Microsystems backing it, so it can't just power its way through bad design.  It's got to compete on quality.
> 
> People who turn away from D because of one keyword they find unusual can stay away. I wouldn't want to work with such people. Programmers can be a fickle lot, but that's ridiculous in the extreme. It's like the C++ programmer who says, "If your code uses char*, you have a bug."
> 
> There are other issues in D that are more likely to, and have, turned people away, as I see it. A keyword with an underscore that no one even need use is nothing.


I do not want to participate in verbal tennis, just to express my support and humble opinion as hobbyist programmer I totally agree with this one. I would use foreach_reverse to do foreach in reversed order.